![]() If this was all we required, PAKE protocols would be easy to build. For obvious reasons, the password, or a hash of it, is assumed to be already known to the server, which is what allows for checking. The distinguishing feature of PAKE protocols is the client will authenticate herself to the server using a password. The earliest key exchange protocols - like classical Diffie-Hellman - were unauthenticated, which made them vulnerable to man-in-the-middle attacks. What’s a PAKE?Ī PAKE protocol, first introduced by Bellovin and Merritt, is a special form of cryptographic key exchange protocol. Key exchange (or “key agreement”) protocols are designed to help two parties (call them a client and server) agree on a shared key, using public-key cryptography. The cryptographic tool that can give this to us is PAKE, and in particular a new protocol called OPAQUE, which I’ll get to at the end of this post. But it does demand a better solution: one where the user’s password never has to go to the server in cleartext. Now, the login problem doesn’t negate the advantage of password hashing in any way. For example, earlier this year Twitter asked all of its (330 million!) users to change their passwords - because it turned out that company had been logging cleartext (unhashed) passwords. ![]() This requirement can lead to disaster if your server is ever persistently compromised, or if your developers make a simple mistake. When the user comes back to log into your website, they will still need to send over their (cleartext) password, since this is required in order for the server to do the check. Regardless of the approach you take, all of these solutions have a single achilles heel: ![]() There are various arguments about which hash function to use, and whether it could help to also use some secret value (called “ pepper“), but we’ll ignore these for the moment. There are many schools of thought on how to handle the hashing process the most common recommendation these days is to use a memory-hard password hashing function like scrypt or argon2 (with a unique per-password salt), and then store only the hashed result. The traditional way to do this is to hash each user password and store the result in a password database. Imagine I’m operating a server that has to store user passwords. To understand why this is such a damn shame, let’s start by describing a very real problem. It should be deployed everywhere, and yet it isn’t. The second rule of PAKE is that this is a shame, because PAKE - which stands for Password Authenticated Key Exchange - is actually one of the most useful technologies that (almost) never gets used. ![]() The first rule of PAKE is: nobody ever wants to talk about PAKE. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |