Best practice to store passwords for external services? | Hacker News Reader

Best practice to store passwords for external services?

13 pointsperssontm7 comments

I'm building a web application that lets user enter their imap-account-information into it, and I need to save it for them for later use.

I've been looking at a few ways to encrypt it, but it also has to be easy to decrypt for me when accessing their imap-account. In the same time it should be made reasonably difficult to decrypt them if the database gets stolen for some reason.

Is there some best practices here? Any hints would be appreciated. Implementation is in php and mysql currently, but might be python as well(I'm still in the prototype phase).

View on HN

If your system needs both to encrypt and decrypt some information this to me means that the decryption key has to be stored somewhere and if that somewhere is compromised, so is everything else.

I would store the decryption key on the filesystem somewhere obscure, so that if somebody gets into your database, but not the filesystem, the data still remains encrypted.

If your filesystem is compromised, all your security measures will quickly become meaningless. You will need to do continuous security monitoring and auditing to make sure that doesn't happen.

Use bcrypt or scrypt to store the passwords. Don't use plain SHA1 or MD5, etc. If you must use SHA1 or MD5 (for whatever reason), iterate and salt them.

Edit: Re-reading, I may have mis-understood your question. You want to be able to decrypt and view their plain-text passwords yourself? Is that what you mean when you say "easy for me to decrypt". If that's the case and you need to decrypt it later (on their behalf) disregard my suggestions.

Yes, I will need the passwords in clear text when doing logins later.

I was thinking about storing the password as cram-md5, but that will require the server to support that. http://www.inter7.com/courierimap/INSTALL.html#crammd5

I'm still in the prototype phase of a project with the same problem, and it's the one aspect of it that makes me nervous.

Note that you don't always need to store the password - GMail will let you do IMAP using OAuth, and Yahoo has their Mail Applications. My own plan is to launch with support for those and find out a little about demand for the product before we start storing people's passwords.

If the task you're doing with the account-information is asynchronous make it inaccessible from the web frontend (or writeonly, public key encryption) and run your cronjob on a different box with a different database user so that the data is safe if your public facing application gets hacked. Also do not store the passwords in plaintext and store the private key in the safest place possible.

Good idea, sounds like a messy setup though, but that might have to do, since I will use virtual machines for this they will most likely have to be accessible from the net, both of them. But your idea is interesting. Thanks!

Any suggestions on a place to store the private key? This is an interesting question, btw.

Reply on news.ycombinator.com