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

[Arnold Reinhold]

> On Aug 17, 2017, at 3:43 PM, Jerry Leichter <leichter at lrw.com> wrote:
> 
>> ...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!
> 

NIST says "All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets.”  So nonprinting characters can and should be ignored.  For Unicode, NIST advises:

"If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings using either the NFKC or NFKD normalization defined in Section 12.1 of Unicode Standard Annex 15 [UAX 15]. This process is applied before hashing the byte string representing the memorized secret. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully.

Unicode normalization is complex issue, see e.g. http://www.unicode.org/reports/tr15/ and I don’t know remotely enough to say the normalization modes suggested cover all potential password-related problems in Unicode, but they clearly represent a carefully considered attempt by people with much expertise on the topic.

Overall I strongly agree with your statement that “the system is there for its users, not the other way around.”  If the new NIST recommendations were widely adopted, users would benefit by not have to chose super-strong passwords. 

Where I differ is in the best way to help the user. My big concern is giving the developers of password authentication systems leeway in “improving” passwords, beyond what NIST allows. I can see developers removing all sorts of text patterns that do not normally have semantic meanings, such as a letter repeated more than twice, capitalizations in the middle of a word, special characters in the middle of a word, words that are close enough to dictionary word to be likely misspellings, and so on. On the other hand, one of the few strategies available to users who want strong yet memorable passwords is to introduce just such non-semantic transformations. 

So I would not allowing password transformations beyond the ones NIST permits and instead encourage developers to include messages along with password failure notices that call attention semantically dubious patterns, such as those mentioned above and others, such as entering the same incorrect password a second time. Then let the user reenter the password with corrections if they were unintentional errors, but don’t degrade the security of those users who deliberately chose such variants.

Arnold Reinhold





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170820/3d1cd34f/attachment.html>