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

비밀번호 변경 상자에 8개의 “기타 기호 및 픽토그램” 블록 문자(예: 및 :nearby:)를 입력하면 초록색 “확인” 메시지가 표시되지만, 제출 시 빨간색 "너무 짧음"으로 바뀐다는 사실을 발견했습니다. 모든 문자가 비-ASCII여도 10자까지 입력해야 합니다. 비밀번호 변경 후 FF와 Chromium 양쪽 모두로 로그인할 수 있었습니다.

이제 내 비밀번호 관리자가 안전하다는 것을 알았으니 다시 테스트해 보았습니다. 같은 일이 다시 일어났습니다: 초록색 "확인"을 받을 수 있을 만큼 이모지를 입력해도 실제로 작동하지는 않습니다. 그리고 더 긴 비밀번호를 시도하면서 반복적으로 테스트하던 중, 세 번째 시도쯤 로그아웃된 것 같습니다. 마침내 이모지 비밀번호로 성공적으로 설정했을 때, "로그아웃되었습니다"라는 메시지가 잠시 표시되긴 했지만 실제로 로그아웃되지는 않았습니다.

이 로그아웃 문제가 이모지에 특화된 버그인지, 아니면 잘못된(또는 적어도 도움이 되지 않는) 기능인지는 확실하지 않습니다. 만약 이것이 의도된 기능이라면, “로그아웃되었습니다” 상자에 그 이유를 설명해 주시기를 바랍니다.

[riking (Kane York)]

네, 이는 자바스크립트의 레거시 문제로 인해 이모지(그리고 기타 아스트랄 평면 문자)가 포함된 문자열의 길이를 잘못 계산하기 때문입니다. 서버에서는 길이를 올바르게 계산합니다.