Monday, March 26, 2012

how to encrypt a single field like a password field

without writing code in my application? Does SQL Server have stored procedure to do it?
Any help is appreciated.
Thanks.SQL Server 2005 has support for encryption, but you have to manage keys, and write your own stored procedures that use the encrypt and decrypt functions. SQL 2000 does not have native support for encryption, I believe.|||Attached is function that is suitable for encrypting passwords.|||naaahh. any encryption formula you put together just is not going to do the job the public-key encryption is going to do.|||Attached is function that is suitable for encrypting passwords.
I have downloaded the code and will take a look at it.|||Theres an inbuilt function in SQL2000:

column type must be:
Declare PWCol varbinary(256)

to insert/update use:

...CONVERT(varbinary(256), PWDENCRYPT('THEPASSWORD'))

and to compare a password...

...where PWDCOMPARE('thepassword', PWCol) = 1

Cheers,
Phil
--
Always remember that you're unique, just like everyone else.|||a quick google search on this undocumented function gives you results on how to hack it. PUBLIC KEY ENCRYPTION is the safest bet. It's been a while since I have done this (4 years?) but I used the RSA cypher.|||naaahh. any encryption formula you put together just is not going to do the job the public-key encryption is going to do.
Not true. The encryption algorithm I gave is a "one-way" algorithm. It cannot be unencrypted, and thus is only suitable in limited situations such as password encryption. It is relatively easy to make secure one-way encryption schemes.
The challenge is to make a secure "two-way" encryption algorithm. SQL Server's built-in encryption is "two-way" but is not secure and was hacked years ago, and the decryption method is readily available on the web.|||Duplicate post.|||a quick google search on this undocumented function gives you results on how to hack it.

Blimey you boys do love to p!$$ on someones fire.

It's only hackable if your front end code is crap and you don't parse throu before SQL.
If you're stupid enough to leave your SQL server open to access then the fact you can hack a password in a table is pretty irrelevant when you can get control of the whole box.

Right, I'm off to sulk in the corner.

...

To err is human, to forgive is not our Policy.|||Whoa, Mr. Sensitive! You're gonna need thicker skin than that!

And no sulking, either. If you think we're full-o-crap, then just say so (but without throwing all tact to the wind...).

P!$$!ng on someone's fire: allowed.
Sulking in the corner: frowned upon.
P!$$!ing in the corner: well, when ya gotta go...|||Well at least I now know why my sulking corner is starting to smell so bad.|||We generally do our sulking and grousing in the Yak Corral. You can join us there:
http://www.dbforums.com/showthread.php?t=989246&page=289|||Wy not to use the in-built function encrypt() ?|||It is an undocumented function which may not be supported, or may use a different algorithm in future releases.

The algorithm has changed through releases in the past, rendering whole databases inaccessible for applications that relied upon it.

No comments:

Post a Comment