Hi Michael, thanks for the very detailed explanation. For me the first part of it is sufficient: The GUI doesn't let you enter characters that cce doesn't allow.
This is what I suspected. This is the interface for people without deeper knowledge which have to be protected from errors like this. Users using the shell are able to understand explanations like this. Thanks a lot! Tobias > -----Original Message----- > From: Blueonyx [mailto:[email protected]] On Behalf Of > Michael Stauber > Sent: Thursday, December 19, 2019 7:29 PM > To: [email protected] > Subject: [BlueOnyx:23537] Re: GUI Login issue for user admin (5209R) > > 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 > _______________________________________________ > Blueonyx mailing list > [email protected] > http://mail.blueonyx.it/mailman/listinfo/blueonyx _______________________________________________ Blueonyx mailing list [email protected] http://mail.blueonyx.it/mailman/listinfo/blueonyx
