Password Field Encryption? 1

[gcoast]

I need to store a password field in a table. Is there anyway to encrypt this field?

We already thought about using views to get around this, but it seems that even the DBA shouldn't be allowed to see the field so encrpytion will be necessary, if possible.

Running SS2000 Sp3a

Thanks in advance,

gcoast

 

[Lekar]

I don't know if it exists a function that encrypts words on SQL Server. Maybe someone else on the forum can suggest one. But, you can make your own function that encrypts word, using methods like using a key, to achieve your requerimient. But I don't understand why the DBA can't see the pwd, the DBA can do with the database anything he wants anyway.

 

[theoxyde]

The best way is to store a cryptographic hash (MD5, SHA) of the password instead of the password itself. Concatenate the username/id to the password before hashing to tie it to that particular user.

That way, you can simply have the user provide the password and check the hash value in the database against the hash of the supplied password to determine whether or not the user is authenticated. That way, even the administrator cannot view the passwords.

 

[theoxyde]

BTW, there are functions in SQL Server to perform hashing and comparison of passwords, but there is no documentation on the functions, no clue as to what hashing algorithm is used, and lots of buffer overflows associated with them, which aren't fixed because the functions aren't documented (read: unsupported).

 

[kishleo]

well why dont you encrypt and decrypt the password in front end, and store and encrypted password in the database,

Kishore MCDBA

 

[theoxyde]

Good question... but what would you use for an encryption key? And where would you store the key? Hashing is a much simpler prospect. A stored procedure can be used to verify the password instead of actually retrieving from the database.

If you are going for encryption/decryption rather than hashing, you may as well go one step further to a public-key strategy and avoid storing the password at all (and is resilient to replay attacks if done correctly).

 

[SemperFiDownUnda]

theoxyde, star for you. MD5 is the smartest route. You'll find that on networks admins can't tell your password. They have the ability to reset them but not read them.

MD5 is a one way hash. Any lenght string from 1char to 2gig will break down to a 32 byte field like "566b9e6bdcbb395497c553a8df1af101"
that meas there are roughly
2,272,657,884,496,751,345,355,241,563,627,500,000,000,000,000,000,000,000,000 combinations
the chance as finding a string that has the same MD5 is pretty remote. You can not work the MD5 back to its source. Brute force is the only method to get an acceptible password.

If you go the encrypt/decrypt method then its only as secure as your key pair. To me it only annoys the people you really have to worry about and doesn't stop them.

 

[theoxyde]

A birthday attack could also be used, but those chances are prohibitively remote as well. SHA-1 is a bit more secure, but comes at a performance trade-off. If you are using a .NET front-end, the SHA1Managed hash provider seems faster than the MD5 implementation, IMO. For nearly every other platform, MD5 is faster (SHA-1 not being worth the performance hit).

Using either one, an attacker would choose a more vulnerable part of the system to attack, but will keep passwords secure from most script-kiddies.

Again, concatenate the user id to the password before hashing. This keeps someone from updating an entry for an admin account with their own password hash. In addition, don't retrieve the password from the database once it has been stored, but authenticate via a stored procedure that accepts a hash (user id + password).

If your application can absorb the performance hit, force all communications with SQL Server to be encrypted via SSL.

 

[SemperFiDownUnda]

I still concider dictionary etc attacks brute force. Good idea about the userid & password combo....I'll start incorporating that into all my systems from now on.

This makes the programmer the weakest link in the chain.

 

[kishleo]

well, i really dont have any idea about hash,MD5,SHA-1 all these terms looks new to me, do you people mine giving me some links to refer to this?



Kishore MCDBA

 

[theoxyde]

Implementation will depend upon the programming platform of the application.

Everything you ever wanted to know about cryptography (and then some):

http://www.rsasecurity.com/rsalabs/faq/index.html

The algorithm for SHA is here (albeit somewhat targeted toward mathematicians):

http://csrc.nist.gov/CryptoToolkit/tkhash.html