Discussion of unicode password requirement V2.1.4

[tghosth]

https://twitter.com/FakeUnicode/status/1192245294429130752?s=19

[elarlang]

Current (v4.0.1) unicode requirement:

V2.1.4 Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.

To watch entire password ruleset, use: #683 Discussion: rules for password format and content

[tghosth]

I have always struggled with unicode/emojis being a compulsory requirement here and this Twitter thread makes me think that even more so. I would consider softening this requirement somehow to focus on not blocking any characters.

[elarlang]

To be clear - problem is not with unicode, problem is with emojis (choosing visually pictures instead type letters).

[danielcuthbert]

I couldn't agree more with the original thread and comments here. As someone who doesn't get emojis or uses them, it's all foreign to me but I see the appeal for wanting to use them. The arguments about warning of using them, however, should be added. In my mind, it should read something like:

Verify that no character set is blocked from being used as a source for passwords. Whilst it is important to note that the chosen input method may vary depending on situation, a single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.

Thoughts?

[jmanico]

I would just suggest “any printable Unicode character including language neutral characters such as spaces and Emoji” Not all User Agents handle control characters well. And I politely suggest that the “12 emoji or 64 kanji” bit confuses the issue a bit.

…

-- Jim Manico @manicode

On Dec 8, 2019, at 3:34 PM, Daniel Cuthbert ***@***.***> wrote:  I couldn't agree more with the original thread and comments here. As someone who doesn't get emojis or uses them, it's all foreign to me but I see the appeal for wanting to use them. The arguments about warning of using them, however, should be added. In my mind, it should read something like: Verify that no character set is blocked from being used as a source for passwords. Whilst it is important to note that the chosen input method may vary depending on situation, a single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted. Thoughts? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[danielcuthbert]

Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords.

Short, simple and covers all. Any objections?

[elarlang]

Just for pointing it out - if we include "spaces", we going to merge requirements V2.1.3 and V2.1.4

V2.1.3 Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced.
V2.1.4 Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.

I actually like do-not-trim-spaces-from-password as separate requirement.

[tghosth]

So having read the original NIST, I think that these requirements should actually be as follows:

V2.1.3 Verify that password truncation is not performed. However, consecutive multiple spaces MAY optionally be coalesced.
V2.1.4 Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords

Any further comments?

[jmanico]

+1

…

-- Jim Manico @manicode Secure Coding Education +1 (808) 652-3805

On Dec 22, 2019, at 2:54 PM, Josh Grossman ***@***.***> wrote:  So having read the original NIST, I think that these requirements should actually be as follows: V2.1.3 Verify that password truncation is not performed. However, consecutive multiple spaces MAY optionally be coalesced. V2.1.4 Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords Any further comments? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jmanico]

Maybe change coalesced to a easier word? :)

…

-- Jim Manico @manicode Secure Coding Education +1 (808) 652-3805

On Dec 22, 2019, at 2:54 PM, Josh Grossman ***@***.***> wrote:  So having read the original NIST, I think that these requirements should actually be as follows: V2.1.3 Verify that password truncation is not performed. However, consecutive multiple spaces MAY optionally be coalesced. V2.1.4 Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords Any further comments? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[tghosth]

V2.1.3 Verify that password truncation is not performed. However, consecutive multiple spaces may be replaced by a single space.
V2.1.4 Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords

[jmanico]

👍🏼👍🏼

…

-- Jim Manico @manicode Secure Coding Education +1 (808) 652-3805

On Dec 25, 2019, at 2:43 PM, Josh Grossman ***@***.***> wrote:  V2.1.3 Verify that password truncation is not performed. However, consecutive multiple spaces may be replaced by a single space. V2.1.4 Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[tghosth]

Opened a PR which I will merge in a week or so in case anyone has final comments.