September 24, 2003 at 6:51 am
Hello!
Sorry to put this subject inside the backup folder.
How can I store a password for a user safe? Do I use varbinary or another fieldtype?
I want my application to use the application role, and I need this information about the password to login. Then I'm shure that no one is able to view this site other than the SA, but that's not good enough.
Please help me.
Regards - Lars
-Lars
Please only reply to this newsgroup. All mails would be bounced back.
September 24, 2003 at 6:56 am
You could look at a 3rd party tool for encrypting the field eg http://www.xpcrypt.com/
Steven
September 24, 2003 at 7:01 am
quote:
You could look at a 3rd party tool for encrypting the field eg http://www.xpcrypt.com/
So SQL doesn't have anything of their own?
What about the varbinary field that has been used in dbo.sysusers. If I
select on this - can I do something to view the exact password?
SELECT * FROM dbo.sysusers WHERE [name] = 'SOMETHING'
Then I receive 0x010006D4D5E55885544EE44CDEFA (fictive one, something like
this)
Please only reply to this newsgroup. All mails would be bounced back.
-Lars
Please only reply to this newsgroup. All mails would be bounced back.
September 24, 2003 at 7:12 am
SQL does have an internal routine which it uses for encrypting and comparing login passwords.
You can see how it works by viewing the sp_password master stored procedure.
Note: There are papers in existance on how to break this password.
Also since this is an internal function it could change with the next service pack/security update etc. and it may be best to go along a different route.
Steven
September 24, 2003 at 7:30 am
You could use CryptoAPI to encrypt the password. Comes with any (recent) version of Windows.
It has a bunch of symmetric and asymmetric algorithms that have been proven to be 'safe'.
You should choose a good key to encrypt / decrypt stuff. We often use a combination of password and/or username and/or a bunch of 'random' data to generate a key for assymetric encryption.
For symmetric encryption, the key should be difficult to track, obviously...
September 24, 2003 at 9:59 am
Security is incredible hard and encryption has lots of downfalls. Having a scheme to do it is only a small part of the issue. Managing the keys is the hard part.
And by the way, having it unreadable by "sa" isn't really feasible unless you are going to require that the pwd change often. The sa can always brute force the pwd over time.
http://www.sqlservercentral.com/columnists/sjones/wp_encryption.asp
Steve Jones
http://www.sqlservercentral.com/columnists/sjones
The Best of SQL Server Central.com 2002 - http://www.sqlservercentral.com/bestof/
September 25, 2003 at 2:21 am
Couldn't I use MD5?
Has anyone of you done this?
I know I can use md5, but can you decrypt
202cb962ac59075b964b07152d234b70 back to string in VC++ or SQL Server?
-Lars
Please only reply to this newsgroup. All mails would be bounced back.
-Lars
Please only reply to this newsgroup. All mails would be bounced back.
September 25, 2003 at 4:14 am
quote:
Couldn't I use MD5?Has anyone of you done this?
I know I can use md5, but can you decrypt
202cb962ac59075b964b07152d234b70 back to string in VC++ or SQL Server?
hi!
MD5 is a hash, you wont be able to "decipher" the byte sequence it creates. the only thing you can do is hash the value you get and compare it to the stored hash. if they match, the "password" was "correct".
in general you should read carefully about limitations and pitfalls when using hash algorithms for password encryption. could happen that you're going to use a "weak" hash which has known issues when it comes to generating the same values for different "passwords".
best regards,
chris.
September 25, 2003 at 6:47 am
What I did was use an NVarChar(50) Field "Password" in my Users table (but I only allow a 25 Length Password). I use my own Encryption methods from the DotNet Framework (Encryption is much easier in .NET). Since the Text of the Encryption must be converted into a BASE64 encoded string (so that I can also save this into XML data), the Password may grow larger than 25 Chars (hence the Length of the Field vs. what I allow the user to type). Also, I found out that not converting to Base64 and back caused a lot of problems with the data. The other thing was the Crypto API...don't use it. For some reason, everytime I tried to wrap that API into a Class, it would only convert ok on SOME machines...on others, it wouldn't even Encrypt / Decrypt correcetly (even though they were the same OS / SP).
I am using the TripleDES algorithm with CBC (Cipher Block Chaining Mode). If you want the code, I can post it. Beware, Cryptography is not for the faint of heart, however, my methods of encryption are super easy (ex. Dim myPassword as String = ICrypto.Encrypt(Value, Password)).
September 25, 2003 at 9:34 am
BTW, there should be some scripts or threads around that give an encryption algorithm in T-SQL. Think it was 3DES or MD5.
But I have to agree that the best way is encryption on the client side. Otherwise, you might send passwords in the clear over the network, and that should be avoided.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply