6

Possible Duplicate:
How to securely hash passwords?
https security - should password be hashed server-side or client-side?

I need to make a request to a web server, the only information I have from the member is an account number and password. The account number can’t be encrypted because I need that information to look up the members record. I would like to encrypt the password before passing it to the web server. But I don’t have any secret key to encrypted the member password, the application can be reversed engineered. My question is can you encrypt a password using that password?? Like MySecretKey is encrypted using MySecretKey as the password. I don’t know if this is possible even if salt is added. Any advice?

Community
  • 1
kwolbert
  • 61
  • 1
  • 2
  • 2
    See http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords and http://security.stackexchange.com/questions/17421/how-to-store-salt for guidelines on password storage. – Polynomial Aug 29 '12 at 06:14
  • How would you recover MySecretKey once you've encrypted it with itself as the key? :) – Thomas Aug 29 '12 at 06:40
  • 1
    Search on this site for "passwords". Folks have already answered in great deal how to handle passwords. The short version is: (a) use SSL, and (b) on the server side, hash them using a slow hash designed for password hashing. But read the materials on this site, as your question has already been answered. – D.W. Aug 29 '12 at 05:27

2 Answers2

5

To answer your specific question, then yes, of course, you can encrypt a piece of data using another piece of data as key, even if both the data and the key happen to be identical. But what would that achieve ? Decrypting would be difficult: you need the key to decrypt, and you do not have the password until you have decrypted it...

"Self-encryption" could be viewed as a kind of hash function: a deterministic transform of some input data, in a way which can be reversed. Hashing is the proper framework for password storage (where, in fact, the password is not stored, only a password verification token). However, growing home-made hash functions is known to be hard; when cryptographers want to build a hash function, they take a lot of time because they need to be sure that the function is secure, and you cannot know that just by looking at it.

Also, secure hashing is not, by itself, sufficient. You need a SLOW and SALTED hash. This subject has been beaten to death several times on this site, see for instance this question or that one. The comprehensive answer being: use bcrypt.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • But I do have the password in our database, using the account number i can retrieve the password from our database use it to uncrypt the password and check if database password matches the unencrypted password sent to webserver. The password is already sent hashed and is hashed in database. –  Aug 29 '12 at 15:51
  • @kwolbert If the password is hashed in the database and you receive encrypted data, where are you going to get the password from to decrypt the encrypted password? You have an irreversible hash and cryptotext that you don't know the key for. – Jeff Ferland Aug 29 '12 at 18:30
1

I would like to encrypt the password before passing it to the web server.

I think this is what your question is really about. Use SSL. Don't roll you own method of trying to permute the password. If it's encrypted in transit with SSL and compared to a hashed version (preferably something suitable for passwords like bcrypt as Tom Leek pointed out), then you've got the best practices setup.

Community
  • 1
Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171