Forgot/reset password process in 2.1.10 remains insecure and increasing the number of security questions isn't good enough

[gene1wood]

A significant vulnerability in the authentication system of BCOE&M was reported in #740

@geoffhumphrey and I emailed when it was reported and came up with what sounded like a good solution to the problem which involved

• For installations of BCOE&M that have php's email() functionality enabled, modify the BCOE&M code to email a user's new password to them instead of displaying it to them on the website
• For installations of BCOE&M that don't have php's email() functionality enabled, display a message to users trying to reset their password that they need to contact that administrator to do a password reset

I indicated "I think this would be a good interim tradeoff as it protects the installations and the users and introduces pain for folks hosting it on systems that can't send email. I think that would be a good security/convenience trade off."

He agreed that he'd put the change in for "the next release. Based upon the current codebase, it will be a pretty easy fix."

A few weeks back @geoffhumphrey indicated that instead the release would have "22 newer and "stronger" questions".

Increasing the number of security questions does little to mitigate this risk as it doesn't prevent users from choosing weaker security questions with brute forceable answers. In any normal website, having a weak security question (e.g. What is your high school mascot?) is not a big deal because the attacker must gain control of the victims email account in addition to guessing the answer to their security question. The security vulnerability originally reported in #740 however calls out that BCOE&M works fundamentally differently and does not enjoy this added protection.

Please complete and release either version 2.1.10 or a security point release in advance of 2.1.10 in the next 30 days (before August 17, 2017) with the proposed change of emailing users their newly reset password (in addition to or instead of an increased number of security questions) so that it's no longer possible for a users new password to be displayed on the site. If this doesn't happen I have an obligation in the interest of responsible disclosure to publish this vulnerability in order to protect the users of BCOE&M.

[geoffhumphrey]

The pre-release does not have the email option, but the full release, planned for later this month, will. I've reopened #740 - it was mistakenly closed.

The coding will attempt to email the reset password. If the server that hosts the installation does not support php mail(), the email will not be sent. However, messaging will say something to the effect of "A new password has been generated and emailed to the address you have on file. If you do not receive an email with your new password, contact a competition official."

The password will not be displayed on screen at any point.

Again, in the future, a token system is planned to be put into place.

Edit: version 2.1.10 will utilize a token system for password reset. Additionally, password strength will be checked using Dropbox's zxcvbn password strength estimator in conjunction with the jQuery Password Strength Meter for Twitter Bootstrap plugin.

[geoffhumphrey]

As it stands now in the latest commit, here's the process users will go through to reset a forgotten password.

1. Click on the reset password link from any login screen or modal.

2. Enter the account's email address (user name).

3. Provide an answer to the security question associated with the account.

4. If the answer is correct, a token will be generated and inserted into the associated account's record in the users database table. Tokens will only be valid for 24 hours. An email is also generated and sent to the email address on file. Messaging will instruct users to contact an official if they do not receive the email with the token URL.

5. If the server allows php's mail() function, the user will receive an email with a token URL.

6. The user clicks or copy/pastes the URL in the email. The resulting page requires entry of the email address associated with the account and entry/confirmation of the new password. Note the password strength indicator.

7a, If the email/token pair do not match what is in the database it results in an error.

7b. If the token has expired or has already been used, a message will say so.

8. If the password change is successful, a message is displayed and the user is able to log into their account with the new password. The token is removed from the user's record in the DB.

9. Everyone is happy.

[gene1wood]

Looks great!

One note, if in step 3 you give the user the option to say that they've forgotten their security question's answer and would like to have it emailed to them, this makes the security questions in this new flow no longer provide any increased security.

In a traditional password reset flow (like what you're describing with tokens), the purpose of the security question is to both prevent an attacker from spamming a users email account with password reset emails and to add a layer of security in the case where the attacker has gained access to the users email account.

By offering to email the user's security question answer to them, it bypasses the two benefits of a security question. As such, I'd recommend either removing security questions entirely and using the token solution alone, or remove the option to have the security question's answer emailed to the user.

[geoffhumphrey]

Excellent point. In the next commit and release, the option to email the security question response will be removed and messaging will indicate to the user that if they cannot remember their response they should contact a site admin. That should button things up.