Slashdot Mirror
Delayed Password Disclosure
ET_Fleshy writes "Markus Jakobsson has an interesting article discussing a promising new security protocol called "Delayed Password Disclosure" that can validate a computers authenticity before exchanging passwords/keys. While nothing is ever truly secure, this seems to show promise in protecting users from a wide variety of stealth attacks (pdf) used today, specifically man in the middle (pdf) attacks."
Forgive me for not reading my latest issue of Cryptographer weekly but how on earth is this any different than RSA fingerprints? It looks like the "envelope" and "carbon paper" are just elements of a pre-shared key anyway.
If you know the fingerprint of the host you are connecting to, you are more or less immune from man-in-the-middle attacks. If you have never communicated with the host before, nothing is going to stop a man-in-the-middle - especially if you have to magically share locations of "carbon paper" without the man-in-the-middle knowing about it.
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
There are enough people who will give away plain-text password unsuspiciously over the phone or internet.
My bank (and probably many others) will block an account after three consecutive failed authentication, so any guesswork is going to be hard for the bad guys.
Rock that crushes, Paper & Scissors that don't matter.
It'd be better if the font weren't so small, though...
Mutual authentication is nothing new. There exist many mutual authentication schemes that are resistant to man in the middle attacks and also ensure liveness of the exchanges.
The one described here looks to be a simple shared secret method. In may situations, certificate based methods are used in order to avoid the need to securely distribute a shared secret ahead of time.
For a shared secret based mutual auth, why not do the normal thing and pass random numbers and their hashes back and forth, mixed in with the challenge-response sequences needed to establish an authenticated identity, a shared session secret and liveness? Read various EAP drafts or 802.11i or recent 802.16e drafts for real world examples of how to do this. The details necessarily change with the context.
These methods have the benefit of lots of analysis by the crypto community. This delayed password disclosure scheme doesn't seem to have the same benefit.
Evil people are out to get you.
Note that use of encryption software, such as SSH, does not address this problem, since the attacker simply can replace the public keys of the two parties with public keys for which it knows the secret keys. This results in the two parties sharing keys with the attacker, as opposed to with each other; as a consequence, the attacker will be able to read (and even modify) all traffic before re-encrypting it and forwarding it.
And this is why you always share public keys via some other secure means (USB drive, cd, floppy), at least in an ideal world. The article talks about this in regards to someone transmitting data to their bank, however if I am not mistaken SSL(not mentioned in the article) already takes care of this kind of attack. Somehow I doubt any joe user is using SSH to authenticate with their bank :-)
I Am My Own Worst Enemy
Me, i hate pdf...so here's HTML versions, courtesy of Google: man in the middle attack
stealth attacks
Have you seen the arrow?
The only part I can't figure out is how they're going to send the carbon paper and envelopes across the Internet. I can't find the protocol for that.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Why is it called Man-in-the-middle?
Isn't it better if it were called Woman-in-the-middle? It would atleast not make us geeks seem so gay.
Well, feminist do-gooders, in an effort to de-genderify the term whilst keeping the acronym MITM beat you to it, by redefining MITM as "Meet-In-The-Middle".
It was a quite popular term in academia, until it was discovered that "Meat-In-The-Middle" in the context of a three-party situation sounds a lot more gay even.
SCO employee? Check out the bounty
What the world does not need is another generalized mutual authentication method. These are used to place a veneer of security on a generally insecure thing.
E.G. Credit card transactions over the internet. These are protected by SSL/TLS. This is somewhat removed from the credit card transaction itself, instead protecting the link rather than the transaction. So you log onto vendorX's web site and use certs with SSL/TLS to protect the link. You feel conforted by the little lock icon in the corner of your screen and proceed to hand VendorX all the details needed to drain arbitary amounts of money from your credit card.
Instead.. Protect the transaction directly, with something like a secure credit card transaction protocol. VendorX doesn't need your credit card details, he needs your money. The security protocols should run between you and the vendor to establish a transaction and the vendor's identity, between you and your credit card company to authorize a payment against the transaction to VendorX and between the credit card company and VendorX to transfer the payment.
VendorX gets the money, not a blank, signed cheque.
Repeat exercise for all activities you need to secure, applying appropriate measures for the situation. Leave SSL/TLS for securing the link, not the application.
Evil people are out to get you.
This is a little like the interlock protocol, without the public-key cryptography. But this instance has the serious disadvantage that the server side must know the user's unencrypted password (or equivalent) to play the game. That is a very bad thing - it has been empirically demonstrated that users will resue their passwords, so any authentication database that keeps them in the clear is a high-value target for attackers.
BTW You are quite safe from MITM attacks when using SSH if you use ssh protocol 2 and public key authentication. The public key signature checks are bound to the results of the Diffie-Hellman key exchange that occurs at the start of the protocol. In the case of a MITM, these DH results will be different for the client->MITM and the MITM->server legs, so the real server will refuse to accept the signature that the client presented to the MITM and the authentication will fail.
By then, it may be too late, as in the meantime, the attacker may collect and even modify information that was not intended for him.
Damnit, Bones I, can't figure out how to, place commas in, my, sentences I know they, should go somewhere I'm. Just not sure where.
https://www.eff.org/https-everywhere
... has solved this problem more than 6 years ago. And it does not require the password to be stored in clear-text by the server. (although, "with a little thought", according to the article, neither does this scheme. BAH! Proof is left as an excercise for the reader)
Stick with something that has been rigorously reviewed, and proven over a period of time. And something that can be explained simply, in terms of the actual technology, rather than resorting to pathetic analogies that do not explain anything!
SRP
So I actually got this sent to me this morning, accompanied with some nice snarkiness about "known plaintext handouts".
a af t-ncs021405.php
http://www.eurekalert.org/pub_releases/2005-02/
Hmm. It's basically Kerberos, except totally broken.
So we don't actually know how this protocol works, but the description at the above link is vastly more coherent. (Anything with "magic envelope" and "this is a metaphor" really shouldn't be taken as a protocol specification.)
===
CUSTOMER: Bank, I will send you some information that is encrypted. You can only decrypt it if you know my password. If you don't know the password, you could of course try all possible passwords (although that is a lot of work!), but you would never know from my message if you picked the right one. Once you have decrypted the message, I want you to send it to me. If it is correctly decrypted, I will know that you know my password already. Once I know that you know my password, I will send it to you so that you can verify that I also know it. Of course, if I am lying about my identity and don't know the password in the first place, then I will not learn anything about the password from your message, so it is safe in both directions.
===
It's also wildly exploitable. Here's how:
First of all, password brute forcing? Alot of work? Only if there's no way to execute an offline attack, i.e. you can run attempts as fast as your own computer can calculate them. What we need is an offline attack -- something that lets us try to try as many attempts as possible. The most important thing is verifiability -- we need to know when we guessed the actual password.
Can we possibly verify our guess? Well, Alice sends the bank some random data, which is dutifully returned to Eve. Eve sniffs this traffic, and now has a very simple task:
Guess all possible passwords the bank could have used to decrypt the password. When the content from Alice, decrypted with the guess, equals what came back from the Bank, Eve has found the password.
But then there's Eve's friend Mallory, who thinks Eve isn't ambitious enough and wants to steal anyone's password at the bank, not just Alice's. Suppose Bob has angered her somehow. Mallory can't sniff Bob's traffic, but then, she doesn't actually need to. Mallory can simply blindly provide some arbitrary data to the bank. It's garbage going out, but even garbage will decrypt into something. Unless the bank specifically has users provide some known plaintext in the outgoing data, it's going to "decrypt" that noise, using the password, into more noise.
Once again, outgoing data + bank password = incoming data. Mallory gets to do offline attacks too -- but against any user she wants.
Of course, the bank *could* put some sort of verifier in the message that Alice sends to it. But then Eve has an even easier time guessing passwords, since she just tries random passwords until the verifier is unveiled. No need to sniff the traffic back from the Bank (which is actually significant -- it means Mallory could firewall off the bank and still successfully participate in the auth protocol, with no way for the bank to find out.)
Anyway, long story short, broken. Really, really broken.
--Dan