I'm curious why I've never heard anyone suggesting to make a public/private key pair, burn the the private key, and just encrypt passwords with the public key as your hashing function.
Short of finding an exploit in GPG, you'd have to crack the public key used which would be near impossible if a long key was used. This assumes you keep that key safe.
So why not literally make a key pair and throw away the key?
At best, that's just a hash function, so no matter how long the key is you can still just guess passwords and do trial encryptions just like you would with a hashed, salted password.
If you used the same key for all your site's passwords an attacker could build a rainbow table so you don't even get to not salt.
It would be a lot slower than a normal hash so it'd be harder to brute force, but you can get the same protection in a simpler, more predictable system by just using PBKDF2 with enough repeated hashes.
I don't subscribe to one "scheme" for passwords since the easiest method (to implement, not crack) will be the avenue malicious hackers also pursue.
This is why most of my custom jobs involve an application specific salt per installation, in addition to the user-unique salt + password hash and then CFB encrypt the salt using another app-specific password + username hash.
I'm not saying PBKDF2 is ideal, I'm just saying that it has all the possible advantages of the proposed GPG based password storage without any of the weirdness of using crypto primitives in a way they weren't intended for.
I can't disagree with your sentiment... there comes a point where a hardware security module makes more sense than extraordinarily convoluted, tortured concealment of the salt and hashing mechanism.
It was perhaps unnecessarily blunt, but that is the root problem with most of these leaks: Someone who doesn't know what they're doing implementing a scheme that is only slightly more secure than storing the passwords in plaintext.
It turns out LivingSocial was actually using SHA-1 with a 40 byte salt [1].
> LivingSocial never stores passwords in plain text. LivingSocial passwords were hashed with SHA1 using a random 40 byte salt. What this means is that our system took the passwords entered by customers and used an algorithm to change them into a unique data string (essentially creating a unique data fingerprint) – that’s the “hash”. To add an additional layer of protection, the “salt” elongates the password and adds complexity. We have switched our hashing algorithm from SHA1 to bcrypt.
A 40 byte salt? "_additional_ layer of protection"? "elongates the password"? It's clear they thought they were implementing extra security (hey, let's use a 40 byte salt instead of 16, mega protection!) but failed miserably because they did not know what they were trying to combat.
A similar method is a "pepper", a form of salt common to all users and stored in the application configuration, allowing the passwords to resist attack even if the hash and user-specific salt are lost. The reason it's not often used is that the assumption is that if your database is compromised, any other commonly-used secret keys on the server will be too. It can be useful for defense in depth, though.
Serious question: How is "pepper" any different than encrypting a traditional salted hash using a symmetric cipher as if it were any other kind of data?
Maybe because encryption using public key is much more CPU intensive and slower than hashing? Since you have users logging into the system all the time, you would need to encrypt the typed password in order to compare it with the record in the database, and this could put a great load on the server CPU if you have many users logging in.
Sounds as if you're suggesting increasing the work for the encryption/decryption? If so, there are well known ways of increasing the work and they're designed specifically for hashing [this kind of data]. I suspect the reason people haven't used pub/priv for such uses is that there are better algorithms for it.
Short of finding an exploit in GPG, you'd have to crack the public key used which would be near impossible if a long key was used. This assumes you keep that key safe.
So why not literally make a key pair and throw away the key?