Users over the world gazillion times per day sign-in to various services using password.
On my own, I control over 100 passwords for different access purposes.
Let's discover what can go wrong.
This blog post should be suitable for both technical and non-technical people
Using the same password everywhere
The starting point would be to use the same password everywhere.
To some, this may sound like a good idea. At least it’s easy to remember.
But no software is considered ultimately secure.
Password database leakages happen. Have I Been Pwned keeps track of password leakages.
If such a password (that is used everywhere) is obtained by the attacker, it’s best to change the password in all services where the user is using the same password.
But first, the user must know, that such leakage happens. The later he/she knows, the worse.
Online services may hide this information from their users because they may not want bad PR or they may think that they stored passwords in a secure way, so nothing bad happened (more on that later).
Also, the user needs to track information published by all the services that he is using, which is virtually impossible, although there exist services like Firefox Monitor which automate this process.
Therefore, it is a bad idea to use the same password everywhere. At least a user can dodge the bullet, and have only one account compromised, instead of all of them, if a unique password is used for all services.
A service needs to store its user’s password somewhere, and usually, it is stored in a database.
A good practice among software developers is to hash passwords, before putting them into the database.
In short, hashing is an operation, that produces a very random string of characters (hash), based on the original input, and the hash is always the same for exactly the same input.
Even the slightest change in the input changes its hash completely. Also, you cannot compute the original input from the hash: it’s only one-way.
The database can store the user’s hash, when the account is created, and then, during login, compare given hashed input, with the hash stored in the database.
This way, the password, even when leaked, is effectively unusable for the attack. Or is it?
There are basically three attacks, that can be performed, when the attacker has access to the hashed version of the password:
- Rainbow table attack. An attacker (or all of them in cooperation) can use a precomputed list of hashes for every possible string combination, and then look for the hash in such a list. The answer to this problem is another good practice that can be used by software developers: salting. Salting basically means adding any long-enough and random-enough string of characters to the user password before hashing (and before comparing). Salt does not have to be obfuscated. This way, the password will have a completely different hash, and probably won’t be present in the rainbow table.
- Exploit security issues of the hashing method itself. Hashing is based purely on math. And in math, often there are shortcuts to achieve the same result. The same applies to hashing functions. If the hashing function is not strong enough (and usually modern enough), then an attacker can very quickly compute (by guessing) the password that produces some particular hash.
- Guess the password (and therefore the hash if it is not salted) in a clever way. As long as rainbow tables just take a pure brute-force approach to the problem, we can use tools like hashcat, which along with an attacker’s experience, can very quickly build hashes not of random characters, but of popular words, numbers, combinations of those and so on. This is nicely described in video by Computerphile.
So if we can trust the service provider (remember this emphasis, since it will be important later on), that it is using a strong hashing function and salting alongside, we can be calm. Or can we?
Remembering all of the passwords
I’ve already described, that we all should use a different password for each access.
It’s impossible to remember all of them, and that’s where password managers come in.
A password manager is a tool that stores all passwords in one place, and expects the user to remember only one password (sometimes called a “master password”), that is used to access all other password.
Password managers usually have very useful features. Do you need all of them? Each useful feature makes application more complex, therefore increasing the risk of security problems. And each of these features (and the company itself) you have to trust them – again, more on that later.
On single sign-on (SSO)
Instead of storing passwords inside a password manager, we can use single sign-on (SSO), which is a technique of passing user verification to another service.
For example, if we want to log in to a given site, sometimes there is an option to “Sign using Google” or “Sign using Facebook“. That’s basically SSO.
This is actually an excellent technique, and I have almost nothing bad to say about it.
First – we don’t have to trust a service provider to securely store our password. It is not storing it at all.
When we want to change a password for any reason, we change it in one place, and we’re done.
Instead, we only have to trust Google or Facebook, and such big companies have the highest security standards, or do they?
Also, such SSO providers, are very likely to be attacked since a successful attack will grant access to a number of accounts at once.
Lack of encrypted connection
We all know the padlock icon in our browsers. This means that the connection to the service provider is using a secure (encrypted) connection. But what does it mean?
Whenever we send (for example, login information) to another server (website) it gets encrypted. This prevents man-in-the-middle attack. Who is this man in the middle?
When we establish a connection to the given server, information is not sent there directly (unless our device is connected directly to it). Multiple routers, ISP-providers, and other devices are in-between, and redirect requests to each other, until finally it gets to the target.
If connection is not encrypted, each of these devices can look into the information we send. Therefore, each of these devices can steal our password.
This becomes especially dangerous if we are using public WiFi networks.
Hey, I’m using VPN bro, I’m secured, no worries! :-)
Well, yes and no. While the connection to the VPN provider will be encrypted, if the target service doesn’t support encryption, information from the VPN provider to this service will be sent unencrypted.
And we don’t know what device is working between the VPN provider’s server and the service’s server. This gives a false impression of security. And still, we have to trust the VPN provider in such a case.
Providing a password every time the user wants to use the service is troublesome. That’s why services often provide a feature called “remember password”.
Well, the name is kind of misleading, because surely the password is not “remembered” anywhere (hopefully) – usually some access token is stored alongside its expiration time, after which the user will have to use their password once again.
But this remember password feature is actually another security hole.
What if somebody can have access to the device with password remembered? An attacker can have such access through a trojan virus or just have the access physically (e.g. when a device is lost or left unprotected in a public space). In such a situation even if we had the strongest password, used a password manager, and the password was stored securely by the service provider, the attacker got access to our account.
All in the name of convenience. Unfortunately, convenience and security typically go in the opposite direction.
That’s something worth remembering, to at least take the risk consciously.
And then comes the trust. In my opinion, the most important factor in account security.
It seems that you have to trust a service provider to securely store your password, or trust a password manager to securely store/encrypt/send to you your password.
But how much trust can be put into companies, that prefer centralization and authoritarian (not to say totalitarian) control over their users?
- What guarantee do we have, that our password manager account won’t be locked for any reason, and we’ll lose all of our passwords?
- What guarantee do we have, that everything is stored securely, when we actually cannot check how it’s stored?
- What guarantee do we have, that service provide doesn’t have bugs, that allow to access account without password at all?
Well, as long as we physically don’t store anything by ourselves, we don’t have any guarantee that something bad won’t happen.
And that’s something, that everyone has to take into account, and unfortunately, this mindset is not very popular these days.
Quite the opposite, despite the network being more and more present in our lives.
We are storing everything in the cloud, not understanding how anything works, and we are happy.
While we may not be able to give up on some external services, and we just may have to trust them, we can do something about storing our passwords.
What to do?
First is to store our passwords locally (in the form of an encrypted backup, or just by using an offline password manager like Pass which I highly recommend, although it requires some technical knowledge to make the best use of), so we are independent – another word probably already forgotten nowadays.
Another, unfortunately not widely supported, possibility is to use keys (software or hardware based ones) that implement asymmetric encryption (build of public and private key concept)
To illustrate in a simple way asymmetric encryption login, imagine envelope, lock, and a key. You give such a lock (public key) to anyone, any service. You own the only key that can open the lock (private key).
The online service has your lock (and so anyone can have one), and it can send you a message in the envelope (encryption) locked with this lock. You open it on your computer, see what’s inside, and send this message back to the service. This way, the service knows, that you are you (private key owner), and not someone else, because you were the only one to see what’s inside the envelope.
In practice, this technique is actually used in a reversed (and more technical) way: a service sends you a message, you encrypt this message, and send the encrypted message back – and they are able to decrypt it.
Yet another way to improve security is to use an open source software (OSS) password manager, if you are using a password manager at all.
And I’m not saying, that OSS is more secure, but at least you have the possibility to check, whether something is stored securely or not.
Using VPNs, popular password managers, or SSO (Google, Facebook, etc.), you don’t even have this possibility. And you never know, if they don’t hide something nasty from you.
Author: Mateusz Koteja