Every few weeks or so, a technical person on Twitter mentions to a business that they shouldn’t be receiving their login details in an email. It’s bad practice and not secure they scream… and the businesses carry on.
In this post, without being technology specific or going into too much technical detail, I’m going to highlight what sending passwords in emails says about these companies’ systems, why it’s not secure and what I think they should be doing instead.
First, a little background; email hasn’t fundamentally changed since the 1980s and is mostly unencrypted by default. As of last year, Google reported that 50% of the emails between them and other providers was unencrypted.
The passwords that businesses email are sent through in clear text, which means they can be easily intercepted and harvested on their way between you and the email servers. Passwords are vulnerable even if transferred over encrypted connections, as they’ll likely just sit in a person’s inbox forever, waiting to be compromised by any hacker smart enough to use a search function.
It’s also worthwhile mentioning at this point that most people use the same password for everything. Do yourself a favour and search for your favourite password in your email, you might just be unpleasantly surprised.
If you’re the type of person who doesn’t do this and knows better, this article isn’t for you. It’s actually not for anybody, I’m trying to stretch other parts of my brain by writing… So if you’re about to adjust your fedora, stroke your neckbeard and comment to tell us why everybody is a dumbass, why don’t you go write your own article instead?
The largest companies in the world have had their services compromised, so no company is special. This is a good time to recommend that you head over to haveIbeenpwned.com to check if your email has been previously pwned in any documented breech.
Anyway, the point of the post isn’t to explain why having your login credentials compromised could be a bad thing. I’ll leave that to your imagination…
…
But Brett, I hear you saying, businesses still need to send their clients a password so they can authenticate? If email isn’t secure, what are they supposed to use to send the clients their password? If you have a better way to do it, then just get on with it and tell us?
I will! They don’t send a password. In fact, they shouldn’t even store passwords in a way that they can access the original at all.
Story time!
A company sends you a mail containing your password or even a password they’ve generated. What does receiving the password in an email tell us about their IT systems?
It highlights that they’re storing the data in such a way that it’s retrievable. That means there is a large bucket with passwords on a server somewhere that somebody has access to.
Don’t worry, the database is encrypted!
So what? I rebut… Even if the mechanism is encrypted, there exists a way to generate an email containing the password. The passwords are available to somebody somehow and that means they can be compromised. That system is inherently insecure by design. If you have access to the user’s password, it can still be leaked, no matter how careful you are.
The only way the password can be properly secure is if the business themselves can’t read it at all! There is no liability if it isn’t possible to access the password. This is accomplished by storing the password in a format where it can’t be reversed into the original text.
But Brett, if they can’t read the password then how are they going to validate the password when you try login? They need that data, there isn’t really any way around that, is there?
They don’t need to know your password, nor do they need to be able to decrypt your password, to validate that it’s correct.
Time for some technical stuff;
I think this process should be used instead of sending the password via an email:
- User signup process creates a new account that isn’t active by default.
- Send user an email with a URL to a managed server-side process to activate the account and create a password.
- Link containing a uniquely generated token that can either only be accessed once or expires in a very short period of time (less than 15 minutes).
- Connection to this process must be secure using HTTPS (SSL/TLS) (duh…)
- User enters password of their own creation into process (don’t auto-generate passwords!)
- The user defined password is randomly salted and hashed using a one-way algorithm.
- The resultant hash and the random salt are then stored for later verification
TLS, Hashing, Salting? You said not much technical detail!? (Wikipedia links for people who care to do the research)
These terms briefly explained in one paragraph.
TLS: Transport layer security, means the connection from a client to a host is encrypted.
Hashing: Transformation of a series of characters into a smaller key. The same input always generates the same hash. There are multiple hashing algorithms all with their pros and cons.
Salting: It’s the act of adding another random value (the salt) to the original key value (the password) so that when you hash the same password with two different salts, the hash results are different.
Salting and hashing is a one-way process. You can’t infer the original password from the hash, which means that even if their data is compromised the attacker won’t have access to the password.
This means that the login process would now work as follows:
User accesses a login process over a secure connection.
Password is sent to server, where it is salted with the previously generated random salt, and hashed with the chosen algorithm. The resultant hash is compared to the stored hash and viola… validation.
Moral of the story. You don’t store passwords so that when you’re compromised your passwords aren’t leaked.
…
A few more technical people will say this article isn’t complete and the mechanism mentioned above isn’t actually secure yet… and they’re right! If the data gets leaked and the attackers have access to both the hashes and the original salt values, they can brute force the passwords over time to crack them. Ways to make the system more secure to get around that are beyond the scope of this post. If you’re looking to this post for any architectural guidance, you really really shouldn’t be… I would suggest reading up elsewhere.
Securely creating accounts, storing passwords and authentication is only one small part of keeping a system secure too.
