Timeline for Password reset system code system vs long hash
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 3, 2014 at 8:14 | history | tweeted | twitter.com/#!/StackSecurity/status/484611248974495744 | ||
| Jul 2, 2014 at 17:09 | comment | added | Callum | @Fleche & Andrew Hoffman I agree. It's a popular commercial product and that's as it as is. We have removed the user-specific information already and don't currently use it in production. | |
| Jul 2, 2014 at 16:41 | comment | added | Fleche | The current tokens are actually harmful, because they mix in the password while using an extremely weak hash algorithm. This is an open invitation for an attacker to intercept a token and start a brute-force attack against the password. Whoever wrote this doesn't know what he's doing, so you'll have to replace this either way. | |
| Jul 2, 2014 at 16:38 | comment | added | Andrew Hoffman | @imukcedup that reset key function seems to be nothing but wildly stabbing in the dark. No offense intended, but the only necessary part of that is the random number generation. | |
| Jul 2, 2014 at 15:57 | answer | added | PwdRsch | timeline score: 3 | |
| Jul 2, 2014 at 15:48 | comment | added | AlexH | +1 for having other options than email to provide reset tokens. You can also introduce security questions to provide the "something you know" combined with "something you have" (something you have being the reset token valid for 2 hours). | |
| Jul 2, 2014 at 15:46 | comment | added | Andrew Hoffman | I think having them not have to click a link is a good idea. However I would make the password reset workflow very intuitive and convenient. Possibly let them add a phone number so they can receive the token through SMS. | |
| Jul 2, 2014 at 15:45 | review | First posts | |||
| Jul 2, 2014 at 15:51 | |||||
| Jul 2, 2014 at 15:41 | comment | added | Callum | It wasn't me who created the current system, its a commercial piece of software. Here is the current function which creates the reset key. md5($userid . rand(100000, 999999) . $password); | |
| Jul 2, 2014 at 15:39 | comment | added | Fleche |
A lot of this sounds rather strange. You create an MD5 hash of what? What's the point of the hash, anyway? The proper way of generating tokens would be to read n random bytes from a source like /dev/urandom and then encode them with a human-friendly format like Base64. And why can't you include this token as plaintext?
|
|
| Jul 2, 2014 at 15:37 | answer | added | Andrew Hoffman | timeline score: 2 | |
| Jul 2, 2014 at 15:36 | comment | added | schroeder♦ | If all services made a move to stop sending links, then that might work, but you are working against 'industry-standard practice', which is not going to help reinforce the lesson to your customers. I think it's overkill. (I run a service that teaches users about phishing) | |
| Jul 2, 2014 at 15:34 | comment | added | Callum | @schroeder My thoughts would be if we didn't send links via email and made our customers aware of this it would help stop phising attempts. Not really education benefits in general phising but it would hopefully stop our customers from clicking links to our website in email. It mabye overkill | |
| Jul 2, 2014 at 15:31 | comment | added | schroeder♦ | Many major services use links as password resets. I'm not sure what educational benefit you will derive from removing all links from your emails. | |
| Jul 2, 2014 at 15:25 | history | asked | Callum | CC BY-SA 3.0 |