How to encrypt the data of a field

I have a field aubot the password of a user.
How can I encrypt the field?In my opinion, for most purposes you are probably better off NOT to store
encrypted passwords in the database. Store a secure hash of the password
instead. It's easy to compute a hash in your client application (take a look
the SHA1 classes in .NET for example).
If you really think you have a good reason to encrypt passwords and if you
are sure you how to do it securely then Google for "encryption" in these
SQLServer newsgroups and you will find links to various third-party
encryption tools.
--
David Portas
SQL Server MVP
--|||Thank,
What is the difference between hash and encrypted password?
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> ¼¶¼g©ó¶l¥ó·s»D
:EYCdnaLqKue9RQrcRVn-jg@.giganews.com...
> In my opinion, for most purposes you are probably better off NOT to store
> encrypted passwords in the database. Store a secure hash of the password
> instead. It's easy to compute a hash in your client application (take a
look
> the SHA1 classes in .NET for example).
> If you really think you have a good reason to encrypt passwords and if you
> are sure you how to do it securely then Google for "encryption" in these
> SQLServer newsgroups and you will find links to various third-party
> encryption tools.
> --
> David Portas
> SQL Server MVP
> --
>|||http://msdn.microsoft.com/library/en-us/dnnetsec/html/cryptosimplified.asp
For password verification purposes an important advantage of hashing over
encryption is that there are no associated problems of key management.
Encryption requires keys, hashing does not.
--
David Portas
SQL Server MVP
--|||ad wrote:
> Thank,
> What is the difference between hash and encrypted password?
>
A has is one-way; meaning, there is no way to reconstruct the original
data from the hash. En encrypted password can be decrypted. That's not
to say that a hash is completely secure.
--
David Gugick
Imceda Software
www.imceda.com|||David,
"No way to reconstruct the original data" assumes there is no context
for the original data, but that is untrue for most of the world's
passwords. If a password is a name or word in any dictionary or
magazine, or a combination of two simple words or names, possibly with a
digit appended, the password is trivial to find from the hash. If the
hash is "plain", it's as easy as a lookup in a table of pre-computed
hashes (those are easy to find or build for SHA-1, MD5, or other
well-known hash functions - you could keep a few on your keychain). If
the hash is "salted," and the salt is known or easy to spot, it's only a
little harder - you need to hash a few million possibilities and see if
you get the hash in hand.
Steve Kass
Drew University
David Gugick wrote:
> ad wrote:
>> Thank,
>> What is the difference between hash and encrypted password?
> A has is one-way; meaning, there is no way to reconstruct the original
> data from the hash. En encrypted password can be decrypted. That's not
> to say that a hash is completely secure.
>|||David,
I agree that it's best not to store passwords at all. But
I've seen enough people think they're secure if they store
plain hashes to believe that any suggestion to store a hash
should be made with a caveat against weak passwords.
"Hashing alone won't protect weak passwords against
dictionary attacks." -- David Portas, November 2, 2004
SK
David Portas wrote:
>In my opinion, for most purposes you are probably better off NOT to store
>encrypted passwords in the database. Store a secure hash of the password
>instead. It's easy to compute a hash in your client application (take a look
>the SHA1 classes in .NET for example).
>If you really think you have a good reason to encrypt passwords and if you
>are sure you how to do it securely then Google for "encryption" in these
>SQLServer newsgroups and you will find links to various third-party
>encryption tools.
>
>|||Since we're talking security I guess it is wisest to assume little or no
knowledge of the subject and to spell out all the caveats. That could be a
long haul though and it takes us a bit off-topic here. My initial reply
prompted the response I might have expected - that the OP didn't have a
well-defined reason for choosing encryption and hadn't considered the
alternatives, so I posted the article, which includes a mention of salting
passwords. An FAQ is the only way to deal with this one, I think.
--
David Portas
SQL Server MVP
--|||Steve Kass wrote:
> David,
> "No way to reconstruct the original data" assumes there is no context
> for the original data, but that is untrue for most of the world's
> passwords. If a password is a name or word in any dictionary or
> magazine, or a combination of two simple words or names, possibly
> with a digit appended, the password is trivial to find from the hash.
> If the hash is "plain", it's as easy as a lookup in a table of
> pre-computed hashes (those are easy to find or build for SHA-1, MD5,
> or other well-known hash functions - you could keep a few on your
> keychain). If the hash is "salted," and the salt is known or easy to
> spot, it's only a little harder - you need to hash a few million
> possibilities and see if you get the hash in hand.
> Steve Kass
> Drew University
>
> David Gugick wrote:
>> ad wrote:
Well, I still think what I said is accurate. Notwithstanding the actual
security of using one technique over another, you can only try and hash
a value and see if you have a match. You're not going to try and somehow
to reverse engineer the hash itself. So it really is one way. It may not
be very secure. Simply enforcing a strong password standard can help
mitigate any security problems.
David Gugick
Imceda Software
www.imceda.com|||Thank,
The password can be use c to hash.
I have another field aoubt the user's salary, my boss ask me it must be
encrypted too,
Are there any good method to encrypted , and need be recover.
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> ¼¶¼g©ó¶l¥ó·s»D
:V62dnf6F0INooAXcRVn-qg@.giganews.com...
> Since we're talking security I guess it is wisest to assume little or no
> knowledge of the subject and to spell out all the caveats. That could be a
> long haul though and it takes us a bit off-topic here. My initial reply
> prompted the response I might have expected - that the OP didn't have a
> well-defined reason for choosing encryption and hadn't considered the
> alternatives, so I posted the article, which includes a mention of salting
> passwords. An FAQ is the only way to deal with this one, I think.
> --
> David Portas
> SQL Server MVP
> --
>