1

Suppose a password’s stored hash is exposed in a theoretical mass security breach of a popular service given the following assumptions:

  • The password is very long (30+ characters)
  • The password uses a full range of characters (94 possible alphanumeric + symbols) and does not follow a pattern
  • The password is a randomly generated string
  • The breached service stores the hashed password (using a secure hash algorithm)

Is this password practically impervious to offline attack since the only viable attack vector (brute force) would not be feasible due to the length of time required to guess the password?

I ask this because the common advice after a breach is to change your password immediately, however if one chooses a sufficiently secure password (say a randomly generated sequence of characters returned by a password manager) would this password remain secure even if it’s hash value has been leaked? Am I missing something fundamental in my understanding?

Improve this question
5
  • Your final assumption is a dangerous one to make. Even if the site was originally storing passwords in a secure manner, once it's known to have been compromised, can you be confident that no changes were made to the authentication code (or the front-end JS code) that would result in the unhashed passwords being obtained?
    – Gh0stFish
    Jun 10, 2022 at 21:50
  • Thanks, all the posters here have definitely cleared things up. You are correct that I had unconsciously also assumed that this is an offline attack and the attacker only has access to the hashed passwords, but you are correct that this is not at all a reasonable assumption to make as we cannot be certain the attacker has not compromised other parts of the system such that the unhashed passwords are also exposed.
    – Security student
    Jun 10, 2022 at 22:15
  • @Securitystudent And even if they weren't exposed, how do you know the site didn't also keep plaintext passwords, perhaps due to bad logging practices? In general, you have to assume that a compromised site is completely compromised.
    – forest
    Jun 10, 2022 at 22:16
  • @forest I guess the crux of my question was that in the strongest scenario where the site and user both strictly follow recommended password storage guidelines, and the attacker is able to get access to the stored password, is the password still vulnerable to attack. To which the obviously bad assumption I made was exactly what you stated, I assumed that only the password files were compromised.
    – Security student
    Jun 10, 2022 at 22:28
  • @Securitystudent Yep. As my answer (and bk2204's answer) describes, ~197 bits is plenty for data-at-rest security. It's so much that even use of a terrible hash like MD5 and no salting would be enough. It just has to have preimage resistance.
    – forest
    Jun 10, 2022 at 22:30

2 Answers 2

Reset to default
3

How secure your password is depends on how much entropy it has. If you have a 30-character password consisting entirely of English words, that has substantially less entropy than a password of 30 characters selected using a CSPRNG from all 95 printable ASCII characters. Also, if the RNG you used was seeded with (for example) just a 32-bit number instead of a properly seeded CSPRNG, then of course the entropy would be reduced (32 bits).

However, assuming that your password is picked out of a large set with a CSPRNG, then a 30-character password should be impervious to guessing. If you picked such a password out of the Base64 character set, it would have 180 bits of entropy, and if it used all 94 non-space printable ASCII characters, it would have 196 bits of entropy. 128 bits of entropy is considered sufficient for security these days, so those would well exceed that threshold.

Using a strong, unique password is a best practice, so in the event of a breach, it's likely that your account won't have been compromised if you've done so. This is the same reason that many sites which issue things like API tokens issue them with at least 128 bits of entropy: because they're effectively unguessable.

However, we recommend changing passwords anyway in a breach for many reasons:

  • Sometimes the attacker may have gotten access to the live system, and then they could just have sniffed the passwords out of memory.
  • Sometimes passwords accidentally get logged or stored in plaintext, and that may have happened with your password. If so, it may have been exposed.
  • Sometimes the attacker may have tried to change a password with their inappropriate access, and that may have resulted in unexpected credentials.
  • On some sites, external tokens and permissions can be expired by a password rotation, so by changing your password, you can make sure that any credentials the attacker may have issued against your account are invalidated.
  • Unfortunately, many sites store passwords in a negligent way, such as by storing plaintext in the database. In fact, if the site has restrictions on the allowed password characters or a length maximum shorter than 72 characters (which is the limit for some bcrypt implementations), then it's probably doing this. If so, then your password probably was exposed.

Most folks in the security field recommend using a password manager (e.g., 1Password), and most secure password managers offer a suitable password generation function, so normally in case of a breach, you can just generate a new secure password, change it, and not have to worry any more.

Improve this answer
0

It's safe only assuming the password was not sniffed in transit prior to being hashed.

A string composed of 30 random and independently chosen characters within a character set of 94 has a total of 9430 possible combinations. This gives log2(9430) ≈ 197 bits of security, which is plenty. It would not be immune to a computationally-unbounded adversary, but it will be immune in practice.

For such a large input, the hash would only have to be resistant to preimage attacks. Even hashes traditionally considered broken like MD4 and MD5 are not particularly vulnerable to preimage attacks. If the hash was not resistant, an attacker could calculate an input that hashes to the same value. They would not necessarily be able to find the original password, but they'd find one which, when fed into the same hash function, would result in the same hash as your real password.

would this password remain secure even if it’s hash value has been leaked?

Yes, but only assuming it is actually hashed and not stored in plaintext. You should still change your password after a breach though because you don't know if an attacker managed to backdoor the site and sniff passwords as they came in prior to leaking the (hashed) passwords.

Improve this answer
1
  • 1
    I actually didn’t think about that seemingly obvious attack vector at all in regards to this scenario. I suppose if the attacker has gotten access to the file containing the hashed passwords it wouldn’t be far fetched at all to assume the attacker has completely compromised the service and they may as well have captured your plaintext password via sniffing even if we can assume the passwords are stored properly.
    – Security student
    Jun 10, 2022 at 21:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .