[peterwwillis]

I don't get how this is a good idea.

First, it's inconvenient because the same door/user id and password on multiple sites will just result in the same hash, so getting different hashes means having different user id's, something not everyone does or can do.

Second, it seems insecure. All you have to do is know the door id (username) and you can brute force the password just like any other salted password hash.

[marijn]

If you choose a suitably expensive hashing algorithm (I don't know if the author did), brute forcing is not practical.

[Appnician]

The door id is not just the user id it also contains the site name. For example "[e-mail]".

[peterwwillis]

ok, so [e-mail]@site.com would be my unique door id, so each site would have a unique hash. that solves the first problem, basically.

if someone compromises that site, they get the unique hash. presumably they're not using an expensive hashing algorithm (most sites don't). since they know my username and the site name, they can start brute forcing my unique hash to determine the password. sure, the program could be using an expensive hash algo that would make this take some time, but the whole point (i thought) was to prevent passwords at rest. with this you still have passwords at rest... they're just distributed out across the internet.

there is benefit here, in that you have to compromise each site to get each unique set of credentials. but the downside is a much bigger single point of failure. you trade off the inherent security of memorized complex passwords for one complex master password and the hope that nobody will ever discover or brute force it.

at the end of the day, passwords are still vulnerable to the same flaw: you only need one attack vector to succeed in compromising accounts. with 2-factor auth you need two attack vectors to succeed, which isn't impossible, but is harder, which is really what security is all about.

[Zikes]

If you looked at a random cryptographically secure hash on the internet, would you be able to determine what hashing algorithm was used? Would you know how many rounds it was sent through, or whether any other hashing techniques were used prior to the final hash?

[peterwwillis]

Yes, yes, yes. Password hashes that use salts or rounds are prefixed with said information, either so you know how to decrypt it, or know how to strip away the salt, or know what number of rounds to decrypt to.

[Zikes]

So if I did a salted sha256 followed by 8 rounds of bcrypt each with their own unique salt (probably a bad idea and I know it) you would know that I started with sha256? Wouldn't the final round of hashing obscure all previous rounds? And how would you strip away a salt without having the original, unhashed information? The whole point of a salt is to be factored in prior to the hashing process.

Also, you don't decrypt hashes.