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."
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.
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.
This basically verifies that the party you are conversing with knows your password, or something about it (i.e. has a salted hash of your password), _before_ you input your password. One could argue that this is more secure than (poorly-implemented) channel security via PKI as a man-in-the-middle would not have access to the accounts hash table unless the target system was compromised.
Interesting, but there are probably a million such things you can do to further tighten security.
Must-not-watch TV!
SSL (ideally) gives you the ability to do that, at least. I had one professor (giving network engineering / security classes) who said that at times, he actually called banks etc. whose websites he'd used and asked them to confirm the SSL certificate fingerprints etc. It always confused the hell out of them, but it worked. :)
quidquid latine dictum sit altum videtur.
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.
Could someone explain to me how you implement carbon paper, "magic envelopes" and invisible ink inside of a computer? seriously...
Also, it seems like you could come up with an algorithm to make password guesses based upon the numbers that were returned...trying different values that add up to zero. Or would this take too long?
And he is me, appearently
;-)
You take it in both ends then AC? I respect your i/o capabilities
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.
This proposed scheme does nothing to prevent a man in the middle attack. For example, if a person is trying to log in to a server, they would wait for the server to prove it knows their password before actually sending the password. But the man in the middle attaker could obviously just start a login attempt at the real server to get the appropriate hash of the user's password. But since anyone can get this hash, where is the security?
Mutual authentication sounds safe and warm. Alice know Bob is at the other end Bob knows Alice is at the other end.
However this is the situation after you have performed the mutual authentication, not before. In all protocols I have seen, this takes place in some order. In order for Alice to authenticate Bob's identity and the other way around, with both exchanges bound together (so differentiating from bilateral authentication), Either Alice or Bob has to first reveal their identity so it can be authenticated. This includes the proposed scheme.
This asks the question "Who goes first". Usually the protocol forces this issue and leaves one side or the other in the disavantageous position of identifying themselves first. This is analagous to the gatekeeper shouting "Halt! Who goes there?" to someone trying to enter. The person trying to enter is forced to go first and reveal themselves.
I may not want to reveal my identity to anyone, especially when it comes to say, wandering around in public with a wireless device. All sorts of tracking mechanisms become possible.
What we want is a "Who goes first protocol" so I can enforce my own policy on revealing my identity. If someone wants to sell to me, they had better go first. If I'm trying to get through a door, the building owner can reasonably expect me to go first. There are plenty of situations where a network may want to only reveal its identity to people who are allowed to know its identity, and noone else.
We already have the algorithms, but the protocols are stuck in the mud and prevent us from moving forward with security that offers more than what SSL gives us.
Evil people are out to get you.
Not if they block an IP rather than a login name, which is the smart thing to do (and the way it's been implemented where I've seen it).
p
In Korea, long hair is for old people!
And just how would you guess/know anyones' usernames , especially without also knowing their passwords?
Personally, my bank usernames look like a chunk taken out of some top-secret military encoded spy message--pretty much like the password that goes with it... I think it's a good practice to obfuscate usernames as much as passwords. It's about as likely that stream of space born gamma rays would trigger my account as it is that an actual person or computer would.
Constitutional rights may be respected, repealed, or modified; but they must never be ignored.
So nobody technical can tell if they've really done anything new or interesting, or if they've just done Yet Another Variant on mutual authentication that doesn't offer any advantages over existing techniques. MITM attacks aren't new, and needing twoway authentication for some applications isn't new, and using stolen passwords to crack machines isn't new, and using cracked machines to do Bad Things with isn't too new, though the popular approaches to cracking Windows machines don't usually bother with MITMing passwords because there are so many other back doors available. So what's new here?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
the problem here is that a webpage is not data but also program (i.e. javascript).
Alice could log in to the fake bank, and not realize that instead of doing the magic password trick, she's sending her password in plain text. Why? Because at the moment, the password encryption is (putting SSL aside) implemented by javascript!
To be safe, a key encryption algorithm would need an established software running it (in this case, the web browser).
This means:
a) having a W3-approved algorithm to be implemented in browsers, or
b) Having downloaded specific software by the bank (i.e. bankOnline browser(TM) or something).
WinXP (depending on configuration) will get continually longer lockouts, exponentially increasing. After 3 or 4 bad logins it's bearable but after 6 or 7 you're looking at 5 minute waits.
How many people can read hex if only you and dead people can read hex?
I've worked with a fair number of reporters; they're not coming up with something that complicated on their own. Hell, you're lucky if you can get like two sentences correctly quoted :) Only time you get that much technical writing in a row is if it's straight from the interview, and generally copied word for word from email.
Now, you're right. I could have taken that metaphor seriously. I could have gone ahead and pointed out, gee, they're basically describing a protocol in which the server XOR's arbitrary content from the client against the password (look real close at the "zero" and "more than zero" math. In bitspace, that's XOR). In this case, I can derive any password just by XORing two Bank->Alice/Bank->Mallory communications against one another.
But XOR is a simple encryption system, probably the only one you could hope to describe in the space alloted. So I gave them the benefit of the doubt; they weren't actually using a wildly broken cipher, just a seriously broken architecture.
First of all, if you can securely communicate with the server at some point (which is required for this to work - the bank needs your hash already) then you can simply use one time pads with rotating keys from that point forth... much more secure. Second of all, I don't know if his analogy to envelopes was just vague or if it really did accurately describe the protocol. If it did describe it accurately then what exactly stops me from standing in between the alice and her bank. Alice hands me her signed envelope, I hand it to the bank, the bank hands me the envelope with the magic numbers that sum to 0, I hand it back to alice. It doesn't matter if I ever knew what was in the envelope, Alice only knows that the authenticated envelope came from my hands. She now believes that I'm the bank. Another possibility is that perhaps by choosing numbers deliberately you could increase the probability that any summation will equal zero (or some predefined number), although I haven't verified that, its just one more thing to think about. I do believe this man just committed academic suicide if that paper is the only he has going.
Regards,
Steve