[Cryptography] [FORGED] NIST SP 800-63-3

[Jerry Leichter]

> ...If the password is displayed in a monospace font, the extra spaces would be clear, except maybe at the end. A font that had a glyph for space, a faint blue dot perhaps, would be even better. 
> 
> In addition, if extra erroneous spaces are a significant problem, there is nothing to prevent the password verifier from displaying a message when rejecting a password saying it contains spaces at the beginning and end, or multiple consecutive spaces in the middle. Some systems i have encountered warn you that the caps lock is on. (They may have a way to detect this directly in JavaScript, but detecting that all alphabetic characters in the bad password are  uppercase would work too.) 
> 
> I would much rather have a clear principle that passwords should be evaluated as entered without any changes....
I find this one of those principles that contradicts normal user experience.

In most contexts, spaces have little semantic significance.  Certainly, one space versus multiple spaces has virtually none.  And what about TAB?  In traditional contexts, there's no difference in appearance - or semantics - between TAB and some number of spaces.  Users would be completely unaware of the difference.  In others (e.g., browsers) TAB has an entirely different semantics ("move to next field" and can't even be entered into the current field).  So if you're going to go with the "evaluate as stream of actual bytes" principle, what if I create a password in a context where TAB is accepted, then have to enter it in a context where it isn't?  (For that matter, you could apply the same argument to RETURN and other "format effectors", to use the official ASCII name for these characters.)

If you allow Unicode characters, there are many different whitespace characters - half spaces, for example.  What do you want to do with those?

Passwords are not just strings manipulated by computers.  They are user interface elements.  The fact that upper and lower case are distinct is somewhat unnatural to people, but they've gotten used to it (though exactly how this is handled in languages with more complex systems - multiple cases, multiple logically representations of the same character, etc., I don't know - I've always wondered, though).

The theoretical loss of key space produced by trimming leading and trailing whitespace and converting all internal whitespace to single space characters - is, in the end, completely trivial compared to the increase in user acceptability.

Never forget that the system is there for its users, not the other way around!

                                                        -- Jerry