STRIP for OS X has been updated, version 1.2.6 was released last week, and since then we've been catching up on some support mail. It features a few minor convenience improvements, based on our customers' feedback and suggestions:
- Verify that Dropbox folder selection is the Dropbox path and not Dropbox/Zetetic
- Preferences window now has a Reset button for the backups directory path
- Preferences now has a switch for disabling creation of a backup on every sync
- Dropbox folder selection now displayed in Preferences along with chooser button
Known Issues:
Upgrading from Strip Sync
There does seem to have been a bug introduced by our adoption of sandboxing a few months back for the Mac App Store as required by Apple. On first-time setup, Strip for OS X checks for the old Strip Sync database and offers to migrate your data—currently this check occurs inside of the Sanbox, so the old data is never detected. There are several ways to work around this, the easiest being an Overwrite from Strip for iOS, but we advise any new users to get in touch with us.
Double windows on setup
On OS X Lion and OS X Mountain Lion, the system takes note of any windows open when you close an app and attempts to automatically restore them. When you start up Strip for OS X the first-time, and quit without setting the program up, and you relaunch the app later, you'll see two windows appear, a setup window and login window. You'll want to quit the plain login window and proceed with the setup window. We should have a fix for this out as soon as we can get it reviewed by Apple (note: version 1.2.6 had to wait 30 days before going into review, so it can be a bit). If you are experience this problem or related issues, please contact us.
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? |
- Limited number of likely values
- Often based on individual's name
- Researchable (especially by childhood friends)
- Not everyone has a nickname
|
| What street did you live on in third grade? |
- Very small number of likely values
- Researchable
- Guessable (by anyone with Google Maps and some time)
|
| What is your oldest cousin's first and last name? |
- Researchable; having a cousin is not a secret
- Not everyone has a cousin
|
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.
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.
;)
;)
;)
;)
;)
;)
;)
;)
;)
;)
;)