Creating Random(ish) String of Characters 3

[Tama]

Hi there

I want to change an e-mail address like "someone@somewhere.com" into a string of random(ish) looking characters like "a54fdgfd689s6df9sdf" and then be able to change the string of characters back into an e-mail address.

The idea is that I'm sending out an e-mail to all the users of a website I run, at the bottom of each e-mail will be a line that'll go "If you've forgot your password please click:

http://www.mydomain.com/iforgotmypassword.php?a54fdgfd689s6df9sdf

and you'll recieve a new password"- it'll then take the string, match it to their e-mail address on my SQL DB and fire back a new password.

I don't think it has to be super-encrypted, just something URL friendly would do.

Any comments, suggestions etc. welcome

Cheers
Tama

I do my sums on finger and thumbs.

 

[Foamcow]

This might help, but I think it's a one way function so you will not be able to get the email address back out of it.

http;//

http://www.php.net/md5

You may need to rethink your approach. You would have to, for example, compare the encoded string to the encoded email addresses within your database.
There has to be a more efficient way though.

Hope that is of some help.

 

[RobBroekhuis]

You could go with the real basic kid encryption method - assign each of the valid e-mail-address characters to a
different character (which could include non-email-valid characters, just to make it more interesting). Not "encryption", but you could make it rather non-obvious, anyway. And real easy, too. Something like:

$plain="ABCDEFG...Z0123456789@_-";
$code="9F-3DQM*n(8q........."; (same length as above, no duplicated characters)

function encode($s) {
$c="";
for ($i=0;$i<strlen($s);$i++) {
$c.=$code{strpos($plain,$s{$i})};
}
return $c;
}
(and the reverse for decoding)

Even simpler, you could use rot13 encoding, if you want to use a built-in function.


Rob

 

[sleipnir214]

The thing is, you want the link to be difficult to reproduce.

One system I use is a token system.

The user opens an form which accepts a userid only and submits to changepasswordscript1.php.

changepasswordscript1.php performs the following actions:[ol][li]perform garbage collection on the change_password table[/li][li]fetch the email address of the user (required to generate a user account and verified by emailing the user a link to click to a verify script) from the user table[/li][li]generate a UUID (Universally unique identifier -- this was on Linux and I used the uuidgen function externally)[/li][li]add the userid, UUID, and a timestamp to the change_password table (the timestamp was for the garbage-collection mechanism -- a user token was only good for 3 hours)[/li][li]send the user an email with a link like [ignore]

http://www.foo.foo/changepassword2.php?uid=theusersid&id=theUUID

[/ignore][/li][/ol]

When the user clicked on the link in the email generated, changepassword2.php performed the following actions:[ol][li]perform garbage collection on the change_password table[/li][li]verify that an entry in the table existed with that userid and UUID[/li][li]produce a form with entries for the new password (twice, for verification) and hidden fields with the userid and UUID. The form submitted to changepassword3.php[/li][/ol]

changepassword3.php performed the following steps:[ol][li]perform garbage collection on the change_password table[/li]verify the userid and uuid against the change_password table[/li]use the password values submitted to change the user's password in the users table[/li][li]remove the currently-used userid and uuid from the change_password table[/li][/ol]

You don't need to perform any encryption, but you need a token with an expiration to change your password, and that token was only sent to the on-file address.


Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[RobBroekhuis]

That's a wonderfully rigorous approach - but I don't think Tama's application calls for that level of rigor, since the email must still be matched to the internal database. I may be wrong, though.


Rob

 

[sleipnir214]

Well, the site in question allowed parents to pay for school meals with a credit card, so I was protecting information about children. The rigor was called-for.

But if you're going to use encryption, you should use strong encryption. Let one user figure out you're using rot13 to obfuscate the email addresses to verify the ability to change a password, and you might have a problem.

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Foamcow]

I dont think Tama wanted strong encryption, but reading between the lines I think he needs it.

Tama: If the string is somehow linked to a password or even just an email address then it HAS to be secure to maintain user privacy.

 

[Tama]

Hi guys

Wow, thanks guys - lots to think about.

The effect of the URL being opened would just send an e-mail with a resetted password to the user. I can imagine that if one of us went to a website such as "eBay" and went to an address such as this:

http://cgi3.ebay.com/aw-cgi/eBayISAPI.dll?UserIdRecognizerShow

I could get an e-mail sent to anyone I:
1) Know the e-mail address of
2) Knew they were registered on eBay

With my proposed system some would have to:
1) Know the e-mail address of someone
2) Know they were a registered user on my site
3) Be bothered working out the decoding system I used.

And they would succeed in sending a reset password to someone's e-mail account. I'm sure that even the most pathetic l33t hax0r has better things to do with their lives.

I suppose if I wanted to be a bit more secure I could set it up the page to only open once for 1 IP address every hour. But I honestly don't think there will be a problem.

Anyway - I'm going to investigate FoamCow's and RobBroekhuis's suggestions. Sleipnir's system looks excellent but probably a bit overkill since my site has nothing to do with kids, or credit cards (that sounds a bit dodgy when I put it like that.)

Cheers
Tama

I do my sums on finger and thumbs.

 

[RobBroekhuis]

I just realized I forgot to include the period in my list of valid e-mail characters. And you have to decide about how to handle upper/lower case, if you use my approach.
The MD5 approach will work too - you'll need to run a query against the email field in your table, comparing the MD5 hash of the field to the querystring returned. Actually, that's by far your easiest approach, and secure, too.
Good luck!


Rob

 

[Tama]

OK - don't slap me for this (though I probably deserver it) - How do I un-md5 an encrypted string - or is that not possible?

I have a way around it - but I'm still curious.

Cheers
Tama

I do my sums on fingers and thumbs.

 

[Foamcow]

I don't think you can.
If you could it wouldn't be very strong encryption ;-)

This is what you do with, say, a password.

Store the user's password as an md5 string in a database.
Then whenever the user enters their password md5 that too and compare the 2 md5 strings.

 

[RobBroekhuis]

Or, in this case, e-mail address. Your database contains the actual e-mail address. The querystring you generate is an MD5 hash of an actual e-mail address. So when the user requests his password to be mailed, you get the MD5 hash, and can then run a query against your database
.... where MD5(email)='$queryhash' ...


Rob

 

[Tama]

Hi guys

I got it working last night. I used a combo of md5 and Rob's kid encryption method he posted above - just for the hell of it.

It's working really well - thank you for all of your help.

Cheers
Tama

I do my sums on fingers and thumbs.