Skip to content

Instantly share code, notes, and snippets.

Created February 23, 2022 20:29
Show Gist options
  • Save soanvig/eb7f912b820b51e77b431d4ceb4e4fd7 to your computer and use it in GitHub Desktop.
Save soanvig/eb7f912b820b51e77b431d4ceb4e4fd7 to your computer and use it in GitHub Desktop.
Password security

Password security analysis

This blog post should be suitable for both technical and non-technical people.

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.

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 password (that is used everywhere) is obtained by the attacker, it's best to change the password in all services where user is using the same password.

But at first, user must know, that such leakage happen. The later he/she knows, the worse.

Online services may hide this information from its users because they may don't want bad PR or they may think that they stored passwords in a secure way, so nothing bad happened (more on that later).

Also, user need to track information published by all 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.

Password storage

A service needs to store its user's password somewhere, and usually it is stored in a database.

The good practice among software developers is to hash password, before putting them into database. In short: hashing is an operation, that produces a very random string of characters (hash), based on original input, and the hash is always the same for exactly the same input. Even slightest change in the input, changes its hash completely. Also, you cannot compute original input from the hash: it's only one-way. The database can store 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:

  1. 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 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.
  2. 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.
  3. Guess the password (and therefore the hash if it is not salted) in a clever way. As long as rainbow tables just take pure brute-force approach to the problem, we can use tools like hashcat which along with attacker's experience can very quickly build hashes not of random characters, but popular words, numbers, combination 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 strong hashing function and salting alongside, we can be calm. Or can we?

Remembering all of them passwords

I've already described, that we all should use different password for each access. It's impossible to remember all of them, and that's where password managers come in.

Password manager is a tool that stores all passwords in one place, and expects the user to remember only one password (sometimes called "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 risk of security problem. And each of these features (and company itself) you have to trust - again, more on that later.

On single sign-on (SSO)

Instead of storing passwords inside password manager, we can use single sign-on (SSO), which 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 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. Do they? Also, such SSO providers, are very likely to be attacked, since successful attack will grant access to number of accounts at once.

Lack of encrypted connection

We all know padlock icon in our browsers. This means, that connection to service provider is using 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 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 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 connection to the VPN provider will be encrypted, if target service doesn't support encryption, information from VPN provider to this service will be send unencrypted. And we don't know what device is working between VPN provider's server and service's server. This gives false impression of security. And still - we have to trust VPN provider in such 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 his 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 situation even if we had the strongest password, used password manager, and 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 to remember, 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 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 lost 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 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 a form of 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 lock (public key) to anyone, any service. You own the only key that can open such 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 back this message to the service. This way 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 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 this possibility. And you never know, if they don't hide something nasty from you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment