[cryptography] Oddity in common bcrypt implementation
nico at cryptonector.com
Tue Jun 28 18:35:58 EDT 2011
On Tue, Jun 28, 2011 at 2:09 PM, Sampo Syreeni <decoy at iki.fi> wrote:
> On 2011-06-28, Marsh Ray wrote:
>> Yes, but in most actual systems the strings are going to get handled.
> Is this really necessarily true, or just an artifact of how things are
> implemented now? Or even a simple-minded implementation.
> Take the case of passwords and usernames. It might make some sense to do a
> case-insensitive username comparison. It wouldn't hurt security much, it
> might help usability and interoperability, and it constitutes desirable
> But a case-insensitive password compare?!? For some reason I don't think
> anybody would want to go there, and that almost everybody would want the
> system to rather fail safe than to do anything but pass around (type-tagged)
> bits. I mean, would anybody really like a spell checker in their ATM?
It's not *case* that you want to be insensitive to. It's *form*,
specifically Unicode form. Whenever you derive keys from passwords or
otherwise use them as inputs to one-way functions you need to put the
password into canonical form, which for Unicode means one of NFC, NFD,
NFKC, or NFKD, plus some additional mappings. This all relates to
things like diacritical marks (accents, etcetera) and such things as
variants of periods and whitespace (think of non-breaking space).
As Paul H. points out, this is not the right forum to discuss the
specifics of Unicode password preparation. So we should stop at
noting the fact that ASCII passwords are always canonical while
Unicode, non-ASCII passwords require additional preparation in order
to be put into canonical form. (This might also be true of other
character sets (or codesets), but we should really only concern
ourselves with Unicode here.)
More information about the cryptography