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 eye-candy.
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 more a question of whether or not your protocol specification
defines the format it's expecting.
It's not all about that. There's also the issue of implementability,
testability and ability to promote (and then withstand) analysis. 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 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.
Humans tend to not define text very precisely and computers don't work
with it directly anyway, they only work with encoded representations
of text as character data.
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.
Many devs (particularly Unixers :-) in the US, AU, and NZ have gotten
away with the "7 bit ASCII" assumption for a long time, but most of
the rest of the world has to deal with locales, code pages, and
multi-byte encodings.
Finnish people don't, and never have.
Let's say you're writing a piece of code like:
if (username == "root")
{
// avoid doing something insecure with root privs
}
The logic of this example is probably broken in important ways but the
point remains: sometimes we need to compare usernames for equality in
contexts that have security implications.
Then you write it out as "root" and it matches "root" because you wrote
"root" the first time around. Plus, that is also why those security and
interoperability sensitive things have been pared downto a minimum,
common character set, in the first place.
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.
The first RFC http://tools.ietf.org/html/rfc2058#section-5.2 says
nothing about the encoding of the character data of the password
field, it just treats it as a series of octets.
Yeah. That's sloppy, compared to today's standards and environments.
I've in fact often wondered why language/encoding/etc considerations
aren't a mandatory section in an RFC, like security is. Even when
dealing with manifestly user-input character data.
Consequently, we can hardly blame users for not using special
characters in their passwords.
Can you really blaim the user for anything?
--
Sampo Syreeni, aka decoy - [email protected], http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
