3 ms·
It doesn't look like an improvement to me. During normal operation it has a black box that validates passwords quickly. The PloyPasswordHash is the key to how
by rstuart4133 11y ago
It doesn't look like an improvement to me.
During normal operation it has a black box that validates passwords quickly. The PloyPasswordHash is the key to how it does it - but really it doesn't matter. All that matters is a password (or a hash of it) goes in, the blackbox maybe reads some data from the (effectively public) password database, and a yes/no comes out at the cost of stuff all CPU time.
The point is - if you can reproduce the blackbox once per GPU node on a password cracker it's no better than any other scheme.
So the security of the scheme rests on the attacker not being able to reproduce the blackbox. If it were a real blackbox sitting somewhere secure then maybe - but it's not. They make a large point of saying this scheme has no secret hardware sauce - is it's just software, in reality just another process running on the web server. If you managed to get a copy of the memory image of that process it's game over. But we can't use that weakness to attack it because it is acknowledged in the paper.
During normal operation the blackbox creates it's secrets by effectively combining a _lot_ of passwords (say N) from users. Thus you need N valid passwords before you can crack one. I think they achieved that, and it does indeed make the it near impossible to recreate the blackbox by brute force - if all you have is the public password data base and a copy of the code.
But it's not that simple. Firstly they acknowledge a naive implementation doesn't work because an attacker can just create N accounts and feed the passwords to the blackbox so it can initialise itself. In addition there is a bootstrap problem - no user can validate their password until N password have been gathered by having N attempted logins.
They get around that by having N (or close to N) special accounts which they call protector accounts. These accounts are presumably created by the server admin and thus can be trusted. They are used for both bootstrapping (implying they are available at boot time) and preventing the flood attack (by insisting some of the special accounts must be part of the N).
And so we get to the real issue: the passwords for those accounts must be entered when the machine boots. Effectively they are the secret the blackbox needs to do it's stuff. Replacing the PolyPasswordHash with a process that demands a single secure password be entered when the machine boots would work just as well. Eg, that password is an extra salt fed to a cryptographic hash along with the password word and on disk salt, and the result must match the hash stored on disk. Without knowing that salt there is no way to validate the passwords.
Sure entering N passwords isn't hard, but would you enter N passwords when there is a method offering equivalent security when you enter just one? And even that isn't the real issue - the real issue is fuck all corporations on the planet have employees willing to be woken up a 2 AM in the morning when a server boots to enter just one password.