This Saturday night, September 15th at 10pm EDT, Tempo and other web systems will be temporarily unavailable while we perform critical patch updates to ensure the stability of our services.
This maintenance outage will also affect the Tempo API, the the Connect website, and the site for Codebook.
Down time could last up to 2 hours, however we hope it will be completed much more quickly. If you need to get in touch with us for any reason, please don’t hesitate.
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:
;)
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).
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?
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.)
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.
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.
Overall, with the addition of the SMS One-Time Password facility, FIM 2010 R2 Self-Service Password Reset gets a lot of stuff right:
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.
Dropbox has made security-conscious users very happy with the recent addition of two-factor authenitication using OATH-TOTP. We are now pleased to announce that the latest version of OneTime for Yubikey adds support for Dropbox, allowing Yubikey owners to use their USB devices for 2-step verification on Mac OS X.
Unlike mobile applications or SMS delivery, a Yubikey with OneTime is highly portable and doesn't require a smartphone, cell coverage, or SMS service. Nor does OneTime make you re-type passwords from your device into login fields on the computer.
Getting started with Dropbox 2-step, OneTime and a Yubikey is very easy. You'll need to install OneTime on your computer and launch the application. Then, login to your Dropbox account page, locate the two-step verification status, and click "change".
;)
Follow through the informational screens until you are prompted to choose a 2-step verification method. Choose to use a Mobile App instead of SMS.
;)
On the next screen, above the QR code, click the link to "enter your security code manually" to view the raw Base32 encoded key data.
;)
;)
Select the raw key and copy the value to the clipboard. Then click the OneTime for Yubikey Icon in the Mac Taskbar, then Preferences, and switch to the Personalization tab.
;)
Paste the secret key into the key field, choose the Yubikey slot to use (usually Slot 2), then "Write Config". Important Note: "Write Config" will irrevocably overwrite any existing configuration in the specified Yubikey slot. When shipped from the Yubico, slot 1 is programmed for the Yubico OTP services and slot 2 is empty, so it is usually the right default. However, if you already use slot 2 with a different service (i.e. GMail) you may want to buy a new Yubikey for Dropobox. Please be careful!
;)
Once the configuration is written to the Yubikey you can start using it immediately. On the next Dropbox screen you'll be asked to enter the current one time password. Just use OneTime's "Insert OTP" menu item, or your global hotkey (⇧⌘Y by default).
;)
Complete the setup process and write down your emergency backup code. Now you're ready to use your Yubikey for Dropbox access on any Mac with OneTime installed!
Learn More » or Buy OneTime Now »
P.S. existing OneTime for Yubikey users can contact us to request a free upgrade to the latest version.
We are proud to annouce that STRIP for Android, the secure password manager and data vault, is now available in the Google Play store!
STRIP has been protecting data on mobile devices since 1998, and we've continued to evolve the product over the years to run on iOS, Mac, Windows, and now Android. Like its peers, STRIP for Android has many advanced features and the best security available:
;)
STRIP for Android
Most importantly, STRIP for Android features complete data encryption, protecting your most valuable information with SQLCipher. An open source extension to SQLite, SQLCipher uses 256-bit AES to encrypt the entire application database. We began the process of porting SQLCipher to Android late last year in conjunction with The Guardian Project to ensure a stable and secure platform, before even starting work on STRIP for Android. SQLCipher has been independently reviewed by many security professionals; for instance Elcomsoft presented findings about STRIP at the BlackHatEU conference, concluding that the application backed by SQLCipher was the "the most resilient to password cracking".
If you are looking for a password and data manager on the Android platform that provides a high degree of security and user flexibility, check out STRIP for Android and let us know what you think.
This Thursday night, August 23rd at 9pm EDT, Tempo and other web systems will be temporarily unavailable while we perform critical patch updates to ensure the stability of our services.
This maintenance outage will also affect the Tempo API, the the Connect website, and the site for Codebook.
Down time could last up to 1 hour, however we hope it will be completed much more quickly. If you need to get in touch with us for any reason, please don’t hesitate.