-
1. Re: Question about dynamic field with MD5
bregent Jul 29, 2009 11:39 PM (in response to Mike_Watt)>Anyway, the short version is, how do I translate a DB entry with MD5 back to plain text for display in a page?
Sorry Mike, I don't have an answer for you but...are you sure you need to do that? Typically, you do not want to display a password in clear text to the user. In fact, you would typically force the user to enter their old password (obscurred in a password type field) before entering their new password.
-
2. Re: Question about dynamic field with MD5
Mike_Watt Jul 30, 2009 6:06 PM (in response to bregent)Well, it is being displayed in a password field. But the php would be the same regardless of whether it was a text field or password field, I was just trying to keep the post as simple as possible.
It's just frustrating because I've gotten so close and I'm just stumped on one piece of the puzzle. -
3. Re: Question about dynamic field with MD5
bregent Jul 30, 2009 6:37 PM (in response to Mike_Watt)Sorry Mike, my point wasn't really whether you were using a text or password field. It was really just asking why you need to retrieve and display the current password at all?
-
4. Re: Question about dynamic field with MD5
Mike_Watt Jul 30, 2009 7:08 PM (in response to bregent)I'd always done it this way because you have to be logged in to access the update page anyway, and it only gives you access to your own stuff. So, the thought was that then entire record can be displayed in a form and the user can update those fields they want and all others will simply update with teh same info (because the field was dynamically populated with the info that was already in the DB).
If the password field is not populated then when the update form is submitted it will erase the password from the DB, right? I mean, I could leave that field out and have password not receive a value, but then how would the user update their password when they need to? -
5. Re: Question about dynamic field with MD5
bregent Jul 30, 2009 8:44 PM (in response to Mike_Watt)>I'd always done it this way because you have to be logged
>in to access the update page anyway, and it only gives you
>access to your own stuff.
Right. But users sometimes leave their work area with apps running or fail to correcty log off. That's why many web apps require you to enter your current password on the form with the new password they are changing to. Or, they are required to enter their password before gaining access to their account page, even if they are already logged into the app. But of course these measures may not be necessary depending on how much security you need.
>I mean, I could leave that field out and have password not receive a value,
>but then how would the user update their password when they need to?
Remember it's a good idea to use a 2nd confirmation password field (especially when they are obscured) to reduce the likelyhood of typos, - so you need to validate those fields anyway. So you can either
1) have the password fields with the rest of the account info but do not populate them. Then test if they have values, make sure they are the same, and if they are, include them in the update statement
2) have a seperate page for just password changing.
-
6. Re: Question about dynamic field with MD5
Mike_Watt Jul 30, 2009 9:45 PM (in response to bregent)You're right. This particular site doesn't really need tough security (so little, in fact, that I was tempted to store pwords in plain text at first) but it would probably be smarter to get into the practice of doing things "right."



