Secure Active Directory Password Reset with FIM 2010 R2
While perusing Troy Hunt's article Everything you ever wanted to know about building a secure password reset feature, I thought it might be interesting to map Troy's notes on good processes against Forefront Identity Manager 2010 R2's SSPR flow, which allows users to reset their own Active Directory passwords from both the company intranet and from the Internet.
We're going to skip over concerns about password hashing and encryption for now, as FIM SSPR only works with Active Directory Domain Services, of which the password encryption and hashing options are a separate topic. Suffice it to say that existing passwords in AD:DS are normally hashed, not recoverable in plaintext, and not available in hashed format without attacking the domain controller at a fairly low level.
Starting with FIM 2010 R2, the self-service password site is just an ordinary web app, with none of the MSIE / ActiveX requirements of the past. Out of the box it follows the familiar pattern of asking for your username, displaying a set of security questions--an administrator configures the text for each question, as well as the total number of displayed and required questions--and if you get them right, you get to reset your account password. The entire flow looks like this:
;)
Step 1. Enter your username
The first step is to enter your username, either in "DOMAIN\username" or "user-principal-name@domain.local" format, or just "username" if a default domain is configured.
If the user ID doesn't exist, or even if the ID does exist but the user hasn't registered for SSPR, FIM does a reasonable job of minimizing information disclosure. Otherwise, if the user account is valid, and is enrolled for SSPR, we see a list of security questions.
;)
This is a little bit of a concern, as a third party may be able to use the initial SSPR page to discover valid logon IDs that are enrolled for SSPR, provided the organization uses logon IDs in the very typical "first.last" or "<first initial>last" and related formats, and also assuming the third party knows the Active Directory domain name (which they might not). It should go without saying that most IT/infosec organizations are not particularly eager to ask their users to remember an opaque logon ID, although in my own experience, these IDs are extremely easy to remember after a few days of regular use--I still remember opaque logon IDs from ten years ago, and even a Prodigy ID from a very, very long time ago.
Highly security-conscious organizations could configure the SSPR portal to require username entry in UPN format, with a validation to reject any other style, in conjunction with assigning values other than the implicit UPN.
Notably, it is not possible to attempt to use FIM SSPR with knowledge of only a person's email address, nor can one use FIM SSPR to test the validity of any email addresses. There's also a lockout mechanism that restricts each account to 3 unsuccessful SSPR attempts in 15 minutes (this is configurable).
Step 2. Answer security questions
There's really nothing new here: the FIM SSPR page presents some or all of the security questions you answered during enrollment. It's up to the FIM administrator to decide how many questions to offer, how many the user must answer, and then out of these, how many will be displayed and required during a reset; there's no capability for the user to type in custom questions like "What's the secret word taped to the bottom of my keyboard?"
The upshot is that your Windows password is only as strong as the difficulty of answering the reset questions correctly. Can one come up with questions that are memorable, unambiguous, stable, apply to practically everyone, and extremely difficult to research? Certainly some questions are better than others, but there's absolutely an argument to be made that it's impossible to present any set of security questitons that is as strong as a long, reasonably random password. For example:
| Question | Issues / Security |
|---|---|
| What was your childhood nickname? |
|
| What street did you live on in third grade? |
|
| What is your oldest cousin's first and last name? |
|
;)
My own practice is to answer questions like these with random gibberish, or sometimes with silliness: "Why yes, my first pet's name was 'Mister Bitey.'" In any event, the answer is outside the set of common responses, it's really not researchable, and right into STRIP it goes in case I need it later.
At this point, in a default FIM SSPR configuration, FIM will let you pick a new password. The new password will (optionally) be validated for compliance with the account's effective password complexity policy, and we're done. It's easy, but... it's not very secure, especially if the user has answered the security questions in a straightforward manner (that is to say, the user has not entered "Cthulhu M. Wiggington III" or "R7z_al4nep5" as his or her oldest cousin). But let's think about this--I mean, what's the point of demanding complex, 12-character passwords that must change monthly and not repeat any of 15 prior passwords, in Active Directory, if we've got these simple, non-complex, never-changing password reset questions kicking around--and on the Internet to boot?
Step 3. 2-Factor Authentication / One-Time Passwords
One of the excellent improvements in FIM 2010 R2 is that the self-service password reset process doesn't have to end with Step 2: we can plug in one of two additional One-Time Password, or OTP, authentication gates. The choices are the One-Time Password Email Gate, which sends a confirmation code to the user's recovery email address, and the One-Time Password SMS Gate, which sends a text message to the user's mobile phone.
;)
The addition of the One-Time Password gates is critically important, especially in an Internet scenario, because it reduces the security questions to merely a precursor, or filter, to an additional check that improves process integrity. Both of the OTP gates send a message like "Enter code 205839 to reset your password," which code the user must re-enter in the FIM SSPR dialog to proceed on to choosing a new password. Fundamentally this is a good approach, as the user has only one try per SSPR session to enter the right temporary PIN, and we haven't sent a new password, or anything else extremely sensitive, over insecure public networks. (See the video linked farther down this page for a view of one-time passwords in action.)
Email One-Time Passwords
I'll talk about the Email OTP gate first: To cut to the chase, it isn't a very secure option. Since we're working with Active Directory here, the user has almost certainly enrolled for SSPR with some third-party email provider like Hotmail / Live, Gmail, AOL, etc.--they can't very well reset a lost or locked-out Active Directory account by logging in to a mail system that uses that same Active Directory for authentication. The problem is that the security of the external webmail account is totally outside IT's control--it's not auditable, the user may have a very weak password, share the same password across multiple other websites, or the webmail provider might have an insecure password recovery process with questions an attacker already researched to attempt to get through FIM SSPR.
Emailing a PIN adds another step, but it really does not add another factor to authentication, because we are still in the realm of "something you know," and this is all stuff a determined attacker could know. However, it is slightly better than emailing a "password reset URL," as the PIN is only useful within the time-limited context of one session with the FIM SSPR website.
Mobile Phone / SMS OTP
The SMS OTP gate works much the same way: after answering the security questions, the system sends a SMS to your mobile number, e.g., "Your password reset PIN is 582048." Type in the PIN to FIM's waiting prompt, and you're ready to choose a new password. This may seem like a small step from the Email OTP, but it's really a very large difference as a legitimate second authentication factor that requires, in addition to "something you know," the "something you have"--possession of the mobile phone. While it might be practical for a determined attacker halfway around the world to research security questions and even to break into a webmail account, the effort and expense would be several orders of magnitude higher to discover the user's mobile number and actually intercept its traffic without alerting the user. (If you're facing attackers with the resources to spend on this kind of effort, it's probably high time to do away with passwords entirely and move on to certificates and smartcards exclusively.)
While FIM 2010 R2 provides the basic framework to enable the SMS One-Time Password, it does not include any implementation or SMS gateway interface. We'd like to encourage organizations interested in SMS authentication for FIM Self-Service Password Reset to check out Zetetic's SMS Provider for FIM, which includes a plugin for the FIM Service and integrated SMS services.
Here's a video of the entire FIM password reset process including SMS PIN.
Summary
Overall, with the addition of the SMS One-Time Password facility, FIM 2010 R2 Self-Service Password Reset gets a lot of stuff right:
- Limited information disclosure
- Lockout interval discourages brute-force guessing
- Flexible security question enrollment allows for good diversity
- Users securely enter a new password, rather than receiving a system-generated one
- Security questions provide a reasonable barrier against spamming users with SMS PINs
- Extensible after the password is reset (e.g., could send the user an email to confirm)
- Time-limited opportunity to complete the reset activity
- SMS PIN provides 2FA
As for areas for improvement, we might like to see the addition of a CAPTCHA or some other mechanism to dissuade using the initial SSPR page to probe for valid logon IDs. This would not be an issue for organizations that decide to not to deploy FIM SSPR on the Intranet, or for those who might guard frontend web access with whitelisted IP ranges or with an intrusion detection system to throttle or eliminate malicious use.
blog comments powered by Disqus