phc-discussions - NFC v NFD UTF-8 Normalization Re: [Was output specifics]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <D911D908-5C2E-4CE0-9D0A-3ADAD092BA40@goldmark.org>
Date: Mon, 9 Mar 2015 15:41:51 -0600
From: Jeffrey Goldberg <jeffrey@...dmark.org>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: NFC v NFD UTF-8 Normalization Re: [Was output specifics]

Sent from my iPhone
(And therefor poorly quoted)

> On Mar 7, 2015, at 7:38 AM, Thomas Pornin <pornin@...et.org> wrote:
> 
> It is RECOMMENDED that passwords are encoded in UTF-8, with NFC normalization and no BOM

I think that you have worded this perfectly. We don't reach (too much) beyond our scope, but we do offer unambiguous guidance. 

But now to the NFC/NFD debate. The case for NFC is obvious. It's what is widely used already. 

The case for NFD is if one wanted to do something like what Facebook does with CAPS-LOCK. If your password fails, Facebook will automatically and silently retry it with case shifted. 

So if someone wanted to do something similar with ö and o, it is much easier to engage in such transformations with NFD.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (2021 bytes)