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.
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.