4 ms·

No. This is not a cryptographic attack on the hash but on the text that is being hashed.

by IncRnd 9y ago

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...

No. This is not a cryptographic attack on the hash but on the text that is being hashed.

by IncRnd 9y ago

No. This is not a cryptographic attack on the hash but on the text that is being hashed.

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...