Storing passwords
Moderator: General Moderators
-
hessodreamy
- Forum Commoner
- Posts: 58
- Joined: Wed Apr 20, 2005 8:11 am
Storing passwords
I currently encrypt passwords to store then in a database. Fine. And when people forget their passwords I would have thought you'd need to send them a new random password and put the encrypted version in the DB.
But how about some sites which, when you forget your password, they email it to you? Am I right in saying that they must be storing it unencrypted?
But how about some sites which, when you forget your password, they email it to you? Am I right in saying that they must be storing it unencrypted?
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: Storing passwords
If they encrypt it they can decrypt it again. If they hash it then they can't really reverse it (ok, it's not impossible to guess via a tedious collision/tunnel proccess).hessodreamy wrote:I currently encrypt passwords to store then in a database. Fine. And when people forget their passwords I would have thought you'd need to send them a new random password and put the encrypted version in the DB.
But how about some sites which, when you forget your password, they email it to you? Am I right in saying that they must be storing it unencrypted?
What I'm trying to say is that hashing and ecryption are not the same
That aside, yes, many sites do store passwords in their plain original format. And no.. that's not the right thing to do
Sounds like you're on the correct track anyway with what you're doing.
-
hessodreamy
- Forum Commoner
- Posts: 58
- Joined: Wed Apr 20, 2005 8:11 am
-
hessodreamy
- Forum Commoner
- Posts: 58
- Joined: Wed Apr 20, 2005 8:11 am
Also how about storing credit card details in session data. (Over ssl)
I would immediately have serious misgivings about it, but if its encrypted is it acceptable?
(I'm only thinking from the point of view of if the information is invalid/rejected, showing them the info they previously entered would be helpful in seeing where/if they went wrong)
I would immediately have serious misgivings about it, but if its encrypted is it acceptable?
(I'm only thinking from the point of view of if the information is invalid/rejected, showing them the info they previously entered would be helpful in seeing where/if they went wrong)
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
I personally wouldn't store it in a session. Can't you use a password protected database for that, even if just temporarily?hessodreamy wrote:Also how about storing credit card details in session data. (Over ssl)
I would immediately have serious misgivings about it, but if its encrypted is it acceptable?
(I'm only thinking from the point of view of if the information is invalid/rejected, showing them the info they previously entered would be helpful in seeing where/if they went wrong)
If you need to use sessions for it you may want to check your session save path and session save handler to keep that data as private as possible. If this isn't a shared hosting server then all that stuff I said is nowhere near as important
-
hessodreamy
- Forum Commoner
- Posts: 58
- Joined: Wed Apr 20, 2005 8:11 am
Re: Storing passwords
They could be using two-way encryption instead of hashing (which I recommend against).hessodreamy wrote:I currently encrypt passwords to store then in a database. Fine. And when people forget their passwords I would have thought you'd need to send them a new random password and put the encrypted version in the DB.
But how about some sites which, when you forget your password, they email it to you? Am I right in saying that they must be storing it unencrypted?
The first sequence you describe is the one I suggest following.
-
hessodreamy
- Forum Commoner
- Posts: 58
- Joined: Wed Apr 20, 2005 8:11 am
Credit card details are just about the most dangerous piece of information on the planet after SSN's. Personally, I'd avoid storing or processing them at all costs.hessodreamy wrote:Also how about storing credit card details in session data. (Over ssl)
I would immediately have serious misgivings about it, but if its encrypted is it acceptable?
(I'm only thinking from the point of view of if the information is invalid/rejected, showing them the info they previously entered would be helpful in seeing where/if they went wrong)
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Anything encrypted can be decrypted. Anything hashed cannot (assuming you use a strong hashing algorithm).oh, now I AM confused. Why would you recommend against encrypting the passwords? Not secure enough?
The reason a password is suggested to be hashed, and not encrypted, is that is has no utility to anyone other than the User. If the server has no use for it, why store an encrypted version at all? At least when hashed it is not recoverable should a hacker or other get access to a list of all user data.
Only change to your user account processes is creating a random password in the Forgotten Password feature, and having to compare a hash generated from the login form's password value, and the hash originally stored from the original password set.
Hashing is more sensible for password protection than encryption...
As Maugrim points out, encryption is two-way. Hashing is one-way. If you capture my hash, you cannot recover my password. If you capture my encrypted password, you can (given sufficient time) recover my password.hessodreamy wrote:oh, now I AM confused. Why would you recommend against encrypting the passwords? Not secure enough?
-
hessodreamy
- Forum Commoner
- Posts: 58
- Joined: Wed Apr 20, 2005 8:11 am