Show HN: A simple “stateless” password manager for Chrome • Hacker News Board

Re: Show HN: A simple “stateless” password manager for Chrome

#51

Post by dannysu » Tue, Dec 30, 2014, 3:05 AM UTC

There are many of this type of hash function based generators, but pretty much all use fast hash functions. The no salt thing also makes me uneasy.

From another Ask HN[0], I learned about bpasswd[1] which does bcrypt and allows the cost (iterations) to be configured. That looks pretty cool.

For me, I chose to go with a hybrid approach and wrote hash0[2] for my less important passwords (important ones live in KeePass). Hash0 does 100,000 iterations of PBKDF2 with salt from CSPRNG unique for each site. It stores the encrypted metadata (just the salt, length, symbol/no symbol, etc) at a location of your choosing (I just store it in my Google App Engine).

Would love to get more eyes on it and get feedback (See services.js for generation logic).

Benefits of hybrid are that:

  - Allows me to use random salt
  - Allows me to easily change password for individual sites (thanks for random salt)
  - Allows me to store website's preferred password length and whether to use symbols or not
  - Allows me to create mappings (so say www.twitter.com and account.twitter.com can use the same password)
  - Allows me to store notes along with the metadata (e.g. what username I used)

[0]: https://news.ycombinator.com/item?id=8753534

[1]: http://www.alexhornung.com/code/bpasswd/

[2]: https://github.com/dannysu/hash0

Re: Show HN: A simple “stateless” password manager for Chrome

#52

Post by dannysu » Tue, Dec 30, 2014, 3:14 AM UTC

kijin wrote: post #47

As usual, purity is overrated. The #1 benefit of a purely stateless password manager is that there is no password database, so your password database cannot be compromised. The drawback, as others have mentioned, is that it's difficult to use strong salts without keeping some sort of database. Changing passwords also becomes a big hassle. But what about a compromise? Keep a database, but only store the salts in the d…

I pretty much wrote hash0 (https://github.com/dannysu/hash0) for most reasons you listed. Would love more auditing if you're interested to take a look.

Re: Show HN: A simple “stateless” password manager for Chrome

#53

Post by SwellJoe » Tue, Dec 30, 2014, 3:47 AM UTC

moe wrote: post #50

SwellJoe wrote: post #49

Earlier quoted context omitted.

It sounds like you're asserting that Bitcoin is not secure because it uses SHA-256. i.e. a pass phrase that has been hashed with SHA-256 could be brute forced to find the master passphrase, thus, a Bitcoin private key could be compromised by a brute force attack. That's an extraordinary claim. (I'm not gonna argue too strenuously about MD5 being somewhat dangerous in this context, as it is very easy to find collision…

It sounds like you're asserting that Bitcoin Don't put words in my mouth, I never suggested anything like that. In Bitcoin the private key is derived from the public key which is normally randomly generated and not provided by the user. The browser 'password manglers' mentioned here instead derive it directly from the password provided by the user. That is a big difference. Most users don't choose a password of suffi…

So, pass phase length and strength is the concern here? If a human were to generate a reasonably strong pass phrase (say 25 characters), would that mitigate the problem? (Certainly this is stronger than a memorizeable unique password for every site, but I'm willing to believe I should do better.)

What does a good password manager look like if not this?

Re: Show HN: A simple “stateless” password manager for Chrome

#54

Post by moe » Tue, Dec 30, 2014, 4:17 AM UTC

SwellJoe wrote: post #53

moe wrote: post #50

Earlier quoted context omitted.

It sounds like you're asserting that Bitcoin Don't put words in my mouth, I never suggested anything like that. In Bitcoin the private key is derived from the public key which is normally randomly generated and not provided by the user. The browser 'password manglers' mentioned here instead derive it directly from the password provided by the user. That is a big difference. Most users don't choose a password of suffi…

So, pass phase length and strength is the concern here? If a human were to generate a reasonably strong pass phrase (say 25 characters), would that mitigate the problem? (Certainly this is stronger than a memorizeable unique password for every site, but I'm willing to believe I should do better.) What does a good password manager look like if not this?

A good password manager generates a new, strong, random password for each site, stores them in a file and encrypts the file with a key that is derived from a user provided password via one of the aforementioned methods (PBKDF2 or scrypt).

This lets the user change his master password without invalidating all stored passwords and the compromise of any single or multiple site passwords does not affect the master password in any way.

And since the password-file is encrypted it can also be trivially backed up and synced across devices using any untrusted transport (e.g. Dropbox).

As it happens, this is exactly how the common solutions (KeePass, LastPass) operate. This part of the wheel is in no need to be re-invented poorly.