Email Password Max field?

[mustang_sally_85344510]

Having an issue with live site...
On "Email Password" the number of charactors in the field are about 34 that are sent to the user.
Security Assist has the field max field empty.
But on the working site. Only allowed to put in about 15 charactors.
In order to be able to allow a user to put in the email password fields, I had to change my field settings to 50 to be able to accomadate 40 charactors.....?....
Why is this?
Also, is there a different fix?
Thank you in advance for your help. :)

[Ray Borduin]

I'm not sure what would cause the problem you are describing.

Do you have a sample url where I can experience the problem? That may be easier than explaining it.

[mustang_sally_85344510]

Hi,
Thank for being willing to help me out here! :)
You will have to go through the whole registration process.
Here is the link.
http://bowlingtournaments4u.com/visitors_Registration.php

[Ray Borduin]

OK... just so I know what I should be looking for.... what page demonstrates the problem and what are the exact steps I can follow to reproduce or see the error?

[mustang_sally_85344510]

First you need to register.
You will be redirected to a My Bowling page.
click on Log out....
Try logging back in again with the wrong password.
You will then go to a email password page.
Put in email.
Check email ....get password.
Try logging back in with the emailed password....

Doesn't work :(

[Ray Borduin]

This is because you are using an encrypted password.

You can't email an encrypted password. Please view the tutorial on encrypted passwords.

You would need to give them a page to reset their password since it is encoded, you can't email it to them directly.

[mustang_sally_85344510]

Redid the emailPW.php page and get this error message on the working..(or should I say NOT working page).
Parse error: syntax error, unexpected T_STRING, expecting ')' in /home/bowlingt/public_html/visitors_EmailPW.php on line 74

[Ray Borduin]

what is on the page: visitors_EmailPW.php on line 74?

[Ray Borduin]

In order to keep this forum somewhat organized, you should really start a new thread to start talking about a new topic.

[mustang_sally_85344510]

sorry. ...

[John Langer]

This is because you are using an encrypted password.

You can't email an encrypted password. Please view the tutorial on encrypted passwords.

You would need to give them a page to reset their password since it is encoded, you can't email it to them directly.

Hi Ray, sorry to hijack this thread but it's the same subject / problem.

You say "You can't email an encrypted password. Please view the tutorial on encrypted passwords." When I view that tutorial (http://assets.webassist.com/solutionrecipes/114_securityassist/07_send_password.swf) the very first page is a list of things that the tutorial will cover. The last item is: "Email new unencrypted password". At the end of the tutorial there is an example of the emailed password that is indeed unencryted. So if it can't be done why is it saying it can in the tutorial? I have discovered that indeed it doesn't happen. All that happens is that it emails the "encrypted" password, which is useless of course. I've revisited the tutorial several times now and always with the same result.

You then say in your previous reply "You would need to give them a page to reset their password since it is encoded, you can't email it to them directly." I wonder if you could take the time to explain how this can be done when the user is not logged in and indeed have forgotten their original password anyway? I'm a bit confused by that one.

I really am in a dilemma here as I am redesigning an existing site with existing encrypted passwords (about 250 of them). I need a way of sending the user a new password that can be entered into a login form that encrypts the password to match what is in the database.

Any help, ideas would be appreciated.

Many thanks,

[Ray Borduin]

1) This is not in conflict with what I stated.

The tutorial has "Email new unencrypted password"

I stated: "You can't email an encrypted password."

The directions don't say "Email new encrypted password" because that isn't possible as I have stated... The tutorial covers scenarios where the password is not encrypted... that is the difference.

Since it uses one way encryption you can't unencrypt once it is encrypted. It is either stored unencrypted or encrypted and if it is encrypted it won't help to email it.

You can set a random variable in the user table and email that to the user in a link back to a page where they are allowed to update their password by specifying a new one. You match the userID to the random variable and allow them to then update the password and encrypt it and store it in the database again. The tutorial should cover this.

[John Langer]

Hi Ray,

Sorry if I sounded confrontational, that was not my intention. I'm just having problems and felt that the tutorial was a bit misleading.

1) The tutorial does indeed state "Email new unencrypted password". That's the point.

The tutorial lists what it is going to teach. The whole point is to encrypt passwords. The preceding ones in the series talk of how to encrypt passwords.

The content summery of this particular tutorial states:
"Send password page:
Generate new unencrypted password
Update database with encrypted value
Email new unencrypted password".

Following the tutorial letter by letter it creates a new unencrypted password, enters that password into the database ENCRYPTED and then emails that password to the user (still encrypted even though the title of this is "Email new unencrypted password). I understand that it cannot send it unencrypted but right at the end it shows an example of the email received with the password UNENCRYPTED.

I'm sorry if you think I'm being awkward but I'm merely pointing out that this particular tutorial is a bit misleading.

Maybe we are talking about two different tutorials. This is the one I'm talking about http://assets.webassist.com/solutionrecipes/114_securityassist/07_send_password.swf

Also you state "The tutorial covers scenarios where the password is not encrypted". I'm sorry but the tutorial does just the opposite of that. The whole series, in fact, is about encrypting passwords.

Sorry to be negative. Now I know for sure that it can't be done I shall have to think of another way.

My thoughts are to to place the new password into the database UNENCRYPTED. Send this to the user by email and provide a link to a new login page (only used for this) that is NOT set up to encryption. Then the user can login and from there immediately change their password to a new ENCRYPTED one.

[Ray Borduin]

I believe you could do that as well... sorry if I sound confrontational. I'm not disturbed I just try to drill the point home sometimes.

The truth of the matter is I haven't gone through that tutorial recently I'm not really sure what it involves.

I just know that then only encryption we offer currently is SHA1, which can't be decrypted and therefor can't be sent in an email.

There are a variety of options for how to get around this:
1) You can randomly generate a new password and email the new password.
2) You can send them to a page where they specify a new password.
3) You send them to a specialized login page

The only thing you cannot to is take something that is encrypted and make it unencrypted at any time.

[John Langer]

That's all right Ray.

Now I know I'm not doing something wrong then I can proceed with a work-a-round (1, 2 or 3) (Probably 3).

Many thanks.

[Ray Borduin]

It seems three would be possible, but really it is the same thing as 2 since you would probably still want to include a random url parameter so you could verify they actually got the email and didn't know to go to the specialized login page directly.

[John Langer]

It seems three would be possible, but really it is the same thing as 2 since you would probably still want to include a random url parameter so you could verify they actually got the email and didn't know to go to the specialized login page directly.

Mmm. Bit beyond me that :)

I can see how two can be done as they would have to login to do it wouldn't they? and the reason for all this is that they can't login.

Could I just ask you to explain the random url parameter bit?

Many thanks for taking the time with this. It's appreciated.

[Ray Borduin]

SecurityAssist includes an option to create a random password.

You use that to store a session variable with a random password.

You use that session variable to update a field you add to the users table to store it. You update the same account that you are sending the email to.

In the email you use that same session variable to append a parameter in the link back to a page on your site like: http://www.yoursite.com/updatepassword.php?verificationCode={session variable with random value}

then on the page updatepassword.php you can allow the user to update the record that matches the verificationCode and email address they entered. You are ensured it is the correct user because they got the email with the random code.

Now the alternative is that you just store the random password you generated into that session variable as the new password, and just send that to them as their new password and let them update it if they want on their own.

[John Langer]

Ah! <Light bulb moment> :)

That makes perfect sense now. Many thanks Ray, you've put me in the right direction.