Password encryption in ASP classic. 2

[ironhide1975]

Is there a module or preferred method for encrpting passwords in a SQL server field using ASP classic.

 

[DotNetGnat]

try these:

http://aspnet.4guysfromrolla.com/articles/103002-1.aspx

http://www.freevbcode.com/ShowCode.asp?ID=2565

-DNG

 

[ironhide1975]

The first example was .NET and the second although I was able to encrpyt the string I could not figure out how to de-crypt it. Are there any other examples per chance?

 

[Abraxus]

I think the point of one-way encryption is that you can't and don't decrypt the password. How do you validate it then? My guess is that you take the string entered for the password when a user attempts to login, run it through the same encryption method and then check it against the similarly encrypted stored value. My hope is that they will match and the user will then be validated

 

[Sheco]

Do a search for MD5 hash.

ewcwee has it right, you store the hashed password in your database and then, to verify the login, you hash whatever the user entered and search for that value rather than the actual password.

The great thing about that is you can honestly say "I don't know your password and I have no way to get it, I can only reset it." It makes people feel better about the security of their data, even if it is stuff you wouldn't be interesting in looking at anyway.

 

[ironhide1975]

Ok I looked through some of my old code and traced back an old encrpytion method to a dll you can install. This was sorta what I was looking for. I just need to make sure that if someone looks at the database they can't easily see the password.

http://download.paipai.net/texts/components.htm

However I am getting untracable errors from time to time now. Do you you guys know what these mean?

 

[ESquared]

Just be aware (not specific to this thread, but general knowledge) that MD5 has been considered "compromised" because of hash collision exploits. There are other hashes (whose names unhelpfully escape me at the moment) which are better accepted.

 

[ironhide1975]

I tried using this and ran into a slew of problems with it crashing and bringint stuff down.

Is there any code that will just turn text into a hash. For example, if I just want to convert the word 'blue' into a funky string and then be able to de-convert, that's all I'm looking for. I pretty much want to prevent someone who can get access to the database from being able to automatically determine a user's password.

 

[ESquared]

If you can deconvert, that's not a hash. Hashes are designed to be one way (based on current computing technology).

If you just want to mildly obscure stuff, an easy way would be to store ANSI strings in a Unicode column without conversion, so each two characters of the ANSI string get stored in one Unicode character.

store password: select convert(nvarchar(50), Convert(varbinary, Convert(varchar(100), 'this is my secret password')))

retrieve password: select convert(varchar(100), convert(varbinary, YourPasswordColumn))

More complicated would be just a simple substitution cypher. Search for that online. But you'll have to write some code that substitutes letters in a string one at a time.

 

[ironhide1975]

Is the above the sql state or ASP?

 

[ESquared]

oh, sorry, it's SQL. If you're writing to a database there's no reason you can't make the transformation as part of the SQL code. But if you must do it in ASP it might go something like this:

'Function AnsiCharactersToUnicodeByteString

Function AtoU(TheString)
   Dim i
   For i = 1 to Len(TheString) Step 2
      AtoU = AtoU & ChrW(Asc(Mid(TheString, i)) * 256 + Asc(Mid(TheString & Chr(0), i + 1)))
   Next
End Function

This function will destroy any Unicode string that you pass in by dropping the most significant byte of each character.

A problem I hadn't considered before is that the length of the password, when stored byte-wise as unicode, may not be preserved correctly. That shouldn't be a problem as long as the comparison is made by passing the supplied login-attempt password through the same conversion, instead of trying to convert the unicode-stored string back to ansi. (If you have an odd number of ANSI characters, you might end up with an extra 0-byte character on the end after to-and-from Unicode.) I suppose you could always remove any extra zero byte.