[BlueOnyx:23541] Re: GUI Login issue for user admin (5209R)
Fungal Style
wayin at hotmail.com
Fri Dec 20 21:17:20 -05 2019
@ would be a problem afaik and is not allowed in the password settings of the gui
Regards
Brian
On 20/12/19, 9:07 pm, "Blueonyx on behalf of Rickard Osser" <blueonyx-bounces at mail.blueonyx.it on behalf of rickard.osser at bluapp.com> wrote:
Hi Michael,
The only blocked characters I can think of that I know is regularly
used in passwords are 'and' (&) and 'at' (@).
If I have to choose one I'd choose @...
IMHO,
Rickard 😀️
On Thu, 2019-12-19 at 13:28 -0500, Michael Stauber wrote:
> 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.
>
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
More information about the Blueonyx
mailing list