IDM Best Practice: Self Service Password Reset

Self service password reset is an important capability for any scientific cyberinfrastructure (CI) providers that manage passwords for a large user community. Without it, providers risk being overwhelmed by support requests from users who forgot their password and risk being the victim of social engineering attacks against support staff following ad-hoc, manual password reset procedures.

We differentiate between password change and password reset. Password change is when the user enters both current and new passwords to update the password for an account. Password reset is when the user has forgotten the current password for the account and needs to establish a new password.

CI providers should avoid re-implementing the password reset workflow if possible. Using external identity providers (e.g., InCommon and/or Google) avoids the risks of managing passwords directly, enables users to log in via an account that they use regularly (so users are less likely to forget the password), benefits from available security features such as two factor authentication, and leverages the password recovery support of the external identity provider(s). Alternatively, CI providers could use an existing password reset workflow built-in to their web application framework (e.g., Joomla or Laravel) or identity management (IDM) platform.

However, in our experience CI providers still sometimes find the need to implement password reset in their unique environment. In this article, we provide an example email-based password reset workflow and discuss design choices and risks that CI providers should consider when implementing password reset. The workflow assumes that users have previously registered a contact email address that can be used for password resets.

Password Reset Workflow

The goal of the following workflow is to allow a registered user to reset their password without requiring assistance from support staff.

1. On the "Sign In" page, the user clicks the "Forgot Password?" link.
2. The user is prompted to enter their username or registered email address.
3. The user is prompted to "check your email for a password reset code to enter below".
4. The user enters the password reset code on the web form.
5. The user enters their newly chosen password.
6. The user can now sign in with the newly chosen password.

Behind the Scenes

To implement this workflow, the web application performs the following actions behind the scenes:

When the user enters a username or email address (step #2), the web application checks for a match with a valid user account. As with any input provided by the user, the web application sanitizes the username and email address values before querying back-end databases, to protect against injection attacks. In response to the user's submission, the web application does not indicate whether a match was found, to avoid disclosing the existence of registered accounts to unauthenticated users. Instead, whether a match was found or not, the web application displays, "Please check your email for a password reset code to enter below. If you do not receive an email message, please contact the help desk" (step #3). If the username or email address provided by the user does not match a valid account, no further action is taken.

If the web application finds a valid account matching the user's input, the next step is to generate the password reset code (for example, an 8 digit random number), store a salted hash of the reset code (for example, using bcrypt) with a timestamp and the user's account ID, and send the email message to the user's registered email address. The password reset code is a time-limited, one-time-use random "nonce" value to confirm that the user received the message at the registered email address. The web application removes stored reset code entries immediately after use or after the time limit (for example, 15 minutes) has elapsed.

Next, the user enters the password reset code from the email message on the web form (step #4). The web application hashes the entered reset code and searches for a match among the current stored values. If no match is found, the application displays an error and prompts the user to try again (for example, allowing up to 3 tries before aborting the process). If a match is found, the application prompts the user to enter a new password (twice for confirmation) (step #5) and checks that the new password is sufficiently strong. If it is, the application changes the user's password to the new value, removes the stored reset code entry, and sends a confirmation email to the user's registered email address. The user can now return to the standard "Sign In" page and proceed to log in with the new password (step #6).

Password Reset Email Messages

The above workflow sends two email messages to the user's registered email address: 1) the message containing the password reset code and 2) the message notifying the user that the password reset completed successfully. These messages should follow recommended practices for email communications, including a trustworthy From address (in the correct DNS domain) and no HTML content. The messages should also include instructions for contacting the help desk if the user did not initiate the password reset. The user's password should never be sent in email messages.

Logging and Monitoring

The password reset capability can be a target for attacks and a source of user support issues, so it is especially important to log all system activities related to password resets and monitor for unexpected behavior. Log messages should have accurate timestamps and should include the originating IP address for password reset requests.

Risks

The primary risk for the password reset process is the possibility that an attacker could reset a valid user's password and thereby obtain unauthorized access. Potential attack vectors include:

• Disclosure of reset code via email: Since the password reset code is sent over unsecured email, it could potentially be disclosed via email account compromise or network eavesdropping, allowing an attacker to use the code to change the user's password. Enforcing a short lifetime on the reset code limits the window of vulnerability against this attack.
• Network disclosure of passwords: The web application should follow HTTPS best practices to protect passwords against active and passive man-in-the-middle and phishing attacks.
• Exposure of reset code database: Storing reset codes in hashed (salted) form in the web application protects against disclosure of valid reset codes due to inadvertent disclosure of the reset code database.
• Brute force attacks on reset codes: Generating long, random reset codes, valid for only a short time, makes it infeasible for an attacker to successfully guess a reset code through brute force. Aborting the reset process after 3 failed reset code entries also protects against guessing attacks. However, beware making reset codes so long that they are inconvenient for users to input. (8 random digits is a reasonable length.)
• Compromise of the password reset front-end web application: In a system architecture with a back-end authentication system (LDAP, Kerberos, etc.) that may be shared across multiple front-end systems, enabling a front-end web application to reset passwords introduces the risk that an attacker who compromises the web application could reset many user passwords and gain further unauthorized access. Unlike password change (which requires knowledge of a current valid password prior to making password updates), password reset trusts the web application to update passwords without further validation by the back-end authentication system. Isolating the password reset functionality to a dedicated, well-secured front-end system can help to mitigate this risk, as well as logging and monitoring on the back-end system.

Examples

The "Forgot Password?" links on the XSEDE User Portal and on HUBzero provide illustrative examples of self service password reset functionality similar to what is described above.

Self Service and Exceptional Cases

If all goes well with the above workflow, the user is able to reset their password without assistance from help desk staff, hence "self service". However, the user may still need assistance if (for example) they lose access to a previously registered email address and therefore can not complete the self service workflow. It is important to have documented processes for handling these exceptional cases at the help desk without introducing new risks for social engineering attacks. A phone call from the help desk to a previously registered phone number can help re-establish account ownership. However, when in doubt as to the identity of the account holder, it may be better to ask the user to create a new account rather than risk improperly resetting the password on an existing account.

What do you think about self service password reset? Post your comments below.

For more about how CTSC helps NSF projects visit http://trustedci.org/howwehelp.

CTSC CyberCheckups

CyberCheckups are a new service that CTSC offers to NSF science and engineering projects. As a complement to CTSC's other activities, a CyberCheckup is a brief review by CTSC of a project's cybersecurity program. The review takes place over the course of a week, with materials delivered by the project to CTSC at the beginning of the week, CTSC staff having 2-3 days to review, a virtual (or physical if appropriate) meeting to discuss, and then a brief report written by CTSC that provides an overall cybersecurity program assessment with recommendations for improvements. A CyberCheckup can be a good method for identifying topics for a longer-term CTSC engagement.

In April, CTSC conducted a CyberCheckup for HUBzero. CTSC staff reviewed 6 HUBzero documents and produced a 2 page report for HUBzero staff within the one week CyberCheckup period. CTSC staff used a checklist of baseline controls and best practices to identify topics to cover during the CyberCheckup.

If you are interested in a CyberCheckup for your project, please contact us.

Seeking InCommon SPs that would benefit from more R&S particiation

The InCommon Research and Scholarship (R&S) category helps solve a key challenge with federated identity, in that all identity providers which participate automatically release attributes to service providers in the category. This greatly eases the normal process a service provider has to go through of working with individual identity providers to obtain such attribute release.

In order to try and increase participation in R&S,  I am building a list of InCommon service providers that would benefit from more IdPs participating in R&S.

If you are such an SP, please contact me.

Thank you,

Von Welch

Director, CTSC

Illicit Bitcoin Mining: Prevention, Detection, and Response

Bitcoin mining and NSF computational resources have been in the news lately with the NSF OIG report for March 2014 (p. 29-30) reporting on a user of NSF-funded supercomputers using them illicitly to mine for over $8,000 in bitcoins. A similar story emerged regarding a student at Harvard. Additionally, a report from Iowa State reports intruders using a computer illicitly for bitcoin mining. (For more details about bitcoin mining, see the NSF-funded research from UCSD.)

Assuming you have made the decision to disallow bitcoin mining, addressing unauthorized bitcoin mining is a multi-phase process.

Educating your users that bitcoin mining isn’t allowed is a good first step. Make sure you have a clear acceptable use policy (AUP) that states what computing systems can and cannot be used for. For example, the IceCube AUP states that their resources “are intended to provide computing resources for analysis, processing and filtering, and simulation activities for the IceCube project.” Another, stronger approach is to explicitly ban bitcoin and other crypto-currency mining (for example, see the Heroku AUP).

Second, your users may still misbehave, or you may have unauthorized users compromise your system, so consider implementing rules for an intrusion detection system to detect the mining. Since bitcoin mining requires network traffic, monitoring network traffic can be effective. For example, bro_bitcoin is a module for Bro to detect bitcoin mining on the network.

Finally, consider procedures for what happens if you detect bitcoin mining and successfully mined bitcoins. This is an emerging area and there are no standard practices yet. However, an incident response plan should support effective response to this case, including who should be notified and involved given the fungible nature of bitcoins.

(CVE-2014-0224) OpenSSL upgrade, urgent for certain circumstances

This morning a new OpenSSL advisory was announced: https://www.openssl.org/news/secadv_20140605.txt

After analysis, while there are no known exploits at this time, there seem to be some circumstances that lend themselves to such and CTSC urges those with the following circumstances to upgrade ASAP and everyone else to patch to the latest version of OpenSSL as soon as they can during normal business hours.

Circumstances dictating upgrade ASAP:

1. Deployments where both the server and client are using OpenSSL 1.0.1
2. Deployments using Datagram Transport Layer Security (DTLS)

Services that use SSL should be restarted after upgrading in order to load the new libraries.

Since web browsers in general don't use OpenSSL, the first case is most likely with other (e.g. command-line) applications. We expect the second case to be rare in the Grid community.

If your software is impacted, please let CTSC know so we can help communicate your fix.

Credits:

• XSEDE
• Globus: https://support.globus.org/entries/71973746
• Adam Langley: https://www.imperialviolet.org/2014/06/05/earlyccs.html
• ISC: https://isc.sans.edu/forums/diary/Critical+OpenSSL+Patch+Available+Patch+Now+/18211

TrueCrypt's Cryptic Disappearance

There's been a lot of speculation as to the reasons behind TrueCrypt's sudden deprecation by its development team. The main website was redirected to Sourceforge with a vague error message--"WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues"--and without the public mailing list discussion or other early warnings that normally accompany the deprecation of an open source development project.

Silence, however, isn't itself cause for panic. An ongoing audit of TrueCrypt hasn't found anything major, and there is plenty of active interest in evaluating TrueCrypt's current state in the hope of moving it forward. In other words, there's no sign of an existing security problem, and plenty of eyes are looking out for one.

The future of TrueCrypt is yet to be seen.

In the mean time, those wanting to create new TrueCrypt installations should be careful where they get their software. With the TrueCrypt site deprecated, there are plenty copies floating around that nobody's checked for malware or back doors. Ideally, users have the ability to verify a new copy of TrueCrypt by means of digital signature or comparing the checksum against that of a known-good copy.  However, absent that, one's safest bet for acquiring TrueCrypt is to use the git archive maintained by the good folks spearheading the ongoing audit linked earlier in this post: https://github.com/DrWhax/truecrypt-archive

Deprecation of open source software projects happens every day. Some get picked up and continued by others, some vanish over time. While the TrueCrypt team's lack of communication with its community may be frustrating, it doesn't change the code, which has not raised red flags. More context may come to light in the long term, but in the mean time even the most cautious among us can afford to take a deep breath.

Call for Participation - Be heard at the 2014 NSF Cybersecurity Summit!

The 2014 NSF Cybersecurity Summit for Large Facilities and Cyberinfrastructure will take place Tuesday, August 26th through Thursday, August 28th, at the Westin Arlington Gateway near National Science Foundation Headquarters in Arlington, VA. On August 26th, the Summit will offer a full day of information security training. On August 27 and the morning of August 28, the event will follow a workshop format designed to identify both the key cybersecurity challenges facing our community and the most effective responses to those challenges.

Please consider submitting a brief (1-5 page) white paper on unmet cybersecurity challenges, lessons learned, best practices, and/or significant successes. The program committee will select a limited number of these papers for presentation at the Summit. All papers will be included in the Summit report. We are also soliciting proposals to provide security training, and applications for student scholarships to attend.

The submission deadline is June 28 and submissions are welcome from any member of the community. Submit directly to Craig Jackson at scjackso@indiana.edu. For more details on the CFP, visit http://trustedci.org/cfp2014.

For more on the summit in general, see http://trustedci.org/2014summit/.

The Summit is limited attendance, please contact Craig Jackson or one of the other organizers if you are interested an invitation.

We hope to hear from you.

Craig

On Behalf of the Organizers, Jim Marsteller, Von Welch, and Craig Jackson