Users often forget their passwords, so applications often must have a password reset mechanism. There are several options for how to do it; some of them are good, most of them not so good. Generate a password and send it in an email? No. Security questions? No way. Reset passwords via a phone call? Rather not. This talk presents some really creative examples of botched password reset implementations, as well as a proven method for resetting passwords securely.
I forgot my password – what a secure password reset needs to have and why
1. Talk about password resets, users, best practices,
and better future. Free speaker notes!
Michal Špaček @spazef0rze
2. Users forget their passwords because they are told to remember them and that's
hard. Did you ever forget your password? See, apps need to have resets.
3. Password reset mechanisms can also be good for the security of the user accounts.
Jabbim is a Jabber/XMPP server run by a Czech company. Unfortunately they
did not have automated password resets when they needed it the most.
4. December 2014
125k plaintext passwords
In December 2014 they suffered a breach and the attacker accessed 125k passwords
stored in plaintext, though Jabbim had their reasons for plaintext, like performance
and legacy client support. Data segmentation was also missing, but let's move on.
The leak wasn't made public, but the bad guy tried to sell it for a bitcoin or two.
5. No automated
password resets
The issue is that Jabbim doesn't have automated password resets because they don't
require users to enter email address during sign-up, so Jabbim can't send a reset
link. Their password reset mechanism is manual and that doesn't scale well.
6. In case of emergency
Issue a blog post
Jabbim could reset passwords immediately for all their users and send them reset
links via email, but this is what they did instead. Some of my friends lost access to
their Jabber accounts because somebody has changed their password before they
were able to read the blog post suggesting them to change their passwords.
They've eventually left the service because of “poor security practices.“
7. Your email maybe?
Because ¯_( ツ )_/¯
If an email address is not mandatory during sing-up it should be at least optional
and the benefits of adding one should be clearly stated. Breaches happen. Loosing
an account just because of one is another thing.
8. What are the benefits of adding an email? When something bad happens with one's
account or if the user forgets their password the service provider can send a link with
a random token to the email address provided and the user can set new password
once they click the link.
9. 1. Random 16+ bytes
2.Expiring in 1 or 2 hours
3.Usable once
The link should be random random, not just random, not time based, not a hash of
something, should expire in few hours max so that the chance of an attacker using
a leaked token is limited. The link should be usable only once for the same reason.
10. SHA-512
Hash the token with SHA-512 before storing it in a database. It doesn't need to be
a slow hash like bcrypt, because the token has a high entropy already and is limited
in time anyway.
11. Option to invalidate
&
IP address and city
The email with the reset link should also contain option to invalidate the token to
minimize the chance of an attacker gaining access to a valid link and reset user's
password. It should be also nice to include the IP address and the city from where
the request originated so that the user can tell if it was them or somebody else.
12. Sometimes, the bad guys use this password reset feature to see whether their
neighbor has been using the service as well so it might not be a good idea to
provide more information than needed, especially if you're running a dating site
for example. Most of the times it does not really matter because it's possible to
use sign-up flow to see whether the address is already registered with the site or
not. It's also important to limit the number of attempts to access password resets.
13. Don't generate and email new password. I've seen a site which always generated
new 5 characters long password, upper and lowercase letters only. In that case,
someone's strong password could be easily downgraded to a short one by just using
the password reset feature. Last but not least, don't send the original password.
You can't, you don't even know it because it's properly hashed, right?
14. token=encrypt(email)
This should be old news for every developer but obviously it's not. One of the more
interesting ways of doing a password reset was this. The token was an encrypted user
email address which got decrypted when sent back and then used to find the user.
That would be fine but the site was leaking source code and encryption keys too, so it
was possible to reset password for anybody. Just use a random token, seriously.
15. https://www.google.com/transparencyreport/saferemail/
The bad thing about email is shown above. Roughly half of the email traffic is not
encrypted as of August 2015. So even if the web app runs on HTTPS and the reset
link is also HTTPS there's still quite a high chance that anybody with some leet skills
can read the link while in transit. That's not what I'd call a secure password reset.
16. https://starttls.info
https://ssl-tools.net
You can use starttls.info or ssl-tools.net to see whether your email traffic is
encrypted and how good the encryption is. It's sort of like SSL Labs Server Check
for email. And even if you score grade A, it's still not end-to-end encryption, just
between servers, so your provider can still read your emails. Your account is
essentially protected by DNS. Someone can just hack your DNS servers and change
the MX records and reset links will go elsewhere. It's similar to SMS, that's not
secure much either.
17. https://www.facebook.com/me/about?section=contact-info
Facebook did this to work around insecure email. They allow you to upload your PGP
public key and then they will encrypt all the notifications they send to you, including
password reset links. Even if you probably won't use the password reset feature
because you use a password manager (right?) then this makes it impossible for the
attacker to reset your password even if they have access to the message with the reset
link because that is encrypted with your public key and only you can decrypt it.
18. Off-the-Record Messaging
https://otr.cypherpunks.ca/
Other option of doing end-to-end encryption to deliver the links securely could be
the OTR library. It's supported out-of-the-box on numerous instant messengers
and has plugins for few others. It can be used from eg. Node.js, Python, Go, and
Java. Your users would need to be “friends” with your app and once they are the
app can send the reset links securely to their instant messenger.
19. ☑ Disable password reset
Or you can just let users disable password resets completely. Just make sure you get
the messaging around that right, suggest using a password manager for example.
20. Disable
Insecure email
PGP email
OTR message
Save
Ideally, the app would let the users select preferred method of delivering the
HTTPS password reset link. More transports could be added, but some common
ones do not support automated sending very well or at all, like Skype for example.
21. Notify users of
password change
One thing the apps should definitely do is to notify the users when they or someone
else have changed their password. Again, clear copy is crucial. Might also be
interesting to require password change verification similar to two-step verification
or two-factor authentication, but I'm not sure yet how to handle cases like when the
device is lost etc.
22. oassword1
passwrod1
assword1
Michal Špaček @spazef0rze
www.michalspacek.cz
One last thing, when users forget their password just don't store the failed attempts.
Once the database leaks the correct password can be recovered easily, here the
password was Password1. Remember, think beyond just emailing links to people.
Editor's Notes
My name is Michal, I'm from Prague, CZ and I'm a web dev. I'd like to talk a bit about password resets on the web and users and best practices and near future.
Let's talk about users first. They forget things a lot. They also forget their passwords because they are told to remember them and that's hard. Did you guys ever forgot your password? Raise your hands. Obivously, apps need to have resets.
Password reset mechanisms can also be good for the security of the user accounts. Jabbim is a jabber/xmpp server run by a Czech company. Unfortunately they did not have automated password resets when they needed it the most.
In Dec14 they suffered a breach and the attacker accessed 125k passwords stored in plaintext. Jabbim had their reasons for plaintext like performance and legacy client support. They've also made some bad design desicions like missing data segmentation but yeah, let's move on. The data was not made public so far so that's the reason why you can't find it on haveibeenpwned.com
The issue here was that Jabbim does not have automated password resets because they don't require users to enter email address during signup so they say they can't send a reset link. Their pw reset mechanism is manual and that does not scale well.
Jabbim could reset passwords immediately for all their users and send them reset links via email, but this is what they did instead. Some of my friends lost access to their jabber accounts because somebody has changed their password before they were able to read the blog post suggesting them to change their pws. They've actually left the service for poor security practices.
If an email address is not mandatory during singup it should be at least optional and the benefits of adding one or two should be clearly stated. Breaches happen. Loosing an account just because of one is another thing.
What benefits of adding an email? When something bad happens with users account or if the user forgets their password the service provider can send a link with a random token to the email address provided and the user can set new password once they click the link.
The link should be random, not time based, not a hash of something, should expire in few hours max so that the chance of using leaked token is limited. And of course, the link should be usable only once for the same reason.
The token should be hashed before storing it in a database. It does not need to be a slow hash, because the token has a high entropy already and is limited in time anyway.
The email with the reset link should also contain an option to invalidate the reset link to minimize the chance of an attacker gaining an access to a valid link and reset users password. It should be also nice to include the IP address and the city from where the request originated so that the user can tell if it was them or somebody else.
Sometimes, the bad guys use this password reset feature to see whether their neighbor has been using the service as well so it might not be a good idea to provide more information than needed, especially if you're running a dating site for example. Most of the times it does not really matter because it's possible to use sign up flow to see whether the address is already registered with the site or not. It's also important to limit the number of attempts to access password resets.
This is what you don't want to do, don't generate and send new password. I've seen a site which always generated 5 chars just upper and lowercase letters when forgotten. In that case my strong password was pretty much useless. And obviously, don't send the original password because you don't even know it because it's properly hashed, right?
This all should be old news for everybody but obviously it's not. One of the more interesting ways of doing a password reset was this. The token was actually an encrypted user email address whichgot decrypted when sent back. That would be quite fine but the site was leaking it's source code and encryption keys too, so it was possible to reset password for anybody. Just use random token.
The bad thing about email is this. Roughly half of the email traffic is not encrypted. So even if the app runs on HTTPS and the reset link is also HTTPS there's a high chance that anybody can read the link while in transit. So that's not what I'd call secure password reset.
You can use starttls.info to see whether your email traffic is encrypted and how good the encryption is. It's sort of like SSLLabs Server Check for email. And even if you score grade A, it's still not end-to-end encryption, so your provider can still read your emails. Or you can just hack the DNS servers and change the MX records, your account is actually protected by DNS. It's similar to SMS, that's not secure much either.
This is what Facebook did. They allow you to upload your PGP public key and they will encrypt all the notifications they send to you, inluding password reset links. So even if you probably won't use the password reset feature because you use password manager, right? Then this makes it impossible for the attacker to reset your password even if they have access to the message with the reset link because that is encrypted with your pubkey.
Other option of doing end-to-end encryption could be the OTR library. It's supported out of the box on numerous instant messengers and has plugins for few others. It can be used from Nodejs, python, Go, Java. Your users would need to be friends with your app and once they are the app can send the reset links securely to their instant messenger.
Or you can just let users disable password resets completely. Just make sure you get the messaging around that right.
Ideally, the app would let the users select the method of delivering the HTTPS link. Just like this. More transports could be added, but some common ones do not support automated sending very well or at all, like Skype for example.
One thing the apps should definitely do is to notify the users when they or someone else have changed their password. Might also be interesting to require password change verification similar to two-stepverification or 2FA, but I'm not sure yet how to handle cases like when the device is lost etc.
One last thing, when users forget their password just don't store the failed attempts. Once the database leaks the correct password can be recovered easily. Remember, think beyond just emailing links to people.