Encrypting Passwords in .NET application
-
Hi, I am developing a Windows application which has login form where user can enter userid & password. The same will be checked against the database for verification. I want to know how the password should be stored in database in Encrypted format? Also, how to retrive such encrypted data in WinForm? I am currently using SQL 2005 as database. Later the database may changed to Oracle 10g. Will the database change affect the coding at UI level? If anyone can give me any suggestions on the same, that would be great. Thanks in advance
HR
-
Hi, I am developing a Windows application which has login form where user can enter userid & password. The same will be checked against the database for verification. I want to know how the password should be stored in database in Encrypted format? Also, how to retrive such encrypted data in WinForm? I am currently using SQL 2005 as database. Later the database may changed to Oracle 10g. Will the database change affect the coding at UI level? If anyone can give me any suggestions on the same, that would be great. Thanks in advance
HR
A common way of doing this is by using a one-way hash on the password before storing in the database. You can use this:
FormsAuthentication.HashPasswordForStoringInConfigFile
to do that. When the user enters a password, its hashed again and the hashes are compared. Using this approach though, you can never get back to plain text password. If a user forgets it, a new one must be created.
Regards, Rob Philpott.
-
A common way of doing this is by using a one-way hash on the password before storing in the database. You can use this:
FormsAuthentication.HashPasswordForStoringInConfigFile
to do that. When the user enters a password, its hashed again and the hashes are compared. Using this approach though, you can never get back to plain text password. If a user forgets it, a new one must be created.
Regards, Rob Philpott.
What's the best way for an application to store credentials if they need to be recoverable (for transmission elsewhere)? One-way hashes are great if all the application has to do is validate credentials when they are re-entered. But what about when some other device will need the real credentials?
-
What's the best way for an application to store credentials if they need to be recoverable (for transmission elsewhere)? One-way hashes are great if all the application has to do is validate credentials when they are re-entered. But what about when some other device will need the real credentials?
You could use an encryption algorithm one-way on the "less secure" server, treating the result like you would a hash. Your "more secure" server could then decrypt a token from the "less secure" server to retrieve the password. This lets you keep only the public half of the key on the "less secure" server. Presumably you'd also be salting the password, which the "more secure" server could ignore.
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games. -
You could use an encryption algorithm one-way on the "less secure" server, treating the result like you would a hash. Your "more secure" server could then decrypt a token from the "less secure" server to retrieve the password. This lets you keep only the public half of the key on the "less secure" server. Presumably you'd also be salting the password, which the "more secure" server could ignore.
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games.You could use an encryption algorithm one-way on the "less secure" server, treating the result like you would a hash. Your "more secure" server could then decrypt a token from the "less secure" server to retrieve the password. You're suggesting using a public key cryptosystem, where the intended recipient of the key knows half of the key and the entity storing the key knows the other? That would be a nice approach if the recipient of the key could handle the public key cryptography. Unfortunately, the recipient has no such facilities. It needs the credentials (sent via serial port, not Internet) in clear form. Security by Obscurity may be the only workable approach (the machine that will legitimately communicate with the recipient must have all the information an impostor would need) but there's still a huge gap between approaches that can be undone in five minutes with a disassembler and those that would take much longer. My guess is that any approach that would be hard to break would take impractically long to implement, but perhaps there are some good methods I don't know about.
-
You could use an encryption algorithm one-way on the "less secure" server, treating the result like you would a hash. Your "more secure" server could then decrypt a token from the "less secure" server to retrieve the password. You're suggesting using a public key cryptosystem, where the intended recipient of the key knows half of the key and the entity storing the key knows the other? That would be a nice approach if the recipient of the key could handle the public key cryptography. Unfortunately, the recipient has no such facilities. It needs the credentials (sent via serial port, not Internet) in clear form. Security by Obscurity may be the only workable approach (the machine that will legitimately communicate with the recipient must have all the information an impostor would need) but there's still a huge gap between approaches that can be undone in five minutes with a disassembler and those that would take much longer. My guess is that any approach that would be hard to break would take impractically long to implement, but perhaps there are some good methods I don't know about.
In my project requirement was same as of your. There is two approach two encrypt as the code level & database level, but I took the code level approach. Although I am not an expert in this area would like to know whether my approach was correct or not also it may answer your query. I used some class provided by .NET framework.
private static string Encrypt(string originalString)
{DESCryptoServiceProvider cryptoProvider = new DESCryptoServiceProvider();
MemoryStream memoryStream = new MemoryStream();CryptoStream cryptoStream = new CryptoStream(memoryStream, cryptoProvider.CreateEncryptor(bytes, bytes), CryptoStreamMode.Write);
StreamWriter writer = new StreamWriter(cryptoStream);
writer.Write(originalString);
writer.Flush();
cryptoStream.FlushFinalBlock();
writer.Flush();return Convert.ToBase64String(memoryStream.GetBuffer(), 0, (int) memoryStream.Length);
}
Now the returned string is in encrypted format & can be inserted in the database.
modified on Thursday, July 31, 2008 2:33 AM
-
You could use an encryption algorithm one-way on the "less secure" server, treating the result like you would a hash. Your "more secure" server could then decrypt a token from the "less secure" server to retrieve the password. You're suggesting using a public key cryptosystem, where the intended recipient of the key knows half of the key and the entity storing the key knows the other? That would be a nice approach if the recipient of the key could handle the public key cryptography. Unfortunately, the recipient has no such facilities. It needs the credentials (sent via serial port, not Internet) in clear form. Security by Obscurity may be the only workable approach (the machine that will legitimately communicate with the recipient must have all the information an impostor would need) but there's still a huge gap between approaches that can be undone in five minutes with a disassembler and those that would take much longer. My guess is that any approach that would be hard to break would take impractically long to implement, but perhaps there are some good methods I don't know about.
What kind of timeframe do you need to hang on to the cleartext? Can you just hold it in memory for the duration of the session with the "less secure" server - handing it out to the serial box when necessary? Otherwise if you have to persist it at all, then I agree with the obscurity approach - use some trivial encryption as a deterrant to someone who's ended up with a database backup tape but somehow not the whole app. Not that it should make you feel comfortable - obviously if the server is capable of retrieving the cleartext then it may as well be cleartext ;)
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games.