News for hackers. Stuff that matters.
Re:NIST’s new password rules – what you need to know by mschuster91 on Tuesday November 22, 2016 @06:40PM (#13018660)
> and should accept all UNICODE characters, too, including emoji

Hell no. This WILL lead to disaster, especially if people store their passwords in managers that may or may not mess up Unicode. UTF-8, for example, allows to encode the character "ä" as \xc3\xa4 OR \x61\xcc\x88. They look visually identical, yet fail any string comparison.

Not to mention the support calls "I'm in $random_foreign_country and don't have $random_char on my keyboard, cannot login"... good luck trying to match the kitty emoticon on your Android phone to the random font on a website to whatever input system iPhone uses. Or when they're used a German Windows keyboard and suddenly have to use a German Mac - basic stuff like the tilde symbol ~, pipe symbol | or the (square) brackets {[]} are not marked out on the keyboard.

I believe that it makes sense to display a warning "Your password may be impossible to type in another country/using a non-$current_platform keyboard" when such characters are encountered.

Re:NIST’s new password rules – what you need to know by kibwen on Tuesday November 22, 2016 @07:49PM (#13019019)

  > UTF-8, for example, allows to encode the character "ä"
  > [...]
  > I believe that it makes sense to display a warning
Both of these are addressed in section 5.1.1.2:

"If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings defined in Section 12.1 of Unicode Standard Annex 15 [UAX 15] using either the NFKC or NFKD normalization. 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."

https://pages.nist.gov/800-63-3/sp800-63b.html

Re:NIST’s new password rules – what you need to know by ph14nix on Thursday December 01, 2016 @12:11PM (#13081087)
> UTF-8, for example, allows to encode the character "ä" as \xc3\xa4 OR \x61\xcc\x88. They look visually identical, yet fail any string comparison.

Well-designed high-level programming language (see Perl6) compares strings depending on how they look, not on their binary representation [0].

For example let's play with Perl6 REPL:

  > my $a = Blob.new(0xc3, 0xa4)
  Blob:0x<c3 a4>
  > my $b = Blob.new(0x61, 0xcc, 0x88)
  Blob:0x<61 cc 88>
  > $a eqv $b
  False
  > $a.decode() eqv $b.decode()
  True
  > $a.decode() eq $b.decode()
  True
As another example, Python3 would fail:

  >>> a = b'\xc3\xa4'
  >>> b = b'\x61\xcc\x88'
  >>> a == b
  False
  >>> a.decode() == b.decode()
  False
Perl6 is definitely going to dominate the world one day.

[0] https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-p...

Re:NIST’s new password rules – what you need to know by silverwind on Tuesday November 22, 2016 @07:58PM (#13019057)
> They look visually identical, yet fail any string comparison.

That's a non-issue. You should normalize unicode strings to a common form (preferably NFC) before any comparision.

Re:NIST’s new password rules – what you need to know by userbinator on Tuesday November 22, 2016 @08:39PM (#13019247)
Personally, I think passwords should be opaque sequences of bytes that just happen to be mostly easily input on a keyboard, but I agree with the warning: some might even consider such a warning a good thing.
Re:NIST’s new password rules – what you need to know by simcop2387 on Tuesday November 22, 2016 @09:38PM (#13019517)
The problem with that is, which keyboard? USA, German, UK, Japanese?