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?

  • 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, 2012 at 5:27
  • 2
  • How would you recover MySecretKey once you've encrypted it with itself as the key? :)
    – Thomas
    Aug 29, 2012 at 6:40

2 Answers 2


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.

  • 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.
    – user12543
    Aug 29, 2012 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, 2012 at 18:30

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.

  • The request is over a secure socket, just wanted this incase it fails
    – user12543
    Aug 29, 2012 at 18:45
  • @kwolbert In that case, the same question has been discussed at security.stackexchange.com/q/8596/836.
    – Jeff Ferland
    Aug 29, 2012 at 18:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.