[BlueOnyx:23537] Re: GUI Login issue for user admin (5209R)

[Michael Stauber]

Hi Tobias,

> But I am quite sure you know what comes next: This seems to be a known 
> problem. So why is it still there? I am afraid we can expect this to
> happen again and again in the future. And I don't expect sympathy for
> this behaviour from my customers..
> 
> It's a bug, isn't it?

It's a longer story and essentially it's a fix for several bugs and
potential exploits.

What we do have now is consistent behavior, though: You try to create a
user via the GUI with a password that has illegal or unsupported
characters? Or you or a siteAdmin or user tries to change his password
via the GUI to one that contains illegal characters?

The GUI won't let you do that and will tell you that your password
contains illegal characters.

So in essence and as far as *that* goes: There is neither a bug nor a
problem.

The issue arises if users get their password changed by other means than
the GUI, because there we cannot check for unsupported characters or
those that are really unwise to be used in first place.

I agree that some of the error handling could perhaps be improved, but
there is also a good security reason why NOT to do that. I don't want
the login form snitch out on us to a potential attacker what the exact
subset of allowed characters might be.

The code change that introduced the current password behavior is from
four years ago and it's this one:

https://devel.blueonyx.it/trac/changeset/2504

That updated the regular expression that's being used on password
validity checks when the password is entered via the GUI.

The other issue is the overhaul of the Login page. That was done in
March 2018 to cope with a potential XSS vulnerability:

https://devel.blueonyx.it/trac/changeset/3035


Let's get technical:
======================

In essence both issues go hand in hand: Whenever we allow a user to
enter data himself (instead of ticking a checkbox or selecting from a
pull-down-menu or moving a slider, etc.) we're in danger. We need to
make *really* sure that the entered data is sane, safe and that there
will be no unforeseen consequences when our code processes that data.

Think of a MySQL quere where a malicious user could trick your MySQL
routine into doing a "DROP ALL;", because you used the info the user
entered as part of your SQL query. And the user entered something that
closed your SQL statement and expanded it at the end with a "DROP ALL;"
and a proper terminator that he supplied via your input form.

In BlueOnyx that won't happen for several reasons and the above measures
are bricks in that wall of defense.

We parse all input and check it. Any input form field and any CODB
database field has a "type" and that "type" specifies what regular
expression is used to check the data for sanity. If entered data doesn't
match that regular expression, then the GUI won't allow you to save.
Even *if* you somehow get past that: CODB won't let the GUI (or the CLI)
store data that doesn't match the regular expression that was specified
in the "type" field in the database backend.

Take usernames. We only accept usernames that are of type
"alphanum_plus", which is specified this way:

<!-- alphanum_plus is alphanumeric data plus a "safe" subset of
punctuation -->
<typedef
	name="alphanum_plus"
	type="re"
	data="^[A-Za-z0-9\\._-]+$"
/>

The reason not to allow - say - umlauts in usernames? Or Kanji
characters? Or Chinese letters or Cyrillic? Because the OS won't allow
it. There is nothing wrong with that and no reason to dispute that, right?

So what's wrong with *NOT* allowing *any* character under the sun for
passwords? In essence it's the same story: The UTF-8 character set
covers such a wide range of characters from different alphabets that it
cannot be guaranteed that all stages of processing will transposition
these characters unchanged.

For example:

https://www.rapidtables.com/code/text/ascii-table.html

The first 32 characters in ASCII code table are "control characters"
that go back to the days of terminal devices and printers. They're used
for sending line feeds, form feeds and carriage returns and such. That's
not password material. But a malicious user could find ways to enter
them as parts of a password.

Characters 33-47, 58-64, 91-96 and 123-127? Depending on how and what
you process them with you need to escape some of them or make them safe
for processing.

Then in the Extended ASCII table you have all the weird offspring with
umlauts, accents, acutes and symbols. But that's not even all of it,
because this is *only* the ASCII table and UTF-8 supports the whole
shebang with a lot more that:

https://www.rapidtables.com/code/text/unicode-characters.html

If you wanted to, you could have the © (copyright symbol) in your
password. In Unicode that's U+00A9, in numeric HTML it's © 	 or in
named HTML code it's ©

You could hammer it in with the Alt+Gr and Numpad keys in some clients
when prompted for the password, but even then there is a good guarantee
that not all clients (or daemons!) would allow it or would interpret
that correctly. So you quickly get into territory where the password
behavior would be inconsistent.

The thing is that I needed to draw a line in the sand somewhere and say:
"Until here and no further. These and those characters are fine for
passwords, but all others are not."

We can argue about allowing several special characters that are
currently not supported, but I cannot (totally impossible!) allow the
whole UTF-8 subset of characters when even more than half of the ASCII
table is already highly problematic.

So please take a look at https://devel.blueonyx.it/trac/changeset/2504
again and let me know which additional characters would be nice to have
in passwords and I'll put that on the to-do-list.

-- 
With best regards

Michael Stauber