How can he do this? Maybe somebody can help me here.
Regards Markus
What does your friend need the password for? If it is used for authentication (to verify that another password submitted is matching the password stored in the database), then you can hash the password. If you need to store the password to use it somewhere else in clear form, then you need to encrypt it.
For SQL Server 2000 there are no builtin functions for hashing or encryption You may hear about pwdencrypt - an undocumented function - do not use it. For SQL Server 2000, you will have to write your own extended procedures for performing encryption or hashing.
In SQL Server 2005, you can use HashBytes to hash the password and EncryptByKey to encrypt it.
Thanks
Laurentiu
but is this truly secure? you're still sending the password over a connection in clear text, unless you're in SSL, yes? isn't it best to simply hash the password on the clientside to begin with?
|||Laurentiu Cristofor wrote:
In SQL Server 2005, you can use HashBytes to hash the password and EncryptByKey to encrypt it.
Thanks
Laurentiu
It is secure if the connection is secured using SSL - it should be secured that way if you're concerned about security.
Hashing on the client side does not address the insecure connection problem, because your authentication will then only depend on the hash (that's all the server will see from the client), and then the hash will effectively serve the same role as the password, so if a hash is intercepted on an insecure connection, a third party can pass it back to the server and connect this way.
Also, note that in my previous post I did not recommend implementing custom authentication schemes using those functions. Instead, you should leverage the mechanisms already provided by SQL Server.
Thanks
Laurentiu
No comments:
Post a Comment