I'm starting a new ASP.Net application from scratch. What should I use to encode passwords and what should my column be?
Just a simple varchar(512)? Thanks for any advice.
A:
I would take a look at the System.Security.Cryptography namespace and devise a way to encrypt the passwords. Once you do that you can just take a look at the size of the encrypted passwords and create your column accordingly. Make sure you don't lose the encryption key of course. I would also have a different key in DEV than in PROD for added security. There are plenty of tutorials (and code) on how to do this in .NET.
Good luck!
fnCzar
2010-08-23 23:45:54
here are some links: http://www.c-sharpcorner.com/uploadfile/gsparamasivam/cryptencryption11282005061028am/cryptencryption.aspxhttp://www.eggheadcafe.com/community/aspnet/2/10191114/systemsecuritycryptography.aspx
fnCzar
2010-08-23 23:48:27
-1 For suggesting encryption for passwords
quantumSoup
2010-08-23 23:50:51
quantumSop: Can you elaborate?
Serg
2010-08-23 23:58:06
@Sergio See my post. Encryption, hashing and encoding are totally different, non-interchangeable terms.
quantumSoup
2010-08-24 00:04:33
Bad, bad advice. Do not encrypt passwords. Use a salted hash.
Steven Sudit
2010-08-24 01:16:49
sorry guys, I meant hashed, wrong choice of words. I deserve the -1 :-)
fnCzar
2010-08-24 15:02:16
+4
A:
I would use the Membership API that's included with .NET. I believe it hashes passwords (and security answers) using salted SHA1. If you still want to reinvent the wheel, you could still use this as a guide for best practices.
Jacob
2010-08-23 23:46:15
If you still want to reinvent the wheel, you should also realize that you're going to get it wrong.
Stephen P
2010-08-24 00:06:17
+3
A:
Well, if you're using SHA1 you're hashes are only going to be 48 characters long, so 512 is overkill.
I use SHA 256 with a salt.
Kevin Sedgley
2010-08-23 23:46:39
+1
A:
People, please.
Encryption != Encoding != Hashing
These are 3 different terms that should not be used interchangeably.
Passwords should be hashed and salted, never encrypted, much less encoded. Use SHA as your hashing algorithm and remember to use a salt too. That's a very important countermeasure to avoid rainbow table attacks.
Also, all hash functions will generate an output that has a fixed size (32 characters in case of MD5, 40 in SHA1, etc.) so you don't need all that extra space.
References/Reading:
quantumSoup
2010-08-23 23:48:15
To be fair there is an encoding step -- after you apply the salted hash, you generally *encode* the hash result as a base64 or hex string :)
hobbs
2010-08-24 00:21:13
@hobbs: If you're going to store the encrypted salt/hash in a database then there's usually no need for an additional encoding step. You'd just store them directly in a `VARBINARY` column, or equivalent.
LukeH
2010-08-24 00:25:16
@LukeH: That's not always convenient. It's much easier to deal with base 16 or 64, especially if you're storing the salt in the same column.
Steven Sudit
2010-08-24 01:16:24