String Comparisons in Windows

General
1

OK guys, I’m stumped…

I’m adding some password authentication to my web app. I take the user entered password, add a string to it and then hash it using Xojo’s crypto module with an MD5 hash. When the user logs in I has the password they enter this way and compare it to the stored hashed password in the database. On OS X, this works just fine, but in Windows, the string comparison fails. Yet, if I look at the hex data of the hashed strings, the hex data is identical! Why is windows not properly analyzing the strings?

And if I use StrComp in binary mode, that function returns the value of 0 correctly when the hashed strings match. Using “=” does not in Windows (works fine in OS X).

Thanks,

Jon

2

Encodings?

3

Shouldn’t really matter. The entered password data and all is all done within the Xojo app. So encodings should all be the same.

OS X does it just fine. Also, I would expect different encodings to vary at the binary/hex level, wouldn’t they?

4

Probably encoding, but you shouldn’t do this. First, MD5 is not considered secure. Second, Crypto provides PBKDF2. At least use that with SHA-256 (SHA-512 preferred) and Crypto.GenerateRandomBytes for the salt.

For even better security, look up Security Through Obesity, or see Thom’s post on the matter.

Unless you’re really not concerned about security, of course.

5

Kem,

Thanks for the info. This particular web app is not a big issue with rock solid security. The authentication is really there just to discourage unauthorized use. But I will take your suggestions and look at implementing them.

Question - As I understand salting, I take the user’s password, concatenate it with the salt and then hash the new string - right? So then when the user enters their password, I need to then generate the salt value again but unless it’s the same value, my strings won’t compare. How can you generate a random salt string on one side and expect to get the same thing later? Maybe I am not applying the salt correctly…??

6

It’s not “all within Xojo”. Reading it back from the database will mess with the encoding (the bytes will be the same, but the “characters” will be interpreted differently by “=”). Use DefineEncoding to match the string you get from hashing the entered password. And no, having the wrong encoding (or no encoding) does not change the bytes, just the way string operations interpret those bytes. Wrong encoding = wrong interpretation = same bytes do not equal each other.

But really, strcomp is preferred here over “=”, unless you’re going to store the values as hex and compare the hex representations. Comparing pure binary data, such as the result of MD5, is best done with strcomp.

7

[quote=109933:@Kem Tekinay]Probably encoding, but you shouldn’t do this. First, MD5 is not considered secure. Second, Crypto provides PBKDF2. At least use that with SHA-256 (SHA-512 preferred) and Crypto.GenerateRandomBytes for the salt.

For even better security, look up Security Through Obesity, or see Thom’s post on the matter.

Unless you’re really not concerned about security, of course.[/quote]

I just read Thom’s post. That’s quite fascinating. I get it. Not sure I need that sort of security here in my application as it’s really designed for private LAN use and there’s really nothing that is needing to be bullet proof secured. I just need a simple lock to keep the honest people honest…Still worth considering beefing it up just so that I have the experience doing so…

8

It matters a great deal

9

You’d store the salt next to the hash.

At the very least, use PBKDF2 with SHA-256. It’s exactly what it was designed for and more secure than what you’re doing.

Are you storing the raw bytes that are returned by the hash? If so, don’t, this is probably where encoding is coming into play. Encode as hex first.

10

[quote=109933:@Kem Tekinay]Probably encoding, but you shouldn’t do this. First, MD5 is not considered secure. Second, Crypto provides PBKDF2. At least use that with SHA-256 (SHA-512 preferred) and Crypto.GenerateRandomBytes for the salt.
[/quote]

Just an update…

I said I was using an MD5 hash. Wrong. It is SHA-512. Just forgot what I put in the code… :slight_smile: