Do not allow the elimination of all spaces in memorized secrets #679
Comments
|
I agree with the suggestion of eliminating the sentence entirely. I see no meaningful benefit to allowing a Verifier to silently compress or remove "space characters". At best, allowing this might save a negligible number of bytes per authentication message exchange. However this comes at a real cost of reducing entropy, as described by @agreinhold, without the user's knowledge. A user could work around this issue by using punctuation or some other delimiter instead of spaces, but this relies on the system informing the user of the behavior at the time they choose their password. |
|
I also agree, this reduces security for no obvious reason, and in a way that is not transparent to the user. This sentence should be removed. |
|
Agreed: Eliminate the sentence entirely. What the user types in a password field IS the password, period. Spaces should be treated no differently from "," or the letter "a". Arnold's arguments are sound. Spaces are an important issue particularly with respect to Diceware, and Diceware is a VERY powerful technique for generating passphrases which are both (1) highly unpredictable and (2) very easy to remember. I for one can easily remember a few different 10 word Diceware passphrases, each with over 128 bits of strength, and also a few 5 word Diceware passphrases, each with over 64 bits of strength. The ability to type spaces between words helps with the rhythm of typing, and also helps prevent problems like Arnold mentions such as "to" and "day" forming "today" when run together. "Ilikepi" above also makes an excellent point by noting that any system which does ignore or compress spaces must inform me at the time I choose my password. After all, I really should know if "to day other stuff" is treated the same as "todayotherstuff". It's true that I could type a comma "," instead of a space between the words -- but again, I wouldn't know I had to do that unless the system told me it was discarding spaces. I repeat: Drop the sentence entirely. Treat spaces exactly the same as any other character. |
|
See also: #1294 |
|
I concur with the previous comments. Allowing for the removal of characters from a password after it has been entered by the user can only serve to reduce the strength of the password, and as discussed for example in the case of Diceware, removing whitespace can be particularly troublesome. If for some reason a system is unable to properly handle whitespace (or any other type of character) within a password, then the system should prevent the user from selecting passwords that contain such characters to begin with, as opposed to mangling the user's chosen password after it has been entered. I thus agree with chkoreff's comment: Treat spaces exactly the same as any other character. Failing that, the recommendation should be that if a system treats any class of character specially in passwords, such special treatment must be completely transparent to the user chosing the password. This could, for example, be done by preventing the user from selecting a password that contains character classes the system is ill-equipped to deal with properly; such character classes could, for example, include whitespace characters. |
|
The user's password is the user's password. Don't screw with it. Aside from the basic elemental "don't accept wrong passwords" aspect of this, an implementation that screws with passwords is more complex than one that doesn't - thus more vulnerable to side channels and implementation problems. If someone can detect when a character is being dropped, they have a powerful side channel that can reduce the password entropy of, eg, a diceware password to a completely worthless level. |
|
Changing to allow replacement of multiple consecutive spaces with a single space (since that is almost certainly a mistype). |
All Fields Are Required
**Organization Name (N/A, if individual):**Diceware.com
Organization Type (see below for codes):5
Document (63-3, 63A, 63B, or 63C):63B
Reference (Include section and paragraph number):5.1.1.2
Comment (Include rationale for comment):
I urge NIST to remove the provision in Draft SP-800-63B, Section 5.1.1.2, which currently provides “Verifiers MAY remove multiple consecutive space characters, or all space characters, prior to verification provided that the result is at least 8 characters in length.” I strongly disagree with this provision, particularly with the permission to remove “all space characters”, as doing so can weaken security of memorized secrets (passwords and pass phrases) with no significant benefit to users or service providers.
I am the developer of Diceware™ (http://diceware.com), a method for generating random pass phrases that are strong, yet relatively easy to remember. Diceware instructs users to generate random pass phrases with quantifiable entropy, using ordinary dice to select words at random from a list of short words. Diceware is intended to be simple enough for nontechnical users to employ with minimal guidance. It has been available for over 20 years and, and as a measure of its popularity, it or its word list has been translated by volunteers into 21 languages, including Basque, Bulgarian, Catalan, Czech, Danish, Dutch, English, Esperanto, Finnish, French, German, Italian, Japanese, Maori, Norwegian, Polish, Portuguese, Russian, Spanish, Swedish and Turkish. Other entities have produced similar lists. Diceware has been called "the ‘gold standard’ for creating secure passphrases.” Diceware instructions and word lists are provided under an open license and there is no charge for their use.
Diceware is needed
Password generation approaches like Diceware are needed. Section 5.1.1 says “Memorized secrets need to be of sufficient complexity and secrecy that it would be impractical for an attacker to guess or otherwise discover the correct secret value.” The SP 800-63B requirements on password strength, including the 8-character minimum length and 10,000 PBKDF repetitions, while a welcome improvement to much existing practice, are not sufficient to protect against attackers who gain access to verification credentials. Stored credentials have been stolen all too frequently and the thieves often mount attacks using massively parallels architectures, including GPU farms or large networks of compromised computer systems (“botnets”). Common 8-character passwords will succumb to such attacks. There is extensive experience to date that most users fail to pick strong enough passwords on their own or under many forms of guidance.
Diceware provides an engineered way for users to chose memorized secrets strong enough to protect their digital assets from attacks on stolen credentials. Many users choose Diceware to guard their highest-value computer accounts.
Removing all spaces can weaken memorized secrets
Removing spaces before hashing can materially weaken reasonable passphrases chosen by users. The extent of weakening depends on the search mode chosen by an attacker. Say a user has a three word passphrase, a reasonable choice for a login password of moderate strength. If that passphrase appears in a dictionary of previous passwords (unlikely), then sophisticated attack software might try it with and without spaces, so removing spaces would only reduce attack complexity by a factor of 2, i.e. one bit of entropy. However if the attacker employs a search over all character strings, removing spaces would reduce the length of this password from 13 characters to 11 characters. Assuming the attacker is searching only Latin alphabet characters, eliminating spaces would reduce the entropy by 9.5 bits or a work factor of 729. While the current NIST draft insures that passwords are not shortened to less than 8 characters, that is not sufficient protection as pointed out above. Why shorten them at all?
Another potential problem with eliminating all spaces could occur when someone randomly selects a passphrase from a word list such as Diceware. An attacker knowing Diceware is used might attempt to try all combinations of words from the word list up to a certain word count. It can happen that two consecutive words will form a third word in the word list, for example “to” and “day” form “today”. If all spaces are removed, a four word random passphrase could be effectively turned into a three word passphrase, which would succumb to attack far sooner that the user expected. If the Diceware word list were employed, that would be a reduction of 12.9 bits of entropy or a factor of 7,776. Retaining spaces between words eliminates the risk of a generating a weak random passphrase. While Diceware passphrases that would be made more vulnerable by eliminating all spaces are relatively rare, there is no reason for NIST 800-63B to activate this potential weakening.
Space elimination benefits no one
I can not envision any human factors problem in retaining spaces within memorized secrets. It is natural for users to type spaces between words. And if the user exercises the suggested option to fully display their memorized secret as entered, spaces, or their lack, will be readily apparent. There may be a case for converting two or more space characters to a single space character, but even these situations can be dealt with the display option, perhaps by using a monospace font or employing special glyphs to represent spaces. By contrast I did not find any mention of eliminating non-printing characters or converting white-space characters, such as tab, to single spaces. I think that practice could at least be permitted, if not mandated.
The SP 800-63B 5.1.1.2 recommendations will require modifications to login software on many existing systems, e.g. removing tests for composition rules. If some stakeholders currently have login systems that eliminate all spaces, they can easily excise that capability while making other mandated changes. If for some reason this is too difficult for them, the elimination of spaces could be depreciated for new systems.
Please fix this
Later in 5.1.1.2, there is a provision that “Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.” I think this is wise. Allowing the removal of all spaces is very similar to imposing a composition rule and no more desirable. I again urge that the clause “or all space characters” be removed from the sentence cited in 5.1.1.2.
Suggested Change:
Replace the sentence “Verifiers MAY remove multiple consecutive space characters, or all space characters, prior to verification provided that the result is at least 8 characters in length.” with “Verifiers MAY reduce multiple consecutive space characters to a single space character prior to verification provided that the result is at least 8 characters in length.” or (better) eliminate the sentence entirely.
Organization Type: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other
The text was updated successfully, but these errors were encountered: