How to encrypt a password for saving it later in a database or text file?

Question

I want my application to save the password encrypted in a database or in a text file. How can I do that assuming that the database or text file can be open by anyone?

Duplicate

Encrypting/Hashing plain text passwords in database

Not duplicate I'm asking for code specific for .NET

EDIT: I'm saving the password for later use. I need to decode it and use it to login. It doesn't have to be super secure, it just needs to be unreadable to the human eye, and difficult to decode with a trivial script.

Answer 1

Use Data Protection API either with the user or machine store (e.g. different key per account your program/database server runs under vs. one key per machine). This will help you decode the passwords later and you don't have to remember or store any encryption keys. The downside of it is that when you reinstall the system/delete the account you won't be able to recover the data, I believe.

Answer 2

If you need to decrypt the password for later use and it doesn't have to be SUPER secure, then use the method here:

http://support.microsoft.com/kb/307010

It's well documented, and easy to understand.

Answer 3

Personally, I would use something that has one-way encryption - MD5, SHA1, etc...

You can use the FormsAuthentication class with it's HashPasswordForStoringInConfigFile method. When validating the user, encrypt the entered password and compare it with the stored version.

Answer 4

Here's a string encryption article with example code .NET

http://www.devarticles.com/c/a/VB.Net/String-Encryption-With-Visual-Basic-.NET/3/

There is no need to use anything fancy, because anyone with a little bit of skill and determination will break it anyway.

Answer 5

Triple DES is one way to do it, as long as you mean "A password that my system needs to be able to recall in order to access a resource". If you mean the password is something a user needs to be able to gain access to your system, probably don't want encryption, just a hash will do. When you store the hashed password value, it is useless to anyone with direct database access, but can still be used for authentication. All you do is compare the stored hash against a hash of the incoming password. If they match, then you grant access.

It isn't perfect, by any means, but it is the way 99.999% of people store their passwords.

If you want to argue that you wish to provide the password back to a user if they lose/forget it, then please don't. Issue them with a temporary password (which you store hashed in the db) and get them to change it on first login.

Answer 6

Based on your question I can see two approaches depending on why you are storing the password.

A. if you only need to authenticate using their password and nothing else.

In that case, going using an algorithm that is not reversible (Hashing) would be your best choice. You will need to make sure of a couple of things:

1. Make sure that the connection is encrypted when transmitting the password from the client to the server. This will prevent it from being sniffed out. This is pretty trivial to do with web applications since the web server is doing the heavy lifting for you. If not it gets a lot tricker and is the subject of an whole other question.

2. Choose a solid hashing algorithm to prevent collision. I would recommend SHA-256 even if it does provide a larger result than SHA1 or MD5. The reference from Microsoft on using their implementation of the algorythm is here.

3. Salt the password to prevent attacks using rainbowtable (i.e. looking up the password in large table with the precomputed hash and the associated password in clear text). The answer here (sited in your question) gives good pseudo code in Python on how to do it. There is also a good example of .NET code here.

B. if you need to be able to read the password for each user for other purposes than authenticating the user.

This case is easy if we are only talking about storing a password (or any kind of sensitive information) on a single computer (server). If that's the case, using the Microsoft Data Protection API would be a good solution since it is tied to that computer and (depending on the way you work) the user under which you application runs and takes care of the worst of the job for you (creating, storing, and using keys). You can find some code reference from Microsoft here. If you need it on more than one system and are not willing to enter the password on each system you install on your application then things get a lot more complex because you need to implement a lot of it from scratch. That would be the subject for another question I would think.

Answer 7

StackOverflow readers don't know how to write secure password schemes and neither do you. If you're going to do that, save time by sticking with plain text. From Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes:

Rainbow tables are easy to beat. For each password, generate a random number (a nonce). Hash the password with the nonce, and store both the hash and the nonce. The server has enough information to verify passwords (the nonce is stored in the clear). But even with a small random value, say, 16 bits, rainbow tables are infeasible: there are now 65,536 “variants” of each hash, and instead of 300 billion rainbow table entries, you need quadrillions. The nonce in this scheme is called a “salt”.

Cool, huh? Yeah, and Unix crypt —- almost the lowest common denominator in security systems —- has had this feature since 1976. If this is news to you, you shouldn’t be designing password systems. Use someone else’s good one.

Use BCrypt - Strong Password Hashing for .NET and Mono. It's a single cleanly written .cs file that will continue to meet your needs as password cracking computers get faster.

Answer 8

Briefly:

Get a big random number which you will keep private and only your application code will have access to.

Encrypt the password + random number with an ancryption algorithm like SHA1, most programming languages have a cryptography framework.

Store the hashed password.

Later when you want to check inputted passwords, you can rehash the user input and compare to the "virtually" undecipherable stored passwords.

Answer 9

BCrypt - Strong Password Hashing for .NET and Mono

Answer 10

If you use encryption for securely storing passwords, you'll need to store the encryption "key" somewhere, too. This will be the "weak link", since if someone gets hold of the encryption key, they will be able to decrypt the encrypted passwords.

Since this is passwords that we're talking about here, a much better solution is to use a one-way hash. You hash the password when the user first creates it (preferably hashing with a salt value) and store the resulting hash value. Since hashes are one-way, no one can reverse the hash to the original plain text value.

To check that a users password is correct, you simply ask the user for the plain-text password, hash their input again and compare the resulting hash value with the hash value you have stored (taking salts into account of course). If the two hash values are the same, the user has entered the correct password.

Please see the following links for further info: Hashing Password with Salt

For encryption (if you need to use that), I'd use Rijndael (AES).

Answer 11

Do you really need to be able to retrieve the password itself? If you're storing a password for the purposes of authenticating someone (or something), you should rather hash it (with salting) and then compare that hash to the hash of the password supplied by the party wishing to be authenticated.

If, on the other hand, you need to store the password in order to be able to retrieve it and supply it to some other authentication service later, then you might want to store it encrypted. In that case, use any decent symmetrical encryption algorithm you can, such as TripleDES or AES or Blowfish.

Answer 12

If you just need the password for an internal authentication process, you should not save the actual password, but save a hash of this password. When you need to check if a password is valid, you'll have to run the hash function on provided password and compare it with the hash you stored in your database/file. You can never find the original password from the hash.

If you need to keep the original password, you'll have to encrypt it. You can use for example a public key infrastructure if you have a process that writes the passwords (public key) and another one that reads them (private key).

Answer 13

do you need to encrypt it ever again? otherwise use a hashfunction to encrypt it and encrypt the password given by the user with the same hashfunction and look if the hashes are equal.

The reason for not using a 2-way-encryption is that one cannot decrypt your key - since a good hashfunction has collisions.

Answer 14

Like ocdecio I would use TripleDes, I would also save the salt in the database too. The key for me is usually hard coded, but the salt should change for each encrypted item.