You Want Salt With That? Part Four: Challenge-Response

re: You Want Salt With That? Part Four: Challenge-Response

Sean — Mon, 07 Feb 2005 21:10:00 GMT

An excellent series. I found this very informative.
Thanks

re: You Want Salt With That? Part Four: Challenge-Response

JD — Mon, 07 Feb 2005 21:15:00 GMT

Fantastic series! Thanks! I would try to come up with working example in PHP to implement this!

Thanks once again!

JD

re: You Want Salt With That? Part Four: Challenge-Response

Eric Lippert — Mon, 07 Feb 2005 21:22:00 GMT

Argh!

What part of DO NOT ATTEMPT TO ROLL YOUR OWN SECURITY SYSTEM was unclear?

This series of articles gives just a quick overview of some of the simpler techniques used by authentication systems and the people who try to crack them. There is nowhere NEAR enough information in here to actually build a secure system.

Let me give you an example. The Kerberos authentication system is breakable if the cryptographic algorithm used allows for mutagenic encryption.

Muta-what? If you don't know what that means, if you can't look at an encryption algorithm and see whether it's susceptible to mutation attacks, then you can't write a secure implementation.

Writing a good authentication system is HARD, it is one of the hardest tasks that face computer scientists today. Realtime robot controllers are a piece of cake compared to authentication systems, so PLEASE leave it to the experts.

(And I am no expert -- I have nowhere near enough experience to write an authentication system.)

re: You Want Salt With That? Part Four: Challenge-Response

foxyshadis — Mon, 07 Feb 2005 21:59:00 GMT

(I have a confession: I wrote my own challenge/response, and then a cut-down version of kerebos, for my site. On the other hand, I wrote the first web server it used, several database servers, pseudo-ssl, fat-client web pages, and so on. It was fun, frustrating, and educational. =D)

Eventually most of it was scrapped for the much more secure and usable Apache/Tomcat + Mysql/Xalan. I'm not smart enough to make uncrackable servers.

Ye Olde Salt

Phylyp — Tue, 08 Feb 2005 07:01:00 GMT

Great series Eric.

Encryption is one area where the more I learn, the less I know...

Would you believe I once thought XORing data (against a single byte value, no less!) was a *great* way of encrypting it?

Thinking back, I'm almost embarrassed to admit it here. Not to mention other equally hilarious forays into encryption.

Presently, I'm able to use the CryptoAPI in my apps that require it, and leave the implementation of encryption techniques to the mathematicians, thank you.

Looking forward to more foundation-building articles like the same.

re: You Want Salt With That? Part Four: Challenge-Response

Eric Lippert — Tue, 08 Feb 2005 08:20:00 GMT

I don't know if Mike came up with the term or if it's an old joke, but Michael Howard refers to algorithms like the XOR encryption as "encraption".

Ah, those witty Kiwis.

Anyhow, thanks for the compliment -- like I said, I'm not sure what I'll blog about next. I've got a whole lot of ideas but not very much time these days.

re: You Want Salt With That? Part Four: Challenge-Response

G. Man — Tue, 08 Feb 2005 14:23:00 GMT

System #4, "Unfortunately, this system is worse" : I dont think that sending a hashed password is WORSE than sending the password in the clear! Granted it is not effective, but it put up barriers for the casual snoop who knows how to run a packet sniffer but knows nothing about hashes or writing their own clients!

re: You Want Salt With That? Part Four: Challenge-Response

G. Man — Tue, 08 Feb 2005 14:39:00 GMT

P.S. Why not just use a timestamp i.e. "2004-06-21T11:29:01.9346744" as the salt, you dont have to worry about unique salts.

Also, you are still open to man-in-the-middle attacks. The server must sign its hashes using asymmetric encryption otherwise I could pretend to be the server and get passwords from the client whenever I need them.

re: You Want Salt With That? Part Four: Challenge-Response

G. Man — Tue, 08 Feb 2005 14:42:00 GMT

sorry, I meant use the timestamp as the challenge, not the password salt

re: You Want Salt With That? Part Four: Challenge-Response

Skywing — Tue, 08 Feb 2005 18:15:00 GMT

You might also want to check out [url=http://srp.stanford.edu]SRP[/url].

re: You Want Salt With That? Part Four: Challenge-Response

Lance Fisher — Wed, 09 Feb 2005 15:31:00 GMT

Great Series Eric!

re: You Want Salt With That? Part Four: Challenge-Response

James — Wed, 09 Feb 2005 23:43:00 GMT

Eric, I might have a series of dumb questions: how are password policies enforced? If the server implements them, I assume that the password is sent in clear text? Either way, I suspect the only reason techniques similar to those you describe are employed -- as opposed to full-blown encryption -- is related to available processor resources. Am I right? Do you see this changing?

re: You Want Salt With That? Part Four: Challenge-Response

Eric Lippert — Thu, 10 Feb 2005 00:03:00 GMT

You're now asking about an entirely different problem -- how to securely transmit the original secret to the server.

> I assume that the password is sent in clear text?

I should hope not!

> how are password policies enforced?

Like, say, passwords must be longer than a certain number of characters? Clearly the server must get the password somehow!

> I suspect the only reason techniques similar to those you describe are employed -- as opposed to full-blown encryption

By "full blown encryption" I assume you mean "using encryption to transmit a message which can be turned back into plaintext by the recipient".

> is related to available processor resources

Encryption of short messages such as passwords is cheap, so no, that's not it. Sending the bits over the wire a reasonable distance is almost certainly more expensive in terms of raw time than doing the math.

Let me give the shortest reason for why you wouldn't use "full blown encryption": because full blown encryption is HARD TO IMPLEMENT CORRECTLY, and NOT NECESSARY TO SOLVE THE PROBLEM.

When it comes to authentication schemes, you want it to be as simple as possible, but no simpler. The key management problems inherent in full-blown encryption -- as in SSL, for example -- are non-trivial. If you can build an authentication system that doesn't need them in order to succeed, then do so!

Now, you are entirely correct in noting that I have hand-waved away the problem of getting the password or pasword-equivalent-hash onto the server in the first place. That DOES require some kind of encryption whereby the message can be recovered by the server. I might do a series on how that works sometime.

re: You Want Salt With That? Part Four: Challenge-Response

William — Thu, 10 Feb 2005 18:36:00 GMT

Thanks Eric. You pointed it out, but I think it is worth saying again that this is not secure nor is any Non-Encrypted means because you can do a dictionary attack as you have all the information you need off the wire. Once you find the password (taking as much time as you need offline), you now have access to this box or any others that use same password. So this is more or less Security-Via-Obscurity which we know is not really security. Even WS-Security and the SendHashed option uses a similar method of using a "Nonce" (one time value), Date "Created" value and "Password Digest" to form a validator that the server can verify. The problem is, all that fancy mojo still does not stop a simple dictionary attack as I point out in "Crack your WSE SendHashed Passwords. "
http://spaces.msn.com/members/staceyw/Blog/cns">http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!178.entry

And that spec was created by industry experts in the field! Even passwords people think are strong like "Letmein;12" can be cracked in ~minutes. BTW - How many people when forced to add digits to a password start at 1 or 12 and increment them when prompted for a change?

IMO, I would not recommend any scheme based on hashes unless the session is *encrypted with SSL or WS-SecureConversation (or other). If the session is encrypted you probably don't need hashes to begin with unless your doing something special with them at the back end. Also, I don't know why people want to use another database when we have AD/SAM and can leverage its' tools. So use encryption, get the clear password on server component, and use win32's LogonUser to authenticate. The ~downside is you have the clear password in a server process for some short time, but only the private key can decrypt, so we can control/guard the logic that uses it closely. Naturally, the Admins can use dictionary attack on ADs password DB, put if we can't trust the admins, then not sure what solution you could implement.

So I would use WSE and SecurityContextTokens(SCT) to sign and encrypt data/body. And don't use UsernameTokens or pw hashes at all. You can get a SCT with public WSE apis. I have also written a way to get a SCT over Soap.tcp and authenticate at same time using PKI encryption and one request/reply pair. Anyone please feel free to review and provide feedback:
http://spaces.msn.com/members/staceyw/Blog/cns">http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry

--William

re: You Want Salt With That? Part Four: Challenge-Response

Eric Lippert — Fri, 11 Feb 2005 01:08:00 GMT

If you can establish an SSL connection then all communications have an additional level of encryption, yes. If you're going to do that, then there's no reason why you couldn't just send the password. No need to muck about with challenge-response, etc, to avoid a replay attack. The unique session key is sufficient to avoid the replay, and the session key is encrypted with the server's public key.

However, SSL does beg the question somewhat. SSL builds a trustworthy connection over an untrustworthy network by leveraging a trusted root certificate. Essentially for any SSL-based scheme to work, every client must trust a given root cert.

Essentially we're talking about mutual authentication here, which is quite a bit harder than one-way authentication. I might do another series on mutual authentication some time.

re: You Want Salt With That? Part Four: Challenge-Response

Dave Anderson — Fri, 11 Feb 2005 22:49:00 GMT

"...refers to algorithms like the XOR encryption as "encraption"..."

And yet XOR is at the very heart of DES and other algorithms. Heck - we can achieve perfect secrecy with XOR and a one-time pad (assuming a pad made with a perfectly random generator, of course). And it would be a hell of a lot faster than exponentiation over an enormous finite field.

Encraption may be a funny word, but it certainly understates the power of XOR.

re: You Want Salt With That? Part Four: Challenge-Response

JD — Fri, 11 Feb 2005 23:39:00 GMT

Sorry for replying bit late.

Eric, when I said that I will try to create working example in PHP, I didn't mean that I will write my own encryption system. What I meant was I would write a working login page which will use MD5 or SHA on both client side (using Javascript) and on Server side (using PHP) to authenticate a user. This example can teach others how they can go about implementing the same in their projects.

I hope I am clear this time.
JD

re: You Want Salt With That? Part Four: Challenge-Response

William — Sun, 13 Feb 2005 19:58:00 GMT

"What I meant was I would write a working login page which will use MD5 or SHA on both client side (using Javascript) "

But why? IMO, hashing is not encryption. And we showed that it is pretty easy to dictionary attack. Using a true encrypted session such as SSL or WS-SecureConversation would be more useful and secure.
--William

Eric Rounds it off

Scott Galloway's Personal Blog — Mon, 14 Feb 2005 17:04:00 GMT

Do not use string hashes for security purposes

Fabulous Adventures In Coding — Fri, 07 Sep 2007 01:44:44 GMT

A recent question I got about the .NET CLR's hashing algorithm for strings is apropos of our discussion

re: You Want Salt With That? Part Four: Challenge-Response

L. Michael Asher — Fri, 11 Jan 2008 18:42:46 GMT

-> "IMO, hashing is not encryption..."

It is a form of encrpytion, plain and simple.

-> "we showed that it is pretty easy to dictionary attack"

No more or less so than symmetric encryption is.

-> "Using a true encrypted session such as [SSL] would be more useful and secure..."

Do you thin kthat SSL doesn't use hashing to authenticate messages? Think again.