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?
http://mattjezorek.com/articles/security-researchers-need-to-research
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
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
