9 ms·

> hashes your username, service name, and master password Security through obscurity. You're essentially just using the same password on every site now.

dspillett 9y ago
Ish. If you use a sufficiently good hash function with a salt to stop rainbow table based attacks and key strengthening for good measure, then an attacker who has one compromised password of yours isn't going to be able to reverse the hash to find what your source password is so that they can generate new per-site passwords using it. That is assuming they even try: how would you know that an arbitrary string of characters was generated that way rather than just being randomly picked by a password manager? Of course all your accounts are compromised if someone knows your master password, but that is little different to an attacker getting your pass-word/-phrase for an online password manager that doesn't use some form of 2FA.
- IncRnd 9y ago
  No. This is not a cryptographic attack on the hash but on the text that is being hashed.
  - dspillett 9y ago
    But how would the text being hashed be attacked without either attacking the hash by brute force or knowing the master password (which is likely a human factors hack, to which online password managers are similarly susceptible?
    - IncRnd 9y ago
      Using hash functions in an attack is not the same as performing a cryptographic attack against the hash function. These are two different classes of attacks, both being real-world attacks. The attack being discussed is against a suggested formula to generate passwords. From the top of the thread, "a scheme that hashes your username, service name, and master password to generate a password." Discovering the password by determining the inputs to the hash function is all that is needed. This is the case even if a different type of function is used instead of a hash. Apologies, if I gave a different impression.
      - dspillett 9y ago
        Ah yes, I was thinking about the other end. Yes, this would be trivially susceptible to a simple dictionary attack if the user chose a bad master password, just as a plain password would. Introducing a good salt would stop that but then the salt would need to be stored and managed somewhere (securely synced everywhere you might need to regenerate a password - it can't be a public value or you are back to square one with the dictionary attack). You could also introduce a CPU and memory intensive key derivation function to frustrate the brute force attack a little but that is a race you won't win if you need the function to work on a low resource device and the attacker has a large cluster of processors and/or plenty of time to work with. It would protect against password reuse attacks even without the salt: if site1 stores plain passwords and leaks them then getting into my account on site2 becomes no easier than it already was if I had different passwords for each site (we are still looking at a brute force dictionary attack against the master password) so the scheme could work if the user has a sufficiently complex master key (and never needs to change that key). Making the master key complex enough but memorable is the challenge there, back to one of the core password related problems but at least with only one (or a few) to remember not one per account. Changing the master key once you believe it has been compromised would be quite some hassle in a similar way to if your master password for a service like 1password were compromised (worse: with a service like 1password you at least have a list of accounts to work down but with this scheme you need to remember them). An interesting though exercise, but I'm probably overthinking an unrecoverably weak idea...

dspillett 9y ago

Ish. If you use a sufficiently good hash function with a salt to stop rainbow table based attacks and key strengthening for good measure, then an attacker who has one compromised password of yours isn't going to be able to reverse the hash to find what your source password is so that they can generate new per-site passwords using it. That is assuming they even try: how would you know that an arbitrary string of characters was generated that way rather than just being randomly picked by a password manager? Of course all your accounts are compromised if someone knows your master password, but that is little different to an attacker getting your pass-word/-phrase for an online password manager that doesn't use some form of 2FA.

IncRnd 9y ago
No. This is not a cryptographic attack on the hash but on the text that is being hashed.
- dspillett 9y ago
  But how would the text being hashed be attacked without either attacking the hash by brute force or knowing the master password (which is likely a human factors hack, to which online password managers are similarly susceptible?
  - IncRnd 9y ago
    Using hash functions in an attack is not the same as performing a cryptographic attack against the hash function. These are two different classes of attacks, both being real-world attacks. The attack being discussed is against a suggested formula to generate passwords. From the top of the thread, "a scheme that hashes your username, service name, and master password to generate a password." Discovering the password by determining the inputs to the hash function is all that is needed. This is the case even if a different type of function is used instead of a hash. Apologies, if I gave a different impression.
    - dspillett 9y ago
      Ah yes, I was thinking about the other end. Yes, this would be trivially susceptible to a simple dictionary attack if the user chose a bad master password, just as a plain password would. Introducing a good salt would stop that but then the salt would need to be stored and managed somewhere (securely synced everywhere you might need to regenerate a password - it can't be a public value or you are back to square one with the dictionary attack). You could also introduce a CPU and memory intensive key derivation function to frustrate the brute force attack a little but that is a race you won't win if you need the function to work on a low resource device and the attacker has a large cluster of processors and/or plenty of time to work with. It would protect against password reuse attacks even without the salt: if site1 stores plain passwords and leaks them then getting into my account on site2 becomes no easier than it already was if I had different passwords for each site (we are still looking at a brute force dictionary attack against the master password) so the scheme could work if the user has a sufficiently complex master key (and never needs to change that key). Making the master key complex enough but memorable is the challenge there, back to one of the core password related problems but at least with only one (or a few) to remember not one per account. Changing the master key once you believe it has been compromised would be quite some hassle in a similar way to if your master password for a service like 1password were compromised (worse: with a service like 1password you at least have a list of accounts to work down but with this scheme you need to remember them). An interesting though exercise, but I'm probably overthinking an unrecoverably weak idea...