4 ms·

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 a

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?

pindi 13y ago
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.
- marshray 13y ago
  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?
babuskov 13y ago
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.
- Evbn 13y ago
  That is the goal. Slower hashing is harder to crack, is more secure. Login load is nothing compared to the rest of the app.
CoffeeDregs 13y ago
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.
bcoates 13y ago
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.
- eksith 13y ago
  The situation is a bit more complicated than that : http://security.stackexchange.com/a/6415 http://security.stackexchange.com/a/6415 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.
  - bcoates 13y ago
    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.
  - floody-berry 13y ago
    people actually pay you just to make shit up?
    - sk5t 13y ago
      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.
      - 13y ago

pindi 13y ago

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.

marshray 13y ago
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?

babuskov 13y ago

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.

Evbn 13y ago
That is the goal. Slower hashing is harder to crack, is more secure. Login load is nothing compared to the rest of the app.

CoffeeDregs 13y ago

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.

bcoates 13y ago

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.

eksith 13y ago
The situation is a bit more complicated than that : http://security.stackexchange.com/a/6415 http://security.stackexchange.com/a/6415 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.
- bcoates 13y ago
  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.
- floody-berry 13y ago
  people actually pay you just to make shit up?
  - sk5t 13y ago
    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.
    - 13y ago