Delayed Password Disclosure 163
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."
Re:An okay article, I guess.... (Score:1, Informative)
Re:I don't see how this could work... (Score:4, Informative)
I believe that, in this case, Alice could generate the contents of said envelope with her public key, then send both the envelope and the key to the remote host. That host would respond with its positions, encrypt those with Alice's public key as well, and return the whole bunch to Alice who then decrypts everything with her private key.
There's something missing in my speculation -- why does Alice need to send anything but her public key?
Re:An Opportunity to Rant. (Score:4, Informative)
That was called SET. It failed because it was expensive and credit card fraud is already pretty low.
Secure Remote Password (Score:5, Informative)
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 [stanford.edu]
Actually Pretty Vulnerable (Score:5, Informative)
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
Re:And this is new how??? (Score:5, Informative)
It actually provides a technique of verifying th authenticity of a host with whom your computer has never communicated. The host, presumably, knows your password (or a salted-hash representation). The host either obtained this via connection with another computer at some time in the past, or by some information that you provided when signing up for whatever the service is (think bank). The host uses what it knows about your password to send you specially encoded information that, in combination with what *you* also know about your password can be used to verify that at the very least you aren't giving your password to a system that doesn't already have that information. You can also think of this method as a decent way to validate RSA fingerprints by a system that hasn't already been seeded with pre-shared keys.
Strong Password Authentication (Score:3, Informative)