How not to do a password manager(bughardy.me)
bughardy.me
How not to do a password manager
https://bughardy.me/at-this-rate-it-will-hit-the-launch-codes-in-5-3-minutes/
1 comments
I do not completely agree with you.
Yes, the problem is still there even with scrypt or any strong hashing function. But the (s/the/one) problem here is the use of a simple PIN code ( from 4 to 8 digits ), to store securely your passwords! Why can't we set up a passphrase instead? And then use scrypt. Morover, I think that PBKDF with 10'000 iterations, as advised by OWASP (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet), is better than clear-text; also if you consider just an 8 digits PIN code. Just my opinion.
Yes, the problem is still there even with scrypt or any strong hashing function. But the (s/the/one) problem here is the use of a simple PIN code ( from 4 to 8 digits ), to store securely your passwords! Why can't we set up a passphrase instead? And then use scrypt. Morover, I think that PBKDF with 10'000 iterations, as advised by OWASP (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet), is better than clear-text; also if you consider just an 8 digits PIN code. Just my opinion.
However the articles primary complaints (that the pin is retrievable, and that the password database is recoverable) is always true no matter how well implemented it was. The entire concept of the application depends on Android's file permissions to stop other apps looking at the database. Once apps bypass that security, recovering the passwords is an eventual inevitability.
The pin is likely just there to stop friends & family from accessing it. The same way Android's pins and patterns aren't really "security features" as much as to stop friends and family (and casual thieves).
So overall the article isn't wrong, but even if the author fixes all of their complaints (and replaces DES with something actually secure), the app wouldn't actually be much better because the same concepts are the backbone of the security.
This all boils down to the author's decision to use a pin. If a four digit pin is the entire basis for security then it can never be made secure, even if it is hashed, even if it is encrypted, and so on. There's no number of BCrypt factors you can set to make a four digit combination secure.
So for the author to make the app more secure they would have to require the user enters a long password, but I get the sense that isn't their USP looking at their app page. Their USP is the fact it only requires a four digit pin, so therefore that is that.
The author could store the pin in a decent hash, and then encrypt the password database using e.g. AES256 but ultimately a four digit pin is a four digit pin. You cannot really fix that unless there is an actual hardware interlock (e.g. chip that checks the number and burns out after too many bad tries).