3 ms·

> However, if you have a British Library login and your password is used elsewhere, we recommend changing it as a precautionary measure. So they store user pas

> However, if you have a British Library login and your password is used elsewhere, we recommend changing it as a precautionary measure. So they store user passwords. This is security 101 stuff.

vaidhy 3y ago
If you are not using oauth, you are storing a hash of the password somewhere, right? Even with all the precautions, it is likely that if your password is a dictionary word, it can be broken. Given most people might be choosing a simple password and people tend to reuse the same password across sites, it is worthwhile asking people to change it.
- BehindTheMath 3y ago
  Isn't the point of salting to prevent dictionary attacks? That's still auth 101.
  - vaidhy 3y ago
    Let us say you do unix style passwords - generate random salt and store the salt with the password. Hashcat can run through 54 billion md5 hashes/17 billion sha-1/7 billion sha-256 hashes on a single pc per second. Asking people to change the password as a precaution does not sound bad at all.
  - tgsovlerkhgsel 3y ago
    Salting slows down dictionary attacks. It doesn't make them impossible. If the site is able to verify a password with reasonable effort, an attacker that stole all relevant data is able to check a password with that level of effort. Without a salt, an attacker has to spend the effort once to check against all users' passwords. A salt doesn't meaningfully increase the cost to check against a specific user but slows down attackers (who want to check a password against all users), so yes, you should have it. Additionally, you should use "expensive" hash functions. If you use 28999 iterations of PBKDF2 with SHA256 (an example config that I found in a benchmark, far from the state of the art but likely still very common), that means trying the 1000 best guesses against your million users is 10000 * 1000000 * 28999 hash calculations. Unfortunately, a RTX 3090 can do 129400 sets of 28999 iterations per second, so trying the entire dictionary against all users will take less than a day (https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace72106d73fef#file-rtx_3090_v6-1-1-benchmark-L1200 https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace7210...). Even with a better algorithm, if you expect to be able to log in 100 users per second on your server (spending all resources on password hashing), the attacker will be able to test at least 100 passwords in the same time using the same resources (realistically more, because the attacker will likely have a better optimized setup, since their machine does nothing else but try passwords while yours is optimized for something else).
acdha 3y ago
That’s too vague to say that. It could also mean “we aren’t sure exactly when the attacker could have intercepted traffic” or “not everything uses the strongest possible hashing algorithm”. At a time like this, do you want people who are incredibly busy trying to guess whether the attacker has the resources to effectively attack every combination of hash algorithm, salt, etc. used anywhere at a large organization? If you’re suffering a catastrophic breach - I’ve heard at least a VMware host-level compromise – it’s likely that it’ll be hard to tell exactly how much or how long an attacker had access to, so giving conservative advice is better than having to later issue an update saying people who thought they were safe weren’t and your earlier advice means that the attacker had more time to try to compromise them. Changing passwords is much, much, much cheaper than recovering from a breach.
Daz1 3y ago
Stop victim blaming.

> However, if you have a British Library login and your password is used elsewhere, we recommend changing it as a precautionary measure. So they store user passwords. This is security 101 stuff.

vaidhy 3y ago

If you are not using oauth, you are storing a hash of the password somewhere, right? Even with all the precautions, it is likely that if your password is a dictionary word, it can be broken. Given most people might be choosing a simple password and people tend to reuse the same password across sites, it is worthwhile asking people to change it.

BehindTheMath 3y ago
Isn't the point of salting to prevent dictionary attacks? That's still auth 101.
- vaidhy 3y ago
  Let us say you do unix style passwords - generate random salt and store the salt with the password. Hashcat can run through 54 billion md5 hashes/17 billion sha-1/7 billion sha-256 hashes on a single pc per second. Asking people to change the password as a precaution does not sound bad at all.
- tgsovlerkhgsel 3y ago
  Salting slows down dictionary attacks. It doesn't make them impossible. If the site is able to verify a password with reasonable effort, an attacker that stole all relevant data is able to check a password with that level of effort. Without a salt, an attacker has to spend the effort once to check against all users' passwords. A salt doesn't meaningfully increase the cost to check against a specific user but slows down attackers (who want to check a password against all users), so yes, you should have it. Additionally, you should use "expensive" hash functions. If you use 28999 iterations of PBKDF2 with SHA256 (an example config that I found in a benchmark, far from the state of the art but likely still very common), that means trying the 1000 best guesses against your million users is 10000 * 1000000 * 28999 hash calculations. Unfortunately, a RTX 3090 can do 129400 sets of 28999 iterations per second, so trying the entire dictionary against all users will take less than a day (https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace72106d73fef#file-rtx_3090_v6-1-1-benchmark-L1200 https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace7210...). Even with a better algorithm, if you expect to be able to log in 100 users per second on your server (spending all resources on password hashing), the attacker will be able to test at least 100 passwords in the same time using the same resources (realistically more, because the attacker will likely have a better optimized setup, since their machine does nothing else but try passwords while yours is optimized for something else).

acdha 3y ago

That’s too vague to say that. It could also mean “we aren’t sure exactly when the attacker could have intercepted traffic” or “not everything uses the strongest possible hashing algorithm”. At a time like this, do you want people who are incredibly busy trying to guess whether the attacker has the resources to effectively attack every combination of hash algorithm, salt, etc. used anywhere at a large organization? If you’re suffering a catastrophic breach - I’ve heard at least a VMware host-level compromise – it’s likely that it’ll be hard to tell exactly how much or how long an attacker had access to, so giving conservative advice is better than having to later issue an update saying people who thought they were safe weren’t and your earlier advice means that the attacker had more time to try to compromise them. Changing passwords is much, much, much cheaper than recovering from a breach.

Daz1 3y ago

Stop victim blaming.