[cryptography] Oddity in common bcrypt implementation

Marsh Ray marsh at extendedsubset.com
Tue Jun 28 20:15:11 EDT 2011

On 06/28/2011 02:09 PM, Sampo Syreeni wrote:
> 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?

> First lets quickly discuss the problem with the AOL Passwords they
> are case insensitive, truncated to 8 characters and required to be at
> least 6. There is more detailed information on The Washington Post by
> @briankrebs . This is a problem and makes weak passwords no mater how
> complex one wants to make it (or thinks that it is). AOL is acting as
> an identity service to iTunes, HuffPo, Meebo, anyone who uses the AOL
> OpenAuth or OpenID services and any instant messaging client. This
> both compounds the issue and spreads the risk around to everyone.

On 06/28/2011 02:09 PM, Sampo Syreeni wrote:
> Any system that dedicates fourty pages worth of text to string
> comparison doesn't have those attributes. It doesn't promote security
> proper, but rather bloated software, difficulties with
> interoperability, unsecure workarounds and even plain security
> through obscurity.
> As a case in point, the Unicode normalization tables have changed
> numerous times in the past, and they aren't even the whole story.
> True, after some pressure from crypto folks they finally fixed the
> normalization target at something like v3.2 or whathaveyou. But then
>  that too will in time lead to a whole bulk of special cases and
> other nastiness, which then promotes versioning difficulties, code
> that is too lengthy to debug properly, and diversion of resources
> from sound security engineering towards what I'm tempted to call
> "politically correct software engineering".

I agree. The thing is borderline unusable unless you can leverage the 
resources of an Apple, Adobe, IBM, or Microsoft on just the text handling.

> I mean, you've certain
> already to have seen what happened in the IETF IDN WG wrt DNS
> phishing... If I ever saw a kluge, attempts at homograph elimination
> (a form of normalization) is that.

Speaking of DNS and crypto protocols, have you seen ICANN's plan to 
register custom gTLDs?

That's right - public internet DNS names without a dot in them. Talk 
about violating your fundamental assumptions.

How is x509 PKI going to interact with this?

> Passwords aren't "text" in the normal sense. Precisely because they
> should be the only thing human keyed crypto should depend on for
> security. As for the rest of the text... Tag it and bag it as-is. At
> least the original intent can then be uncovered forensically, if
> need be. Unlike if you go around twiddling your bits on the way.

Yes, I used to develop print spooling software and always regretted it 
when we deviated from this strategy.

>> You can only claim "bytes are bytes" up until the point that the
>> customer says they have a directory server which compares usernames
>> "case insensitively".
> If there's a security implication, you should then probably fail safe
> and wait for the software vendor to fix the possible
> interoperability bug.

Ideally. In practice, sometimes the string-matching code doesn't know 
which the 'safer' direction to fail is.

You can't simply file a bug report and have a Microsoft, Novell, or Sun 
change (or maybe even document) the fundamental behavior of their 
directory server.

- Marsh

More information about the cryptography mailing list