Results 1 to 13 of 13
  1. #1

    How should I store a private key?

    I have a database which stores sensitive information which is encrypted asymmetrically with OpenSSL. Entries are added through our website using the public key and our staff members are able to decrypt the information using the private key through a web interface. How I am doing it now is essentially storing the private key in a cookie, but for some reason I feel like there must be a better way to do it. Does anyone have any better ideas?

  2. #2
    Join Date
    Jan 2011
    Location
    Canada
    Posts
    934
    The below is just a suggestion and general best practice IMHO.

    1) Store the private key off disk (eg: usb drive, etc)
    2) Your web interface should have a login system using the private key. Once authenticated, a separate time-limited token is issued and stored in the cookie. Server-side session also tracks ip to ensure validity of said token.
    3) All subsequent access is done via token authentication. Only when the token expires, do you ever go back to the private key.

  3. #3
    Quote Originally Posted by tchen View Post
    The below is just a suggestion and general best practice IMHO.

    1) Store the private key off disk (eg: usb drive, etc)
    2) Your web interface should have a login system using the private key. Once authenticated, a separate time-limited token is issued and stored in the cookie. Server-side session also tracks ip to ensure validity of said token.
    3) All subsequent access is done via token authentication. Only when the token expires, do you ever go back to the private key.
    Two questions:

    - If the key is stored on a USB drive, I'm assuming the staff member would then have to navigate to the text file and upload it to the server in order to log in, correct?

    - I'm not entirely sure I understand your use of a "token". If a token is what is needed to stay logged in, how is the private key stored between requests in order to decrypt the encrypted data? Presumably if it was given by the client only upon login, it would then have to be stored on the server, which I would think defeats the purpose of even encrypting the data in the first place.

    Edit :: The private key is not used for user authentication. That is done with a username and password. In order to log in they need to provide all 3. From then on, a session ID is used to stay logged in and the private key is required whenever the server needs to decrypt something.

  4. #4
    Join Date
    Jan 2011
    Location
    Canada
    Posts
    934
    Ah that's clearer. I missed reading the part about the db sendback being encrypted. Disregard the whole token idea

    Regarding what you ACTUALLY wrote one thing you could try - and I'm not sure how well it'll work for you - is to have the user locate and open the key file locally via javascript. You could use a cookie to make this easier, but just retain the path, not the actual key.

    There may be some browser security restrictions in doing this, but there should be a couple workarounds, including but not limited to turning down the security setting for that site.

  5. #5
    That's actually a good idea. But just a question, what's the difference between doing it like that or actually storing it in a browser cookie? Cookies from one domain are not accessible by another one. What about HTML5 local storage?

  6. #6
    Join Date
    Jan 2011
    Location
    Canada
    Posts
    934
    Main thing was the usb key. You don't want the private key permanently accessible on the machine, much like it would in the browser cookie dir or temp storage.

    Also, if I'm not mistaken, there are a couple XSS vulnerabilities related to cookies.

  7. #7
    What about this idea? In order to keep the keys completely away from the end user and to not store the private key on the server, instead have two servers. The main server with the encrypted data and a secondary server on a separate network which contains the private key and will only give it out if some sort of password is correct and the IP address matches the IP of the main server. The main server would then connect to the secondary server through a secure connection to retrieve the private key when decryption is necessary. Can anyone see any security holes in doing it this way?

  8. #8
    Join Date
    Jan 2011
    Location
    Canada
    Posts
    934
    I figured part of the reason to encrypt the database was so that a compromised db server won't allow anyone to see the data. In which case, having the server query for the private key and use it to decode and transmit would open you up for more interception.

    I think you'd want to transmit encrypted data from the db to the private key server, decrypt it, and then forward the result to the user under SSL. It'd act as a proxy of sorts. You weakest link would then be the private key proxy. Aside from using OAuth style authentication to control its access to the db, I'm not sure if there's anything else you can do.

  9. #9
    Quote Originally Posted by tchen View Post
    I figured part of the reason to encrypt the database was so that a compromised db server won't allow anyone to see the data.
    Yes, that is correct.

    Quote Originally Posted by tchen View Post
    In which case, having the server query for the private key and use it to decode and transmit would open you up for more interception.

    I think you'd want to transmit encrypted data from the db to the private key server, decrypt it, and then forward the result to the user under SSL. It'd act as a proxy of sorts. You weakest link would then be the private key proxy. Aside from using OAuth style authentication to control its access to the db, I'm not sure if there's anything else you can do.
    Perhaps I'm not fully understanding you here, but if the db server were to query another server for the key (as opposed to sending the encrypted data to it) I don't see this as being another point of interception as long as this is done through SSL as well. Also, since the client would be using a web browser in order to view the decrypted data, I'm not sure how easy it would be to set it some sort of 3-way transaction where the client sends a request to the one server and receives a response from another one without using some tricky html5 websockets stuff and some even more tricky Apache mods to have one request send data to another user without storing it on that server somehow.

  10. #10
    Join Date
    Jan 2011
    Location
    Canada
    Posts
    934
    Ah, the interception bit was about a compromised DB server. I would assume you wouldn't have wanted the private key anywhere near that server.

    Something like OAuth would give you something similar to the way paypal handles gateway payments for most of the providers here.

    For the sake of illustration, lets say the database server is the one controlling the user login and db permissions. The user normally connects to the proxy to view and edit decrypted data. To allow the proxy and db to exchange data, the proxy initiates a service request to the db, which returns a token. At the same time it also creates a popup for the user with the db login page, passing along the token. The user then authenticates with the db server, and another temporary use token is passed from the server to the proxy for subsequent uses on that session.

    Its a pretty standard pattern, and the advantage is that in no situation will any compromised party be able to decrypt the full database by themselves.

    Database: has encrypted data + user auth hashes
    Proxy: has private key
    User: has user password

    Obviously, there's still an issue of a compromised Proxy having decrypted data in memory, but at least you don't have unfettered access to the database outside of a session.

  11. #11
    Join Date
    Jan 2011
    Location
    Canada
    Posts
    934
    I should point out that you don't really need anything tricky with apache mods or sockets for the above. It's all pretty plain.

  12. #12
    I've never heard of OAuth, but the concept seems very interesting. Thanks a lot for all your help.

  13. #13
    Join Date
    Jan 2011
    Location
    Canada
    Posts
    934
    No problem. Good luck with it and I hope it works out.

    Cheers

Similar Threads

  1. SSH to Cpanel server with public/private key
    By Tomcatf14 in forum Hosting Security and Technology
    Replies: 7
    Last Post: 04-15-2010, 06:29 PM
  2. Public/Private key PHP workflow
    By Steve_Arm in forum Programming Discussion
    Replies: 6
    Last Post: 04-04-2009, 06:57 AM
  3. Public/Private key authentification
    By hasinjaan in forum Hosting Security and Technology
    Replies: 5
    Last Post: 10-26-2008, 07:20 AM
  4. SSH public/private key login
    By Iggy in forum Hosting Security and Technology
    Replies: 2
    Last Post: 04-25-2003, 10:28 PM
  5. help : SSL generating private key with openssl
    By JamesBond in forum Web Hosting
    Replies: 4
    Last Post: 05-01-2001, 06:26 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •