eliminating temporary passwords / expiring email links

[Soupala]

New feature proposal.

What about changing the default method for how UserCake is currently dealing with forgotten passwords.

It's not an ideal user experience or security practice to email passwords to users, even if the password is only temporary. We can't assume that users will change their password, and it's just another step the user shouldn't have to worry about.

Once they click on the link, that should immediately take them to a screen that prompts them to reset their password.

Should UserFrosting have to stay consistent with UserCake on this issue, or would this be a candidate just for UserFrosting's roadmap?

[Soupala]

I put it in the subject line, but forgot to mention that the link to reset the password should expire after a few hours.

[alexweissman]

I agree. It might also be worth implementing an additional level of identity verification, such as asking them to enter their username, before allowing them to reset their password (after the reset link has been sent; see the flowchart at the bottom of http://www.troyhunt.com/2012/05/everything-you-ever-wanted-to-know.html).

Would you want to take charge on implementing this feature?

[Soupala]

I can, although it might be several months till I can finish it. So if anyone is really anxious and wants to take it, let me know.

[lilfade]

Wouldn't it be easier to send the auth code to reset the password and when the user click the link we check too see how long it's been since the auth key was sent if say more then 6 hours or whatever time frame make them re validate and start again?

[alexweissman]

@Soupala thanks! I'm going to be working mainly on the auth system over the next few weeks, so maybe after that would be a good time to implement this feature.
@lilfade yes, we should definitely have an expiration time for the auth keys. But, requiring an extra piece of information would help in the event that the user's email account has been compromised somehow.

[lilfade]

Maybe some password reset question could be implemented eg. "Whats your favorite color" or "What hospital were you born in" ect. most people won't forget such question as these as easily as there password.

[alexweissman]

Yeah, we could do something like that, although we'd need something difficult for a hacker to glean from peoples' social media accounts. See http://goodsecurityquestions.com/. We need questions that people won't forget, are universally applicable, and cannot be easy deduced from social media.

[alexweissman]

We could also possibly make the questions a feature that admins can configure themselves ;-)

[lilfade]

Well we could have the user set the question and when the user requests a lost password we could have them choose the question say using radio boxes with 2 other questions if they select the right question and provide the answer as well. We could do this 2 time and have 5 questions from the user this would make it pretty secure I'd say, any ideas?

[Soupala]

tricky issue. If we leave it to the users to create their own, we can't
trust they'll create good ones. But on the other hand, if we come up with
a list of questions that can't easily be guessed or gleaned from stolen
documents, that would be good.

On Wed, May 7, 2014 at 9:38 AM, Alex Weissman notifications@github.comwrote:

We could also possibly make the questions a feature that admins can
configure themselves ;-)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-42450947
.

-Mica

Mica Cardillo
soupala.com
@Soupala http://www.twitter.com/Soupala on Twitter
Profile http://www.linkedin.com/pub/mica-cardillo/13/b37/a35 on LinkedIn
541.840.7245

[lilfade]

I updated the lost password page need to make a few fixes and drop alot of debug code but basically i changed it so there is a configurable time setting (by admin) for passwords to expire. When you get the email it will direct you to the page to change your password rather then send you a password. And to change the password you will also need to varify the username associated with the activation token.

Just need to touch everything up and we can probably close this feature as well.

[lilfade]

Actually i need to do some work on this still to make sure everything is working before i make a pull but that should happen today sometime ^_^

[alexweissman]

Sweet! I'll be gone for the weekend, if I don't get a chance to look at it before I leave, I'll see it on Monday :-D

[lilfade]

Thats cool, at the moment its really rough and i still need to fix it up but i finally got the forgot_password.php to load 2 forms and process it with the js depending on what form loaded. It works though just gonna rewrite it a little bit to make it all work a bit better ^_^. yea no rush on this one though im not sure how this weekend will work out for me yet may have time or may not xD

[lilfade]

Ok this should all work wanna check this out (https://github.com/lilfade/UserFrosting/compare/alexweissman:butterflyknife...master) and let me know what you think of the changes and if you think we need anything else added. I still have to add the new msgs to the lang array but thats about it i think.

[alexweissman]

Nice, looks fantastic. This is getting me to thinking, that rather than keeping all of these seldom-used variables (activation requests, password requests, etc) directly in the user table, we could keep them in a separate table. Then we could keep a sort of history of account events for users, and the user table would be less cluttered.

[lilfade]

did you just want to use something like this then: ?

User	User Extra
id	id
	user_id
user_name	activation_token
display_name	last_activation_request
password	lost_password_request
email	lost_password_timestamp
active
title
sign_up_stamp
last_sign_in_stamp
enabled

or maybe we can do something like

User Extra	User Extra 1	User Extra 2
id	1	2
user_id	1	2
request_name	lost_password_request	activation_token
request_value	1	b20913e533fd20dade5c03e0d46a995c

only issue i can see is if we hold all values of a user's request is we might end up having a very long table of data but we could setup a function to clear this table on a set schedule.

[alexweissman]

Hmm, I like the second although we'd need every entry to have a timestamp so we can identify the most recent value. Let's wait on this, it's not critical to pushing butterflyknife. We'll try to gauge what people want for future releases.

[alexweissman]

Implemented in butterflyknife.