5 ms·

If you're implying that Newegg or any public-facing authentication system could be implemented with a non-exposed password vault, then I don't see how. If user

If you're implying that Newegg or any public-facing authentication system could be implemented with a non-exposed password vault, then I don't see how. If user passwords are encrypted with symmetric encryption, either the application must have access to the key in order to compare your provided password to the password stored in the DB, or the DB has to have a stored procedure with access to the key. Therefore it's not -only- customer support that has access, but anyone who hacks the production system also gains access to the key. Of course there are ways to obscure that if it's kept in memory and required as input before the server starts up, but theoretically it's available to anyone who compromises the relevant server. (And even if there were a system that were implemented as you describe, with access allowed only when a support staffer and a supervisor provides an asymmetric key each, who supervises the supervisors?) (edit: The offered suggestions show that I wasn't considering non-symmetric or non-software approaches; in any case, at best those seem like complicated band-aids for a situation that should not exist.)

SoftwareMaven 15y ago
The work could be done on a hardware security module, so the key never leaves the well-guarded environment. That would also make a good gatekeeper for requests for the unencrypted password.
amalcon 15y ago
It could either: A) Have a traditional hashing scheme independent of the vault B) Use public-key encryption, and give the production system only the public key. The server could encrypt the provided password for decryption by the private key, and then compare ciphertext. The vault simply has the private key. Neither of these systems are ideal, especially the latter, but they do get around the one particular issue of a hacked frontend.
- Travis 15y ago
  Why is (B) not ideal? Sounds like you get the usability (recoverable passwords) without the security issues (assuming that you properly separated the keys, etc.) I ask because I am writing an app currently that stores an SSN. The data are downloaded for later use on non-public facing machines, and the SSN needs to be decrypted at that point. I am saving the data using PKI, and will be able to decrypt it later (but anyone without my keys won't be able to).
  - tptacek 15y ago
    Among the many reasons not to try implementing this is the fact that secure public key encryption is randomized.
    - Travis 15y ago
      I'm not sure I follow your statement. How would you recommend that I encrypt a piece of data to store into a database? It needs to be reversible (encryption, not a hash), but does not need to be reversible on the production system (the field just needs to be decrypted before analysis, on different machines at a later time).
      - tptacek 15y ago
        You could use public key encryption in a cryptosystem to store rows in a database. The "correct" way to do that would be to use /dev/random to generate a 128 bit AES key, encrypt the data with AES, and encrypt the AES key with RSA. That gets you "reversible on one server but not another". But you're looking for something beyond that; you want "semi-reversible and deterministic". Determinism is not typically regarded as a feature in cryptosystems. Secure RSA schemes go out of their way to avoid it (read Wikipedia's OAEP article as a starting point). Generally I think it's a very bad idea to get involved in custom cryptosystems just to store passwords.
        Travis 15y ago
        I'm a little lost, perhaps I'm not explaining my problem too well. I really appreciate your assistance so far, and I'll try not to waste too much more of your time or space in the HN databases. If you have a quick link about your first paragraph, that would be appreciated. I'm not sure exactly what that means -- I understand what you mean bygenerate an AES key via /dev/random (gives us nondeterministic key), then encrypt the data with AES. However, why would I use a symmetric encryption system rather than a private/public key pair? With a priv/pub pair, can't I encrypt the data on the server but not be able to decrypt it? Again, thanks for your help. I'm not actually storing passwords -- those I properly hash. The problem is that my data app has a requirement to collect SSNs (and they need to be reversible, although that can be offline at a later date). Oddly enough, the data requirements only state encryption is required for that -- most of my colleagues are using symmetric encryption with the passphrase stored on the server itself! I was just hoping I could build a system that would be able to encrypt the data, but not decrypt it (the decryption would be handled by another machine not available to the public).
tptacek 15y ago
I'm implying that customer-facing systems use secure hashes, and that the company also stores encrypted passwords on a server not exposed to the Internet.

SoftwareMaven 15y ago

The work could be done on a hardware security module, so the key never leaves the well-guarded environment. That would also make a good gatekeeper for requests for the unencrypted password.

amalcon 15y ago

It could either: A) Have a traditional hashing scheme independent of the vault B) Use public-key encryption, and give the production system only the public key. The server could encrypt the provided password for decryption by the private key, and then compare ciphertext. The vault simply has the private key. Neither of these systems are ideal, especially the latter, but they do get around the one particular issue of a hacked frontend.

Travis 15y ago
Why is (B) not ideal? Sounds like you get the usability (recoverable passwords) without the security issues (assuming that you properly separated the keys, etc.) I ask because I am writing an app currently that stores an SSN. The data are downloaded for later use on non-public facing machines, and the SSN needs to be decrypted at that point. I am saving the data using PKI, and will be able to decrypt it later (but anyone without my keys won't be able to).
- tptacek 15y ago
  Among the many reasons not to try implementing this is the fact that secure public key encryption is randomized.
  - Travis 15y ago
    I'm not sure I follow your statement. How would you recommend that I encrypt a piece of data to store into a database? It needs to be reversible (encryption, not a hash), but does not need to be reversible on the production system (the field just needs to be decrypted before analysis, on different machines at a later time).
    - tptacek 15y ago
      You could use public key encryption in a cryptosystem to store rows in a database. The "correct" way to do that would be to use /dev/random to generate a 128 bit AES key, encrypt the data with AES, and encrypt the AES key with RSA. That gets you "reversible on one server but not another". But you're looking for something beyond that; you want "semi-reversible and deterministic". Determinism is not typically regarded as a feature in cryptosystems. Secure RSA schemes go out of their way to avoid it (read Wikipedia's OAEP article as a starting point). Generally I think it's a very bad idea to get involved in custom cryptosystems just to store passwords.
      - Travis 15y ago
        I'm a little lost, perhaps I'm not explaining my problem too well. I really appreciate your assistance so far, and I'll try not to waste too much more of your time or space in the HN databases. If you have a quick link about your first paragraph, that would be appreciated. I'm not sure exactly what that means -- I understand what you mean bygenerate an AES key via /dev/random (gives us nondeterministic key), then encrypt the data with AES. However, why would I use a symmetric encryption system rather than a private/public key pair? With a priv/pub pair, can't I encrypt the data on the server but not be able to decrypt it? Again, thanks for your help. I'm not actually storing passwords -- those I properly hash. The problem is that my data app has a requirement to collect SSNs (and they need to be reversible, although that can be offline at a later date). Oddly enough, the data requirements only state encryption is required for that -- most of my colleagues are using symmetric encryption with the passphrase stored on the server itself! I was just hoping I could build a system that would be able to encrypt the data, but not decrypt it (the decryption would be handled by another machine not available to the public).

tptacek 15y ago

I'm implying that customer-facing systems use secure hashes, and that the company also stores encrypted passwords on a server not exposed to the Internet.