Best practices for password reset

[sneakyimp]

So I remember running across this OWASP article on how to deal with password reminder functionality. Having just read it again, it seems a) really elaborate and b) kinda poorly written.

What does everyone feel are the crucial ingredients for password reset functionality? I've noticed that banks, Google, Twitter, Facebook, etc. seem to collect phone numbers where they can send an out-of-band password reset code if necessary. That seems pretty fancy to me and, although I know Amazon SNS is a way to send such text messages, I wonder if there might be some other affordable way to send SNS messages. The OWASP article is pretty vague but it seems to me it goes something like this:

1) User clicks 'Forgot Password'

2) User goes to page where they enter their email and click GO. They are emailed a 'password reset' message with a link in it.

3) Clicking that link in 'password reset' email takes user to a page they are prompted to answer 'security questions.' I.e., questions they were previously prompted for which are not your password like Mother's Maiden Name, Favorite Color, First Pet, or whatever. You need to answer maybe 2 or 3 of these correctly--article is vague on this point. Q: What happens if a user has never answered these questions?

4) If user screws up on #3 (too many failed attempts? does this use CAPTCHA to prevent brute force?) then we force you to use a "side-channel" (e.g., alternate email address, phone text message, automated voice call) to receive a token. I.e., some random sequence which they must enter in a particular page on the website.

5) Assuming success at step #3 or step #4, we set some session value and take the user to a password reset page where they can enter the new password and then enter it a second time to confirm it.

6) Send 'your password has been reset' email to primary email address on account.

Any thoughts/feelings on this?

[Bonesnap]

This is how I implemented password resets in my current project:

1) User can't log in so he clicks the "forgot your password?" link.

2) Gets taken to a form where he enters his email address (system checks to ensure the email address is in the system).

3) A password reset token is generated, along with the pertinent information (email address, user ID, timestamp, etc.) and stored in the database. The token is only valid for 1 hour.

4) An email is sent to the email address that was entered with a link to the reset page. Link contains the token. Link also contains an additional variable "r" which equals 1. More of a distraction than anything. This must be present and must equal 1 otherwise the reset page won't load.

5) User receives the link, clicks it, and is taken to the reset password page where he can enter and confirm his new password.

6) Upon resetting his password, the token is invalidated (along with any other tokens that might be associated with that email address) and a confirmation email is sent.

I was thinking about limiting the password reset to the IP that requested the reset, but wasn't sure how that would affect mobile users who are not connected to a wifi network.

From what I read my system isn't 100% secure and I should be hashing the token that's being sent to the user but I fail to see the added benefit. Indeed, the token itself is obscured but so what? I mean, all this is predicated on the fact that the email account hasn't been compromised, but my Spidey-sense tells me that if someone's email account is compromised the owner is probably not going to care quite as much about some random service and instead would rather get their email account back. Also, from our perspective, there's not much we can do about compromised email accounts.

I suppose that's what these secret questions are for, but from everything I have read they are way worse than passwords and offer very little protection. Usually the selection of the questions is limited (and the questions are too similar to other websites). Sometimes there's the ability to enter your own. But then there's the challenge of validating these answers. What if the question was "Who was your favourite high school teacher?" and you put "mr. smith", and then 8 months or longer later, you enter "Mr. Smith". Should that validate? Should the answer be exact? Probably should be, right? But then you run into these issues. Seems like a very large can of worms that doesn't need to be opened.

Also, like passwords, people are not imaginative; they are going to choose the same old questions with the same old answers, or very weak questions with very weak answers. Signing up for websites and services is a chore nowadays. People don't like it (which feeds into why they provide poor passwords, poor security questions, and poor answers), so they choose the lowest common denominator to move forward, or they don't sign up at all.

[sneakyimp]

Thanks for your response. The details about your process are really informative too.

Apologies for this lengthy post, but a lot of the OWASP recommendations seem wise and yet introduce substantial complexity and effort. I'm thinking if these recommendations can be implemented/encoded once, it would be a nice library for use again and again.

Bonesnap;11051831 wrote:

This is how I implemented password resets in my current project:
3) A password reset token is generated, along with the pertinent information (email address, user ID, timestamp, etc.) and stored in the database. The token is only valid for 1 hour.

I'm guessing these password reset tokens are stored in their own table? I was thinking something like this:
id
user id
token, probably a lengthy, randomly-generated alphanumeric key. something hard to guess or forge.
nonce/secret chars - some random sequence of chars which can be used to improve security of password reset email (see below)
* expiration datetime

Bonesnap;11051831 wrote:

4) An email is sent to the email address that was entered with a link to the reset page. Link contains the token. Link also contains an additional variable "r" which equals 1. More of a distraction than anything. This must be present and must equal 1 otherwise the reset page won't load.

I tend to doubt the "r=1" is going to help. I might suggest a nonce or something based on timestamps or a hash of some user's email or something but I'm not sure it's going to add anything to the token. If the token is truly random, that's about as safe as you're going to get I would think. If someone intercepts the email to get the token, they also get the link too. On the other hand, if someone exploits the database but not the php code, then they may not know how the nonce gets calculated which would provide a tiny bit more defense. (is this what we mean by 'defense in depth?')

Bonesnap;11051831 wrote:

5) User receives the link, clicks it, and is taken to the reset password page where he can enter and confirm his new password.

If I correctly understand the OWASP recommendations, as poorly written as they are, they propose using the security questions at this point rather than just letting some email recipient (or thief) reset the password.

Bonesnap;11051831 wrote:

6) Upon resetting his password, the token is invalidated (along with any other tokens that might be associated with that email address) and a confirmation email is sent.

Thank you for assiduously including this detail of your process. It might be easily overlooked. It's important to clean up the loose ends for security and other reasons.

Bonesnap;11051831 wrote:

I was thinking about limiting the password reset to the IP that requested the reset, but wasn't sure how that would affect mobile users who are not connected to a wifi network.

Or users who turn off wifi and walk outside to get in their car. Yeah it's been my experience that insisting on a consistent IP can lead to what seem like mysterious failures: the system suddenly doesn't work because my IP changed (and I didn't even know it).

Bonesnap;11051831 wrote:

From what I read my system isn't 100% secure and I should be hashing the token that's being sent to the user but I fail to see the added benefit.

Let's admit it: no system is 100% secure 😉
As for 'hashing' the token, refer to my nonce suggestion above. First time I saw the use of a nonce was in the Authorize.net payment gateway. The API required with each POST that requested payment a digest/hash/nonce which was calculated from some values, I forget what they are. For better security, I would imagine it should be something that hashes together the password-reset-token and something that does not exist in the email which a hacker could not easily guess. Basically, when some dude shows up on the password reset page trying to reset a password, you hash the token with something in your db that wasn't in the email (a user id? perhaps some random salt or chars you stored in your db?). Note that the token's hash would need to calculate identically between the time it is requested from the user and the time they return to your site. You might consider storing the server-side secret chars in your password-reset-token-table (see my suggestion above).

Bonesnap;11051831 wrote:

Indeed, the token itself is obscured but so what? I mean, all this is predicated on the fact that the email account hasn't been compromised

From what I see the token is not obscured -- at least it's not if you have the email. It would be right there in plain sight.

Bonesnap;11051831 wrote:

but my Spidey-sense tells me that if someone's email account is compromised the owner is probably not going to care quite as much about some random service and instead would rather get their email account back. Also, from our perspective, there's not much we can do about compromised email accounts.

In my case, the random service might allow the purchase of quite expensive--although not exactly fungible--merchandise. For most of my projects, the password reset without security questions would be entirely adequate.

Bonesnap;11051831 wrote:

I suppose that's what these secret questions are for, but from everything I have read they are way worse than passwords and offer very little protection. Usually the selection of the questions is limited (and the questions are too similar to other websites). Sometimes there's the ability to enter your own. But then there's the challenge of validating these answers. What if the question was "Who was your favourite high school teacher?" and you put "mr. smith", and then 8 months or longer later, you enter "Mr. Smith". Should that validate? Should the answer be exact? Probably should be, right? But then you run into these issues. Seems like a very large can of worms that doesn't need to be opened.

I certainly concur it's a can of worms but would point out a few things:
Security questions are an additional layer of protection for password reset sequence. They are not used instead of but rather in addition to the email reset loop as an added precaution.
The OWASP article has some decent thoughts on what good questions are, and it discourages letting users define their own secret questions.
* I was assuming I would check answers case-insensitively. Remember that this is just a tiny added layer of security between the password reset email and actually resetting the password.

Some other things about the OWASP recs:

OWASP wrote:

be sure that you collect some means to send the password reset information to some out-of-band side-channel, such as a (different) email address, an SMS texting number, etc.

This to me is where things start to get kinda messy and we start to introduce a lot more logic branching. E.g.:

$other_email = DB_other_email::fetch($blah);
if ($other_email) {
  // use other email;
} else {
  send_token_via_text_message_to_phone_number_on_file($token);
}
// etc
// etc
// etc

Does anyone do this? I can appreciate that it might increase security, but it might also reduce it. Another email address or communication channel exposes another attack angle.

OWASP wrote:

Review Any Canned [Security] Questions with Your Legal Department or Privacy Officer

WTF? Legal liability can be introduced by offering canned questions? sigh.

OWASP wrote:

we would always recommend at least encrypting the answers rather than storing them as plaintext

Not something that had ocurred to me. I'm thinking convert the answer to lowercase before using [man]password_hash[/man]. OWASP also recommends storing the security questions as reversible (i.e., decryptable) ciphertext.

OWASP wrote:

Periodically Have Your Users Review their Questions

While this makes sense, questions arise. What does 'periodically' mean? At what point in one's web application would one prompt a user to do this? After login? On every page access? It also implies that we store a timestamp/datetime with every answer. NOTE: if you use password_hash when storing answers, you can never present them with their previously entered answers.

[sneakyimp]

(continued... 🙁 )

Regarding the password-reset page where you enter your security answers in step #2 here, it says:

OWASP wrote:

Avoid sending the username as a parameter (hidden or otherwise) when the form on this page is submitted. The username should be stored in the server-side session where it can be retrieved as needed.

This is a bit confusing to me. So far the user entered their username, we sent them an email with a token, and they would have clicked the link in the email to get to this page. I suppose the idea is to avoid enabling brute force attacks. Letting a user specify some username and the security questions in the same form seems like a bad idea, right?

OWASP wrote:

Because users' security questions / answers generally contains much less entropy than a well-chosen password (how many likely answers are there to the typical "What's your favorite sports team?" or "In what city where you born?" security questions anyway?), make sure you limit the number of guesses attempted and if some threshold is exceeded for that user (say 3 to 5), lock out the user's account for some reasonable duration (say at least 5 minutes) and then challenge the user with some form of challenge token per standard multi-factor workflow; see #3, below) to mitigate attempts by hackers to guess the questions and reset the user's password. (It is not unreasonable to think that a user's email account may have already been compromised, so tokens that do not involve email, such as SMS or a mobile soft-token, are best.)

Makes sense. I'm sort of wondering about the mechanics of how one will "limit the number of guesses attempted." Obviously, this limit needs to be associated with some time frame. I'm having a bit of trouble picturing some reasonable data structure and/or algorithm for this. Obviously we don't want to limit a user to 3 guesses in 1000 years. We want to detect 3 guesses in fairly rapid succession. Do I need to add more columns to my db table that stores the answers. E.g.,
recent_guess_count
time_of_most_recent_guess
I can imagine checking if time_of_most_recent_guess was less than FIVE_MINUTES ago and, if so, we check if recent_guess_count >= SOME_THRESHOLD and, if so, then we ignore the user and show them some message about too many guesses recently and give them a link to the alternate approach of getting a token sent to some other communication channel. This also starts to get pretty complex and elaborate, logically-speaking. Thoughts welcome.

OWASP wrote:

After step 2, lock out the user's account immediately. Then SMS or utilize some other multi-factor token challenge with a randomly-generated code having 8 or more characters. This introduces an “out-of-band” communication channel and adds defense-in-depth as it is another barrier for a hacker to overcome. If the bad guy has somehow managed to successfully get past steps 1 and 2, he is unlikely to have compromised the side-channel.

Not sure I agree with "he is unlikely to have compromised..." statement but I do see this option implemented by all the big internet companies. Seems the idea is about stymying hack attempts on the primary password reset channel while leaving open the option of using some other channel. Not sure this enhances security as much as provides a convenience.

OWASP wrote:

If you keep statistics on how many times the respective questions has been posed to someone as part of a Forgot Password flow (recommended), it would be advisable to also display that information. (For instance, if against your advice, they created a question such as "What is my favorite hobby?" and see that it had been presented 113 times and they think they might have only reset their password 5 times, it would probably be advisable to change that security question and probably their password as well.)

OK yes this also makes sense but DAMN things are starting to get complicated.

OWASP wrote:

Authenticate Requests to Change Questions

Yes of course yes. Jesus.

Comments welcome. Has anyone else implemented this sort of complicated thing?

Potentially humorous anecdote: My credit card company prompts me not just for my password but also for security question info EVERY SINGLE TIME I login to their website. And yet someone tried to purchase $502 worth of stuff from a PetSmart about 3000 miles from where I live. One wonders if all this caution is really worth it.

[sneakyimp]

OH and almost forgot. This last recommendation pertains to another thread we've discussed lately.

OWASP wrote:

It is important to keep audit records when password change requests were submitted. This includes whether or not security questions were answered, when reset messages were sent to users and when users utilize them. It is especially important to log failed attempts to answer security questions and failed attempted use of expired tokens. This data can be used to detect abuse and malicious behavior. Data such as time, IP address, and browser information can be used to spot trends of suspicious use.

It also introduces still more complexity into this already complicated password reset concept.

[Bonesnap]

sneakyimp;11051845 wrote:

I'm guessing these password reset tokens are stored in their own table? I was thinking something like this:
id
user id
token, probably a lengthy, randomly-generated alphanumeric key. something hard to guess or forge.
nonce/secret chars - some random sequence of chars which can be used to improve security of password reset email (see below)
* expiration datetime

Yes, they're in their own table. The structure is similar:

• id
• user id
• timestamp
• token

sneakyimp;11051845 wrote:

I tend to doubt the "r=1" is going to help. I might suggest a nonce or something based on timestamps or a hash of some user's email or something but I'm not sure it's going to add anything to the token. If the token is truly random, that's about as safe as you're going to get I would think. If someone intercepts the email to get the token, they also get the link too. On the other hand, if someone exploits the database but not the php code, then they may not know how the nonce gets calculated which would provide a tiny bit more defense. (is this what we mean by 'defense in depth?')

It wasn't really meant to do much, just if someone wanted to quickly copy and paste a token but didn't notice the r=1 at the end of the URL it would simply just redirect. The actual form itself generates a form token upon page load.

sneakyimp;11051845 wrote:

If I correctly understand the OWASP recommendations, as poorly written as they are, they propose using the security questions at this point rather than just letting some email recipient (or thief) reset the password.

From everything I have read security questions are usually not effective and are usually hated by users.

sneakyimp;11051845 wrote:

Let's admit it: no system is 100% secure 😉
As for 'hashing' the token, refer to my nonce suggestion above. First time I saw the use of a nonce was in the Authorize.net payment gateway. The API required with each POST that requested payment a digest/hash/nonce which was calculated from some values, I forget what they are. For better security, I would imagine it should be something that hashes together the password-reset-token and something that does not exist in the email which a hacker could not easily guess. Basically, when some dude shows up on the password reset page trying to reset a password, you hash the token with something in your db that wasn't in the email (a user id? perhaps some random salt or chars you stored in your db?). Note that the token's hash would need to calculate identically between the time it is requested from the user and the time they return to your site. You might consider storing the server-side secret chars in your password-reset-token-table (see my suggestion above).

Indeed, nothing is 100% secure!

I recently watched a video on this very topic and the person stored the token and a hashed version of the token in the database. I guess to obscure the token, but the token itself is just a random string, so I am not so sure what it accomplishes. In any case my process doesn't involve it. When I have a chance I'll link the video.

sneakyimp;11051845 wrote:

From what I see the token is not obscured -- at least it's not if you have the email. It would be right there in plain sight.

No, but it would be obscured if it was hashed.

sneakyimp;11051845 wrote:

In my case, the random service might allow the purchase of quite expensive--although not exactly fungible--merchandise. For most of my projects, the password reset without security questions would be entirely adequate.

Unauthorized purchases are usually handled pretty well by banks and credit card issuers. Also online transactions should always require the CVV code of the card which should never be stored, so unless the malicious person has the physical card, a transaction should not be possible. Furthermore, if the person has somehow managed to obtain the card, why even bother trying to intercept some password reset on a website? Just go on Amazon or eBay and start buying stuff!

sneakyimp;11051845 wrote:

I certainly concur it's a can of worms but would point out a few things:
Security questions are an additional layer of protection for password reset sequence. They are not used instead of but rather in addition to the email reset loop as an added precaution.
The OWASP article has some decent thoughts on what good questions are, and it discourages letting users define their own secret questions.
* I was assuming I would check answers case-insensitively. Remember that this is just a tiny added layer of security between the password reset email and actually resetting the password.

I know they're used in addition to but they're generally considered ineffective (from what I have read). I went to the link but it had very limited information and the full list was behind a pay wall :rolleyes: Their list of "good" questions I would consider to be pretty easy to obtain.

Case insensitivity is just one angle though. What about punctuation? My favourite teacher might me Mr. Smith, but maybe I entered mr smith. Or my mother's maiden name (perhaps one of the worst questions ever) was O'Connor, but I entered Oconnor, etc. Generally speaking, and in an ideal situation, these questions would never be used. It's only when a user goes back to a website or service that they have not used in a very long time do they get used (since they have obviously forgot their password). Now the person is trying to remember exactly what they entered way back when they registered.

sneakyimp;11051845 wrote:

Some other things about the OWASP recs:

OWASP's recommendations definitely seem to be overly complex and try to cover every single possible situation that could possibly be possible. Possible. Possible. Possible. :p

This doesn't mean they're not good, but I think for most use-cases they may be overkill and not necessary (and as you mentioned, they add quite a bit of complexity). In any case, they're definitely overkill for anything I have done or plan on doing. I think they're a good reference for some best practices and the general process.

[Weedpacket]

I take the OWASP recommendations as more SHOULD rather than MUST: describing the ideal (how many people starting from scratch would consider implementing an audit log?) but you can leave things off if you can make a good case for saying why they're not necessary in your situation (like you really aren't going to consider monitoring for automated cracking attempts or signs that an account holder is being victimised).

[sneakyimp]

Weedpacket;11051893 wrote:

I take the OWASP recommendations as more SHOULD rather than MUST: describing the ideal (how many people starting from scratch would consider implementing an audit log?) but you can leave things off if you can make a good case for saying why they're not necessary in your situation (like you really aren't going to consider monitoring for automated cracking attempts or signs that an account holder is being victimised).

Agreed, and I'm pretty good at rationalizing my laziness in the face of onerous-but-wise security practices.

Any suggestions about generating a token? Obviously the token should be impossible to guess (or effectively impossible before it expires anyway) and would ideally be something you can just append to the end of a url without any additional transformation like url encoding or db quoting or anything. There's also the issue of whether the server has the function [man]openssl_random_pseudo_bytes[/man] or some other random byte generator defined. And how about a little math analysis?

I'm tempted to use something like this:

// generate a string token
$token = bin2hex(openssl_random_pseudo_bytes(16)); 

If I'm not mistaken, $token would always be a string 32 characters in length and the number number of possible values would be about 3.4 x 10³⁸. Can someone verify this? Seems to me that would be very difficult to guess or crack. Thoughts?

I'm tempted to use [man]base64_encode[/man] instead of [man]bin2hex[/man] because the encoded strings would be shorter. This would result in shorter urls and more compact db storage, but some of the chars used in base64 will get transformed when part of a url.

And then there's the issue of what to do if [man]openssl_random_pseudo_bytes[/man] is not defined on the server. I'm wondering if it's OK to do something like this:

function get_token() {
	if (function_exists("openssl_random_pseudo_bytes")){
		$token = bin2hex(openssl_random_pseudo_bytes(16));
	} else {
		$random_bytes = "";
		for($i=0; $i< 16; $i++) {
			$random_bytes .= pack("c", mt_rand(0, 255));
		}
		$token = bin2hex($random_bytes);
	}
	return $token;
}

The docs for [man]mt_rand[/man] indicate pretty clearly that the bytes returned are not cryptographically secure. Thoughts?

[Derokorian]

sneakyimp;11051961 wrote:

Agreed, and I'm pretty good at rationalizing my laziness in the face of onerous-but-wise security practices.

Any suggestions about generating a token? Obviously the token should be impossible to guess (or effectively impossible before it expires anyway) and would ideally be something you can just append to the end of a url without any additional transformation like url encoding or db quoting or anything. There's also the issue of whether the server has the function [man]openssl_random_pseudo_bytes[/man] or some other random byte generator defined. And how about a little math analysis?

https://github.com/ircmaxell/random_compat

which is the 5.x version of http://php.net/manual/en/function.random-int.php

[sneakyimp]

Derokorian;11051965 wrote:

https://github.com/ircmaxell/random_compat

which is the 5.x version of http://php.net/manual/en/function.random-int.php

Thanks for that link. Looks like a PECL extension. Interestingly, a search of Ubuntu php packages that mention openssl (or openssl packages that mention php) yielded absolutely nothing. However, all the machines I'm currently dealing with (workstation, dev, production) all seem to have the openssl functions available.

I'm also wondering how to proceed session-wise if a user shows up at my password reset page with a valid password reset token that has not expired. This would be the token I emailed to them. Once they click on the link and come back to my site and once I've checked the token and am sure it has not expired, I need to :
allow them to reset their password if I'm being lax about security
prompt them with a series of security questions if I'm being serious about security
* possibly track other details to prevent brute force attacks and such.

I'm sort of wondering how to manage what might be a multi-form password reset process. I'm thinking I need take the token on the password-reset landing page and store it in session until the user has completed some series of identity validation steps and possibly reset their password. Each page in the identity validation phase (which could be a few forms they have to deal with) must take care to also check the token or bounce the user. I'm thinking I should hang on to the token until the user actually manages to reset their password.

Any thoughts/tips/suggestions on this token/password reset workflow?

[Derokorian]

Um... Look in the lib folder, there is a random.php the PECL extension simply provides the class that is defined in that file.

As for propagating the token... I would leave it in session, but I also use a CSRF token to prevent a form being submitted twice, or someone intercepting a request from a user and changing the POST data to a new password (for example) and resending the request.

[sneakyimp]

Derokorian;11051969 wrote:

Um... Look in the lib folder, there is a random.php the PECL extension simply provides the class that is defined in that file.

Hmmm. Sorry I didn't look at that more carefully. I've looked at the code and it would seem that the class tries a few different approaches but it's only marginally better than the function I wrote. I.e., it tries mcrypt and openssl first and then falls back on some linux-only options (/dev/random, /dev/urandom, /dev/arandom) before finally resorting to mt_rand (which is not cryptographically secure). Also -- and I haven't really examined this thoroughly -- the token() function constrains one's token to a particular alphabet. If I'm not mistaken, this would provide a random value that needs no url-encoding but might also reduce considerably the range of possibilities for one's random token.

Derokorian;11051969 wrote:

As for propagating the token... I would leave it in session, but I also use a CSRF token to prevent a form being submitted twice, or someone intercepting a request from a user and changing the POST data to a new password (for example) and resending the request.

Thanks so much for this detail. I must admit I've not been paying sufficient attention to CSRF threats and have not yet had 'the awakening' on how to prevent these. I understand the risk clearly: some bad guy knows how to formulate a url he can send to an authorized user that will perform some malicious operation. It is the prevention which I hope to understand.

It sounds like the prevention technique you are using is "synchronizer token pattern." If I understand correctly, your system will generate some token on the server side and store it in session. Any important request that results in some action on the server (e.g., "delete user" or "set user permissions") then the request must also send some_token along with the data one would typically submit with the form. The script that handles the form will take some_token for any incoming request and check to make sure it matches the some_token stored in session. What confuses me a bit is when you say "prevent a form from being submitted twice." Sounds to me like you are generating a new some_token every time you display a form and checking all form submissions to make sure the correct token is supplied. The article says this can cause substantial complications for AJAX sites because if the token is always changing and you have AJAX events firing off then it's hard to keep your tokens straight.

Could you elaborate on your anti-CSRF techniques in the context of a multi-page password reset scheme? Page zero for me seems pretty clear. This is a controller method I have:

	public function password_reset($token) {
		// make sure the token received has the correct format (32-char hexadecimal string in my case)
		if (!$this->_validate_password_reset_token($token)) {
			show_error("Invalid password reset token.", 400);
		}

	// this queries the database and returns an array of matching records or NULL if no matching record found
	$token_records = DB_password_reset_token::fetch_where($this->db, array(
		DB_password_reset_token::COL_TOKEN => $token
	));
	// make sure we have at least one
	if (!is_array($token_records) || (count($token_records) < 1)) {
		show_error("Token not found", 400);
	}

	// check expiration datetime of token against current time
	$token_record = $token_records[0]; 
	$expiration_unix_stamp = strtotime($token_record->expiration_datetime);
	if ($expiration_unix_stamp < time()) {
		show_error("Password reset token expired", 403);
	}

	// valid token found in the db, not expired...this token is legit
	// Set CSRF token? WHAT TO DO?
	// show new password form if i'm being easy or redirect user to first page of N-page password reset gauntlet

} // password_reset()

[Derokorian]

sneakyimp;11051993 wrote:

Hmmm. Sorry I didn't look at that more carefully. I've looked at the code and it would seem that the class tries a few different approaches but it's only marginally better than the function I wrote. I.e., it tries mcrypt and openssl first and then falls back on some linux-only options (/dev/random, /dev/urandom, /dev/arandom) before finally resorting to mt_rand (which is not cryptographically secure). Also -- and I haven't really examined this thoroughly -- the token() function constrains one's token to a particular alphabet. If I'm not mistaken, this would provide a random value that needs no url-encoding but might also reduce considerably the range of possibilities for one's random token.

I'm not sure about the token part, I guess I don't see what you're concern here is. The problem at hand has little to do with the number of possibilities and more to do with the predictability of the output.

As for using mt_rand it only does that in genNormal() function, however if you set it to secure, it uses genSecure which will throw an exception if the secure options are not available.

sneakyimp;11051993 wrote:

It sounds like the prevention technique you are using is "synchronizer token pattern." If I understand correctly, your system will generate some token on the server side and store it in session. Any important request that results in some action on the server (e.g., "delete user" or "set user permissions") then the request must also send some_token along with the data one would typically submit with the form. The script that handles the form will take some_token for any incoming request and check to make sure it matches the some_token stored in session. What confuses me a bit is when you say "prevent a form from being submitted twice." Sounds to me like you are generating a new some_token every time you display a form and checking all form submissions to make sure the correct token is supplied. The article says this can cause substantial complications for AJAX sites because if the token is always changing and you have AJAX events firing off then it's hard to keep your tokens straight.

Without giving too much detail away, the token submitted with the form is an encrypted formatted string containing additional data that I can use to validate incoming requests (think something along the lines of base64_encode(implode(':', [$form_id,time(),$token]))😉. The tokens are generated for a specific form, when the view for that form is requested (whether through the normal templating engine for an entire page load, or through an api request when changing state on a SPA). When my SPA loads a view that's already been retrieved, it has a hook implemented that makes a request for just the token. This way, every time a form is loaded it gets a new token, whether or not the previous token has been used (also tokens expire). Then when a form is submitted, I can validate the request came from where I expected, the token hasn't been used already, the token is for this form, and that it wasn't issued more than <configurable time> ago.

sneakyimp;11051993 wrote:

Could you elaborate on your anti-CSRF techniques in the context of a multi-page password reset scheme? Page zero for me seems pretty clear. This is a controller method I have:

	public function password_reset($token) {
		// make sure the token received has the correct format (32-char hexadecimal string in my case)
		if (!$this->_validate_password_reset_token($token)) {
			show_error("Invalid password reset token.", 400);
		}

	// this queries the database and returns an array of matching records or NULL if no matching record found
	$token_records = DB_password_reset_token::fetch_where($this->db, array(
		DB_password_reset_token::COL_TOKEN => $token
	));
	// make sure we have at least one
	if (!is_array($token_records) || (count($token_records) < 1)) {
		show_error("Token not found", 400);
	}

	// check expiration datetime of token against current time
	$token_record = $token_records[0]; 
	$expiration_unix_stamp = strtotime($token_record->expiration_datetime);
	if ($expiration_unix_stamp < time()) {
		show_error("Password reset token expired", 403);
	}

	// valid token found in the db, not expired...this token is legit
	// Set CSRF token? WHAT TO DO?
	// show new password form if i'm being easy or redirect user to first page of N-page password reset gauntlet

} // password_reset()

Ewww preceding underscores makes me sad. I do question what if more than one row was returned? That seems equally problematic as no rows to me.

That aside I'm not sure what you're asking for - maybe the explanation of CSRF above helps?

[sneakyimp]

Derokorian;11051995 wrote:

I'm not sure about the token part, I guess I don't see what you're concern here is.

Don't sweat my token-angst. It's just me being pedantic/OCD about cryptographic security because I find it more interesting than actually implementing reasonably effective solutions.

Derokorian;11051995 wrote:

Without giving too much detail away, the token submitted with the form is an encrypted formatted string containing additional data that I can use to validate incoming requests...

Thanks for your detail here. Your approach sounds a bit like I was describing before with a cryptographic nonce. I.e., the hashes you calculate are nonces. It seems to involve a random key (stored in session perhaps) hashed with some of the information being submitted in the form which could limit the use of the nonce in terms of time and user id. I'm ruminating on your token approach. It works sort of like this:
some kind of random_string is generated which doesn't have to be regenerated with each page request because we can hash it up with other data depending on where we use it
when we show a form, we include a hidden input with some hash of the random string. we might hash it with a form_id, the time, perhaps a userid, etc. this hashing serves two purposes: 1) conceals the random_string we are currently using and 2) binds a particular hash value to some form_id and possibly the time and possibly other values, which greatly reduces the lifespan and/or range of utility of the hash -- this effectively reduces the likelihood of abuse because a given hash is only good in a very limited range of circumstances.
* when the form gets submitted, it will include the hash we have generated and the form-handling script can take the random_string from session and, using information submitted with the form, it can recalculate the hash and check if the hash submitted with the form is correct. This form-handler can also check the time of the form submission and, if it's too old, can reject the form submission.

If I understand correctly, the power of this approach is that it makes it extremely difficult for an attacker to forge a correct form submission because s/he would need to know the secret random_string stored on the server and also know the algorithms for generating the hashes in order to formulate any valid form submission. It's like a secret handshake your server makes with itself.

Derokorian;11051995 wrote:

Ewww preceding underscores makes me sad. I do question what if more than one row was returned? That seems equally problematic as no rows to me.

I like the starting underscores to distinguish private properties/methods from public ones. This can be very handy when writing a toString function: don't output any properties preceded by an underscore. It's also helpful as a coding convention in that it clearly indicates restricted access for the prop/method.

Good point I suppose about the multiple tokens. I'm still wrestling with the question of when do I delete the password reset tokens stored in my db table? If I'm not mistaken, I need this password_reset_token record to stick around long enough that it can properly authenticate/validate a legitimate user request to reset a password. I need it for at least two page requests:
1) need to check for the token's existence before displaying the "please enter your new password" form
2) need to check for the token's existence when handling the form submission once the user enters this new password

Note that in practice it's extremely unlikely that two tokens will ever exist for a given user, much less for a given token. The function that generates these records first takes care to delete any other tokens belonging to particular user_id and then generates a token using 16 random bytes (3.4 x 10³⁸ possibilities). I suppose if something was broken, though, there might be some risk. E.g., what if my db table somehow got populated with null values or something? I could possibly delete all password reset tokens matchnig some token if we find more than one record that matches.

Derokorian;11051995 wrote:

That aside I'm not sure what you're asking for - maybe the explanation of CSRF above helps?

Your explanation does help, although I'm still not sure of a few things:
at what point do I generate this random_string on the server that is the basis for all my CSRF tokens/hashes? What I lack is experience using this technique. Right now, I only understand that frequent regeneration isn't much of a problem when using just HTML but can introduce problems when using AJAX. Sounds like your AJAX scripts feature a server call that can ask for a new random_string to be generated? I'm not really sure.
I have these password reset tokens stored in my database table, password_reset_token. Still no idea how long to keep these records or what sort of session information to maintain if a user is in some sequence of N pages involved in resetting a password. I'm leaning toward keeping the password reset token for all N page requests and validating it with each page request (i.e., fetching the record with the matching token, checking expiration datetime, etc). I would only destroy the password reset token record when the user finally enters their new password OR I might garbage collect expired password reset tokens via cron job or at random.

I think I'm in command of the fundamental logic of CSRF and this password reset process, but I'm trying to make sure it's secure and hoping to avoid any pitfalls that might arise when putting it into practice.

[Derokorian]

sneakyimp;11051999 wrote:

Good point I suppose about the multiple tokens. I'm still wrestling with the question of when do I delete the password reset tokens stored in my db table? If I'm not mistaken, I need this password_reset_token record to stick around long enough that it can properly authenticate/validate a legitimate user request to reset a password. I need it for at least two page requests:
1) need to check for the token's existence before displaying the "please enter your new password" form
2) need to check for the token's existence when handling the form submission once the user enters this new password

Note that in practice it's extremely unlikely that two tokens will ever exist for a given user, much less for a given token. The function that generates these records first takes care to delete any other tokens belonging to particular user_id and then generates a token using 16 random bytes (3.4 x 10³⁸ possibilities). I suppose if something was broken, though, there might be some risk. E.g., what if my db table somehow got populated with null values or something? I could possibly delete all password reset tokens matchnig some token if we find more than one record that matches.

Well, for my system I specifically allow multiple tokens to exist. This is because some people don't see the email instantly, and request a second reset, then receiving the first email click that link. I would certainly not want that link to not work because they requested a reset twice (unless the second request was after the first expired... but email should arrive before then LOL)

sneakyimp;11051999 wrote:

at what point do I generate this random_string on the server that is the basis for all my CSRF tokens/hashes? What I lack is experience using this technique. Right now, I only understand that frequent regeneration isn't much of a problem when using just HTML but can introduce problems when using AJAX. Sounds like your AJAX scripts feature a server call that can ask for a new random_string to be generated? I'm not really sure.

Well I generate a new nonce as you called it for every single CSRF. This is how it works:

CSRF.php

class CSRF
{
    public static function getToken($form_id, $user_id = null)
    {
        $data = [$form_id];
        is_null($user_id) ?: $data[] = $user_id;
        $data[] = (new Random(true))->token(6);
        $csrf = convert_uuencode(implode(static::SEPARATOR, $data));
        $_SESSION[$csrf] = $data;
        return $csrf;
    }

public static function checkToken($token, $form_id, $user_id = null)
{
    $data = explode(static::SEPARATOR, convert_uudecode($token));
    $sess_data = isset($_SESSION[$token]) ? $_SESSION['token'] : [];
    unset($_SESSION['token']);
    return $data == $sess_data &&
           $data[0] == $form_id &&
           (is_null($user_id) || $data[1] == $user_id) &&
           (time() - Config::GetValue('security','csrf_expiration')) <= $data[is_null($user_id) ? 1 : 2];
} 
}

SomeForm.tpl

<input type="hidden" name="CSRF" value="{CSRF::getToken(SomeForm)}" />

SomeFormController.php

public function submit()
{
    if (!isset($_POST['CSRF']) || !CSRF::checkToken($_POST['CSRF'], 'SomeForm')) {
        return ErrorController::BadRequest();
    }
    // continue processing
}

[Bonesnap]

sneakyimp;11051961 wrote:

Any suggestions about generating a token? Obviously the token should be impossible to guess (or effectively impossible before it expires anyway) and would ideally be something you can just append to the end of a url without any additional transformation like url encoding or db quoting or anything. There's also the issue of whether the server has the function [man]openssl_random_pseudo_bytes[/man] or some other random byte generator defined. And how about a little math analysis?

I'm tempted to use something like this:

// generate a string token
$token = bin2hex(openssl_random_pseudo_bytes(16)); 

If I'm not mistaken, $token would always be a string 32 characters in length and the number number of possible values would be about 3.4 x 10³⁸. Can someone verify this? Seems to me that would be very difficult to guess or crack. Thoughts?

I'm tempted to use [man]base64_encode[/man] instead of [man]bin2hex[/man] because the encoded strings would be shorter. This would result in shorter urls and more compact db storage, but some of the chars used in base64 will get transformed when part of a url.

And then there's the issue of what to do if [man]openssl_random_pseudo_bytes[/man] is not defined on the server. I'm wondering if it's OK to do something like this:

The docs for [man]mt_rand[/man] indicate pretty clearly that the bytes returned are not cryptographically secure. Thoughts?

I'm doing this pretty much exactly. Using openssl_random_pseudo_bytes to generate a token then using base64_encode on it. I have seen bin2hex() used as well. A quick thought: I haven't had any issues using the base64_encoded string in URLs, but I might switch to using bin2hex in case I have just been getting lucky.

As for if the server doesn't have openssl_random_pseudo_bytes defined, I think that's mitigated by the fact that you're in control of it, no? Installing it should be relatively easy. It's default in the Windows version of PHP, so I can only imagine that Linux installations would have it as well. Also in my case, I use it for generating form tokens so if it doesn't exist then the site doesn't work correctly and I move on to somewhere else. But we have control over the environment so it shouldn't be much of an issue.

[laserlight]

Have you considered using, or allowing the use of, a third party TOTP implementation, e.g., Google Authenticator or Authy?

EDIT:
To elaborate, perhaps this could form the challenge required at the password reset page, i.e., you might still generate a token to check that the user had access to the password reset email, but instead of answering security questions on the password reset page, the user supplies another token using the third party service.

Alternatively, this could replace your own token system entirely, but just allowing the user to set a new password if the correct username/email address and TOTP token is supplied would mean that the password becomes useless: you might as well just use TOTP tokens as the password. You could check that the user owns the email account on record by sending a generated password to that email address, but that has its own disadvantages, e.g., inconvenient, and email is almost certainly an insecure channel.

[sneakyimp]

Bonesnap;11052021 wrote:

I'm doing this pretty much exactly. Using openssl_random_pseudo_bytes to generate a token then using base64_encode on it. I have seen bin2hex() used as well. A quick thought: I haven't had any issues using the base64_encoded string in URLs, but I might switch to using bin2hex in case I have just been getting lucky.

The bin2hex is about 30% longer string length, but hexadecimal doesn't change one whit if you urlencode it. base64 has a few chars that get altered. Modern browsers seem pretty smart about handling spaces and equal signs and stuff but urlencoding issues can be a real pain in the ass. They usually sneak up on you when some user complains "the AJAX doesn't work" or whatever. Or sometimes urlencoding gets repeated and repeated so you get doubly-url-encoded strings so you have to figure out where the double encoding is, etc. I say go bin2hex.

Bonesnap;11052021 wrote:

As for if the server doesn't have openssl_random_pseudo_bytes defined, I think that's mitigated by the fact that you're in control of it, no? Installing it should be relatively easy. It's default in the Windows version of PHP, so I can only imagine that Linux installations would have it as well. Also in my case, I use it for generating form tokens so if it doesn't exist then the site doesn't work correctly and I move on to somewhere else. But we have control over the environment so it shouldn't be much of an issue.

Yeah it's available on all the servers I'm currently dealing with so I'm not going to sweat this too hard. It seems to be the default for CentOS and Ubuntu installs via DEB/RPM. If it were not, installing it might be a chore because, as I previously mentioned, there is no specific php/openssl package and compiling php from source would be required. It is my hope that the reason there's no package for php/openssl is because it is included by default with php so there's no need for a package.

At any rate, I'm not sweating it at the moment. I am a bit curious, though, how one might generate cryptographically secure random numbers in PHP if one could only use basic PHP language structures in one's code. Would this even be possible? I.e., if you didn't have mt_rand or any other function to generate a random number, would it be possible? I'm guessing you'd have to go to some system call or external file somewhere to have even the slightest chance.

[laserlight]

sneakyimp wrote:

I am a bit curious, though, how one might generate cryptographically secure random numbers in PHP if one could only use basic PHP language structures in one's code. Would this even be possible? I.e., if you didn't have mt_rand or any other function to generate a random number, would it be possible? I'm guessing you'd have to go to some system call or external file somewhere to have even the slightest chance.

You could err... implement a CSPRNG like Blum Blum Shub?

[sneakyimp]

laserlight;11052023 wrote:

Have you considered using, or allowing the use of, a third party TOTP implementation, e.g., Google Authenticator or Authy?

Thanks for the suggestion. This seems like the 'side chain' suggested by OWASP document which would be used in the event of security question failure. I'm not familiar with these. My client just asked if we can let users register/login via Facebook. I guess I'll be looking into some of this stuff here soon.

laserlight;11052023 wrote:

EDIT:
To elaborate, perhaps this could form the challenge required at the password reset page, i.e., you might still generate a token to check that the user had access to the password reset email, but instead of answering security questions on the password reset page, the user supplies another token using the third party service.

Thanks for elaboration. Will have to mull implications. As a personal aside, I am really starting to find Facebook/Google super-creepy. I bought a plane ticket directly from an airline's website and emailed it (via hotmail) to my wife's gmail account. Somehow my flights have ended up in her iPhone's calendar app. Uncanny valley type ****.

laserlight;11052023 wrote:

Alternatively, this could replace your own token system entirely, but just allowing the user to set a new password if the correct username/email address and TOTP token is supplied would mean that the password becomes useless: you might as well just use TOTP tokens as the password. You could check that the user owns the email account on record by sending a generated password to that email address, but that has its own disadvantages, e.g., inconvenient, and email is almost certainly an insecure channel.

Not being familiar with TOTP in practice, I'm not entirely sure what you are suggesting in this last paragraph. I may misunderstand, but I'm vaguely aware of a feeling of horror that you are suggesting we allow people to use their gmail account (or similar) as their key into our site.