Hacker News Reader

Comment by stepstep | Hacker News Reader

Just took a look at the SGP FAQ and saw this:

> SuperGenPass uses a one-way hash algorithm (base-64 MD5) to generate passwords. Specifically, it concatenates the master password and the domain name of the Web site (masterpassword:domain.com), hashes the result at least ten times (and until it satisfies the generated password requirements), and cuts the result to the desired length.

Yikes! MD5 is known to be broken, and 10 rounds of hashing is no defense against brute force attacks. Hashpass uses SHA-256 (not broken) and does 2^16 rounds of hashing.

View on HN

No, SHA-256, the way you use it, is not "far too slow for brute-force".

To anyone reading here: Please do yourselves a favor and stay away from BOTH SuperGenPass and from this one.

They are nearly equivalent to using the same password for every website. A malicious website owner can derive your "master password" from the hash that you gave them and thereby gain access to all your websites.

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 collisions...slightly harder to find the exact passphrase, particularly if it is a very long/strong passphrase. A collision in this context is not enough to break the usage.)

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 sufficient strength since they are limited to printable characters and especially when they are required to type it in all the time.

This is why key stretching functions such as PKDF2 and Scrypt were invented. To make relatively bad passwords (which users are prone to choose) harder to crack.

Screwing this particular step up in a tool that wants to be a password manager (of all things) strongly indicates that the creator has no remote clue what he is doing and that everyone should stay far away from his software.

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.

Reply on news.ycombinator.com