Min Password Length vs Block Common Passwords

[mpalmer (Matt Palmer)]

My bet there is that the client-side validation is counting octets, whereas the server, being Unicode-aware, is counting characters, and coming up with a different result.

[elijah (Eli the Bearded)]

Characters in that codeblock (and indeed all of U+1xxxx) are four-octets long in UTF-8. I don’t know what it’s counting, but Unicode 7/Unicode 8 issues (like amphora) could be in play.

[david (David Taylor)]

Taking the string " " as an example, javascript says

"😀".length = 2

and Ruby says

"😀".length = 1

---

Which is the correct implementation here? @codinghorror's blog post says:

Enforce a minimum Unicode password length

because it’s nice and simple for users. So is one character. That sounds reasonable to me.

However… the blog also says

If you paste the above four Unicode emojis into your favorite login dialog (go ahead – try it), to discover that it … isn’t in fact four characters.

This is indeed true of the Discourse password fields - one emoji = 2 characters. So if it’s showing as 2 characters in the password field, surely that should count as 2 characters in a password

---

On a related note, it is currently very difficult to type emojis directly into html password inputs - you can only copy/paste them in. This is the case on Chrome on mac (using system emoji window), and also Safari on iOS (the emoji button doesn’t even show up with the password field focused). So, as much as I try, I can’t use as my password on Discourse (without cheating with copy/paste).

[elijah (Eli the Bearded)]

😀 is four octets in UTF-8: Base64 visualizer

I have no idea why Javascript gets that count. (UTF-16?) But 😀 does show as ⏺⏺ in the password field of Discourse (for me).

[david (David Taylor)]

@elijah

UTF-16?

It would appear so (from here)

This property returns the number of code units in the string. UTF-16, the string format used by JavaScript, uses a single 16-bit code unit to represent the most common characters, but needs to use two code units for less commonly-used characters, so it’s possible for the value returned by length to not match the actual number of characters in the string.

[fedup]

A sentence with spaces - could be the best personal password choice

[Mittineague]

I’m not sure a space would work. It’s a control character and there might be some filters somewhere that wouldn’t like it.

[david (David Taylor)]

@Mittineague

I’m not sure a space would work

A space is absolutely fine, it’s just another character as far as a password is concerned. Try it here on meta - it works.

[Alt-Elijah (Elijah's Alternate)]

@Alt-Elijah

我发现，在输入八个“杂项符号和象形文字”区块字符（例如 及其附近的字符）后，密码更改框会显示绿色的“通过”，但提交后却变为红色的“太短”。即使全部使用非 ASCII 字符，我也必须输入满十个字符。更改密码后，我能够使用 Firefox 和 Chromium 登录。

再次测试，现在我知道我的密码管理器是 安全的。同样的情况又发生了：足以显示绿色“通过”的 emoji 数量，实际上并不足以成功设置密码。当我逐步尝试越来越长的密码时，系统在第三次尝试时将我登出了。当我成功将其设置为包含 个 emoji 的密码后，仍然闪现了“您已被登出”的提示，但实际上并未登出。

不确定这个登出问题是 emoji 特有的 bug，还是某种 misguided（或者至少是不便）的功能。如果这是功能设计，请让“您已被登出”的提示框说明具体原因。

[riking (Kane York)]

是的，这是由于 JavaScript 的遗留问题导致其错误计算包含表情符号（以及其他辅助平面字符）的字符串长度。服务器能正确计算长度。