Hi,
I need some help with storing password in mysql database or something similar.
i used to store the password in database using md5() function but there is no way to retrieve thepassword back.

Now i want to know that -
is it standard and secure way to store password?
is there any other technique to store password so i can retrive it back?

Any advice on this would be highly appreciated.
you can my quwstion in other websites
Thanks

- But that is the whole idea behind it - NOT TO BE ABLE TO decrypt passwords, the encryption process being just one-way. In almost any given scenario, you'll find the password being encrypted and stored the first time you enter it.

From next time onwards, whenever you login, the newly entered password is again encrypted - the matched against the stored & encrytped form in the database.

For security reasons password decryption routines are never built into the system. Why do you think, 99% of the web-based services (the more secure ones) never e-mail you your password, but instead ask you to set a new one when you forget your old one. SIMPLE - because your old password cannot be decrypted and mailed to you.

Having a decryption system in place (even if it is not accessible to outsiders) opens up the doorway for a prodigal system administrator or some lesser mortal in the same office, to have a means to decrypt the passwords of other users and have some fun with 'em

Take for example - even on Linux, a sysadmin cannot KNOW or FIND OUT what a user's password is. In case it is lost or forgotten, at best he can reset it to something that the user desires.



The standard technique (one-way) is the most secure you can get, although you can use some other routine and not just a simple MD5 hash.

If you're implementing this in your own application, you can easily use MySQL AES_ENCRYPT () function to store your passwords in an encrypted form (only constraint - the storage field in mysql has to be declared Binary).

AES_ENCRYPT (Advanced Encryption Standard), however has a matching decryption function too - AES_DECRYPT - with which you can achieve what you're seeking to do... but this just serves to weaken the security mechanism - like a weak-link in the chain.

Besides, to use either of these functions, you've to use a Secret Key - sort of a master password, which will be used to encrypt the stored passwords. You need to have this handy during decryption too..or else you can never get back the original pass.

One idea, in case you want to implement this method, is to generate this secret key dynamically for each user based on some other stored data, say their name/address/phone/date of birth etc.. so each user will have a separate secret key, with which you encrypt/decrypt their passwords.

Example:
Some stored fields in the database:
============================

• UserID    [/tab][tab]--> Some Autoincrementing ID maybe
• First_Name    [/tab] --> Joseph
• Last_Name[tab]--> Somebody
• Phone    [/tab][tab]--> 123456789
• BirthDate    [/tab]--> 10/12/1900
• Password[tab]--> mypassword

Once the user enters all the details (including a plain text password) in the web-form, I use a routine to:

• Take the middle two characters of the First_Name = se
• First and last character of Last_Name = Sy
• Last 3 digits of Phone = 789
• First two digits of birthdate = 10

I get my secret key = seSy78910

Now I use this to call the AES_ENCRYPT function and encrypt my password and put it in the password field in the DB along with another INSERT instruction to store the rest of the data:


There.. that statement should update the password field in your db with the encrypted form. By issuing these two statements together I can use the LAST_INSERT_ID to get the last inserted ID of the user (depends on the auto-incrementing field) and update the password.

OR,
You can issue both statements together in a single set of instructions, in this format:


Since the key to encrypt is being dynamically generated using some string manipulation routine, it'll always be unique for each user and quite secure in a sense. Only thing that you'll have to safeguard is this Key Generating Mechanism. If this falls into someone else's hands he can decrypt anybody's passwords in your db. So use some pretty ingenuous and complicated routine to generate this key.

Hope this will put you on the right track..

Regards,
m^e

you can write your own encryption and decryption functions to encrypt/decrypt the passwords but in my opinion the best is to use the way not to have a possibility to decrypt

WOW, m^e, thank you for this explanation. It really sheds light on some questions I have been aksing for years.

Serious, man, this is the first time I *really* understand one-way versus two-way encryption. Someone famous said, the people which can expain complicated matters with simple words are the real geniuses.

I don't want to get into brown-nosing (remember, m^e, I used that term in my first post here 15 days ago), but this is an excellent example. Let me quote Albert Einstein, whom I admire among other things just for that, with another example: When asked how to explain the wireless telegraph, he responded, "The wireless telegraph is not difficult to understand. The ordinary telegraph is like a very long cat. You pull the tail in New York, and it meows in Los Angeles. The wireless is the same, only without the cat."

Hahahaha thank you for that curare. That was simply a brilliant example. Thanks for the terrific new addition to my quotes & phrases handbook

And since you brough the term brown-nosing up, I remember seeing an extremely hilarious rendition of it on Webster.Com..



What can I say except - "Very well put"