4 ms·

Properly hashed/salted passwords are considered safe to store in a database. You still wouldn’t want them to be stolen, but they are not in plaintext. There are

by orev 6y ago

Properly hashed/salted passwords are considered safe to store in a database. You still wouldn’t want them to be stolen, but they are not in plaintext. There are other times when you do need to store secrets that you need to be able to decrypt so you can use them.

eyelidlessness 6y ago
Nothing is considered safe, and everything is considered borrowed time if you're storing encrypted data. Retrievable data isn't any less encrypted than hashes, it's just a bidirectional encryption.
ithkuil 6y ago
It all depends on two factors: a) minimal required entropy of the passwords themselves. b) how computation expensive is the hash function itself. The threat model in password bashing scenario is that the attacker wants to discover the password and then use it to impersonate the user. Thus the attacker needs to guess the password, by searching though the space of all possible passwords (using heuristics such as dictionary, common letter/number replacements, common position of symbols mandatory in many password policies) and the the candidate password needs to be hashed and compared to the known good hash. By using an expensive hash function such as bcrypt you can limit the ability of exhaustively search the space of all possible passwords. But if a user uses a weak password, the attack will succeed and leaking the hashes will make the search go several orders of magnitude faster than online brute forcing (I.e real login attempts, which can be throttled)
- e12e 6y ago
  c) the fact that in the real world, some users will re-use "secure" passwords.
  - ithkuil 6y ago
    In the real world this reduces password entropy, thus it falls under (a) :-) EDIT: perhaps it would be easier to just think of it in terms of predictability. Often tech jargon gets in the way.
    - e12e 6y ago
      Yes and no. You could argue the infamous Debian openssl bug reduced entropy [1], but it really is about compromised keys. Or in this case compromised passwords. [1] in a sense, this is of course obviously and literally true (that it is about entropy). But I think the more interesting distinction is between leaked secrets, and "bad" secrets - in that light the "Debian keys" all form a group of "leaked" secret keys. There's nothing inherently wrong with the generated keys - but you'd have to improbably unlucky to "accidentally" generate any given compromised key using a good rng. In the same way, the password "TGSCfkL$seG2@tn5DowiFJ$nPj%KW#vMT" that bitwarden just generated for me isn't inherently bad - until now, that it's been published/leaked. So I'm not sure I agree that it's all/only about entropy. I think it illustrates well that secrets and especially those managed by people (such as passwords and passphrases) have systemic component: the system seen as a whole incorporates users, other systems as well as any one given system (Gmail is affected by leaked Hotmail accounts, and vice-versa).
      - ithkuil 6y ago
        I'm not disagreeing. I just wanted to highlight to to break a password you need a) to guess it b) to verify it. Leaking the hashes affects (b)

by orev 6y ago

eyelidlessness 6y ago

Nothing is considered safe, and everything is considered borrowed time if you're storing encrypted data. Retrievable data isn't any less encrypted than hashes, it's just a bidirectional encryption.

ithkuil 6y ago

It all depends on two factors: a) minimal required entropy of the passwords themselves. b) how computation expensive is the hash function itself. The threat model in password bashing scenario is that the attacker wants to discover the password and then use it to impersonate the user. Thus the attacker needs to guess the password, by searching though the space of all possible passwords (using heuristics such as dictionary, common letter/number replacements, common position of symbols mandatory in many password policies) and the the candidate password needs to be hashed and compared to the known good hash. By using an expensive hash function such as bcrypt you can limit the ability of exhaustively search the space of all possible passwords. But if a user uses a weak password, the attack will succeed and leaking the hashes will make the search go several orders of magnitude faster than online brute forcing (I.e real login attempts, which can be throttled)

e12e 6y ago
c) the fact that in the real world, some users will re-use "secure" passwords.
- ithkuil 6y ago
  In the real world this reduces password entropy, thus it falls under (a) :-) EDIT: perhaps it would be easier to just think of it in terms of predictability. Often tech jargon gets in the way.
  - e12e 6y ago
    Yes and no. You could argue the infamous Debian openssl bug reduced entropy [1], but it really is about compromised keys. Or in this case compromised passwords. [1] in a sense, this is of course obviously and literally true (that it is about entropy). But I think the more interesting distinction is between leaked secrets, and "bad" secrets - in that light the "Debian keys" all form a group of "leaked" secret keys. There's nothing inherently wrong with the generated keys - but you'd have to improbably unlucky to "accidentally" generate any given compromised key using a good rng. In the same way, the password "TGSCfkL$seG2@tn5DowiFJ$nPj%KW#vMT" that bitwarden just generated for me isn't inherently bad - until now, that it's been published/leaked. So I'm not sure I agree that it's all/only about entropy. I think it illustrates well that secrets and especially those managed by people (such as passwords and passphrases) have systemic component: the system seen as a whole incorporates users, other systems as well as any one given system (Gmail is affected by leaked Hotmail accounts, and vice-versa).
    - ithkuil 6y ago
      I'm not disagreeing. I just wanted to highlight to to break a password you need a) to guess it b) to verify it. Leaking the hashes affects (b)