Open pv opened 9 years ago
Can you explain how a method like pbkdf2 or scrypt should work in this scenario?
Methods like scrypt use a random salt for computing a key. If I want to generate the same key again this salt would be needed. Because of it being random I have to save it on the first run.
The problem is: I don't want to store so many things. So users can give in the settings a fixed salt which is the same on any password. When I store random things which the user can't remember they would need the same data everywhere they need to generate passwords (smartphone, laptop, desktop, internet cafe, ...). So syncing would be a problem then..
If I misunderstood how password based key derivation functions work please tell me, I would be happy to improve batagur. If not I think keeping the fixed salt in the settings and up to 1111 (can be set anything higher, eventually I will change the slider to a textbox) SHA512 iterations should be good enough for the next time.
You could derive the salt from the site-specific token, eg sha of the token, plus any user specified salt. The point here would be to replace your custom iterated-sha kdf with a standard kdf.
Note also that the owasp recommended iteration counts are 60000 or so, quite larger than what the app currently allows.
Note though, that I'm not a crypto specialist, so best to check the suggestion yourself too.
The app should use a key derivation function, and not a sha hash. Standard functions here are pbkdf2 and scrypt.
The attack is as follows: suppose you use the generated password on a malicious site, day, foo.com. The attacker knows the generated password, and can guess with high probability the token. Then, it is possible to bruteforce the master password.
Currently, the sha hash iterated a small number if times is probably too fast to protect against this. It would be better to use a standard approach, and calibrate the iteration count so that computation takes long enough, eg one second.