views:

96

answers:

2

Hello,

I'm writing a program where I use MD5 to hash login details before I send them to a server, but there I have to compare it to a blowfish (jBCrypt) hashed password retrieved from a database.

jBCrypt uses:

if (BCrypt.checkpw("candidatePassword", hashedPwd)) {
// they are the same
}

The problem is that, I don't have a candidate password to test. How can I have both secure transmission of my login details and secure storage of these details on the database. What is the best way to approach this?

I use username, timestamp, random bytes and password to create my md5 digest value.

Thanks, Vladimir

+3  A: 

Given only the two hashes, you can't1. Hashes are designed to be one-way; you can't recover the original data from the hash, which is why storing hashed passwords is deemed more secure than storing encrypted passwords.

So the only way to validate data against a hash is to hash the data and see if the result matches.


1 Of course, words such as can't and only really mean "unless you use brute force...." The theories behind these algorithms prove that they are "reasonably" secure, but one must always remember the difference between theory and practice: in theory, there is no difference.

Adam Liss
A: 

Adam is right: if you hash multiple values together, you cannot get them back from the hash.

It sounds like what you really want is encryption: an encrypted message is meaningless to an adversary who intercepts it, but can have its value(s) extracted on the other end by a friendly party.*

Security for webapps is its own special field with many resources you could look up on how to do this.

A suggested approach would be this:

  • From the client side, create a hash of the random bytes and password. Package the username, timestamp, and hashed value, and securely send it to the server (using SSL, or encryption).

  • From the server, decrypt or otherwise 'depackage' the values, and check the hashed password and the username against the values in the database. It if matches, allow access, if it doesn't, deny.

(this makes the assumption that you're using the random bytes as a 'salt' for the hash. If you aren't, just hash the password, and not the random bytes).

*= This is a very high-level idea of how encryption works, and assumes everything is done properly, and no intermediate step is compromised, etc. etc.

paul.meier
I think the problem is that different hashing algorithms are used on the client and the server, so the hashes won't match even if the passwords are the same. Oh, and "won't" really means "with a vanishingly small probability." I wonder if any other technical field requires more disclaimers than cryptography. :-)
Adam Liss