It Is Time To Replace Passwords With Keys
It is time to stop using passwords. The Troy Hunt article, Passwords Evolved: Authentication Guidance for the Modern Era just got passed around the office again and wow, what a mess we are in. Instead of passwords we should switch to using public-key cryptography like TLS and ssh use.
"But people can barely manage passwords, there's no way they can manage keys!"
Wrong. People can't barely manage passwords, they can't manage them at all. Read the Troy Hunt article where he says, "Embrace Password Managers." We've given up on humans managing passwords and we are now relying on software to do it. We use software that securely stores our passwords and synchronizes them over the internet so that we have those passwords on all our devices. Often the software generates the passwords for us too. Guess what we could do with keys? The exact same thing.
Now read the Troy Hunt article again and this time think about how it's not just end-users that can't manage passwords, but how developers also cannot manage passwords. There are UI problems, there are concerns with code injection attacks, there are problems with hashing, salting, and storing passwords and with protecting those stored passwords from thieves. Those problems all go away if developers only have to store public keys. No hashing, no salting, no secrets. Think about it. As a user the only thing you'll give to a website to authenticate is your public key. You don't have to trust them with any secrets at all. From the point of view of a developer, you don't have to worry about keeping your customers secrets safe anymore. What a relief! As for UI, if we do it right websites and apps don't need any UI at all for authentication. What is the UI for TLS? The lock symbol that the browser displays. That's it! Websites you visit authenticate themselves to you using strong public-key cryptography behind the scenes, under the covers. It could be the same with user authentication.
Now read the article one more time and think about how not only are users and developers unable to deal with passwords, but security experts can't either. They can't agree on what makes a good secure password, what format it should be in. Special characters? Random strings of characters? Long passphrases of regular words? What's easier to create? Easier to type? Easier to memorize? Should a website show the password as users type it or not? How often should we change passwords? If we are giving up on memorizing and using password managers, does any of that matter? Maybe?
Now think about public-key cryptography. Security experts generally all agree on what makes good public-key cryptography, what format the keys should be in and what length. That was all hashed out years ago. True, there might be disagreement on when stronger keys should be used, whether to use RSA or ECC, and if ECC which curves to use and so on, but regular users relying on key manager software don't have to be involved in those discussions. They don't have to worry anymore about whether they should use a special character or how long of a password to use or if passwords made up of song lyrics are a good idea or not. The discussions on key size or which ECC curve to use raises the debate way beyond trying to figure out what is user friendly but still defeats rainbow tables and script kiddies. It takes the debate up to the level of wondering which nation state might attack you. If we eliminate human involvement in coming up with authentication tokens and remove script kiddies from the attack surface altogether that's a *huge* improvement over passwords.
"OK, but if we use public-key cryptography we also need to use full PKI like TLS."
Do we? PKI provides identity confirmation and key revocation. Do we have identity confirmation for account passwords today? When I create an account with, say, Amazon do they verify that I really am who I say I am? Nope. Not at all. They don't care one bit about who I really am. They just want my money. What about key revocation? Do we have password revocation today? Again, other than manually logging into a website and changing your password, we don't, and we can easily duplicate that manual process with keys in order to get us started. If we don't have full PKI with our public-key authentication we are no worse off than we are today.
The great thing about switching to public-key cryptography is that someday we could add in some sort of Let's Encrypt-like easy-to-use PKI if we want, which would take us light-years beyond where we are with passwords today. We aren't going to get there though if we don't take the first step of ditching passwords.
Getting rid of password authentication and using public-key cryptography instead will make user authentication easier for users, developers, and security experts, and it will make us all more secure.
"But people can barely manage passwords, there's no way they can manage keys!"
Wrong. People can't barely manage passwords, they can't manage them at all. Read the Troy Hunt article where he says, "Embrace Password Managers." We've given up on humans managing passwords and we are now relying on software to do it. We use software that securely stores our passwords and synchronizes them over the internet so that we have those passwords on all our devices. Often the software generates the passwords for us too. Guess what we could do with keys? The exact same thing.
Now read the Troy Hunt article again and this time think about how it's not just end-users that can't manage passwords, but how developers also cannot manage passwords. There are UI problems, there are concerns with code injection attacks, there are problems with hashing, salting, and storing passwords and with protecting those stored passwords from thieves. Those problems all go away if developers only have to store public keys. No hashing, no salting, no secrets. Think about it. As a user the only thing you'll give to a website to authenticate is your public key. You don't have to trust them with any secrets at all. From the point of view of a developer, you don't have to worry about keeping your customers secrets safe anymore. What a relief! As for UI, if we do it right websites and apps don't need any UI at all for authentication. What is the UI for TLS? The lock symbol that the browser displays. That's it! Websites you visit authenticate themselves to you using strong public-key cryptography behind the scenes, under the covers. It could be the same with user authentication.
Now read the article one more time and think about how not only are users and developers unable to deal with passwords, but security experts can't either. They can't agree on what makes a good secure password, what format it should be in. Special characters? Random strings of characters? Long passphrases of regular words? What's easier to create? Easier to type? Easier to memorize? Should a website show the password as users type it or not? How often should we change passwords? If we are giving up on memorizing and using password managers, does any of that matter? Maybe?
Now think about public-key cryptography. Security experts generally all agree on what makes good public-key cryptography, what format the keys should be in and what length. That was all hashed out years ago. True, there might be disagreement on when stronger keys should be used, whether to use RSA or ECC, and if ECC which curves to use and so on, but regular users relying on key manager software don't have to be involved in those discussions. They don't have to worry anymore about whether they should use a special character or how long of a password to use or if passwords made up of song lyrics are a good idea or not. The discussions on key size or which ECC curve to use raises the debate way beyond trying to figure out what is user friendly but still defeats rainbow tables and script kiddies. It takes the debate up to the level of wondering which nation state might attack you. If we eliminate human involvement in coming up with authentication tokens and remove script kiddies from the attack surface altogether that's a *huge* improvement over passwords.
"OK, but if we use public-key cryptography we also need to use full PKI like TLS."
Do we? PKI provides identity confirmation and key revocation. Do we have identity confirmation for account passwords today? When I create an account with, say, Amazon do they verify that I really am who I say I am? Nope. Not at all. They don't care one bit about who I really am. They just want my money. What about key revocation? Do we have password revocation today? Again, other than manually logging into a website and changing your password, we don't, and we can easily duplicate that manual process with keys in order to get us started. If we don't have full PKI with our public-key authentication we are no worse off than we are today.
The great thing about switching to public-key cryptography is that someday we could add in some sort of Let's Encrypt-like easy-to-use PKI if we want, which would take us light-years beyond where we are with passwords today. We aren't going to get there though if we don't take the first step of ditching passwords.
Getting rid of password authentication and using public-key cryptography instead will make user authentication easier for users, developers, and security experts, and it will make us all more secure.
Comments