Microsoft 2-factor authentication: following familiar paths (part I)

Last week Microsoft  released 2-factor authentication for its online accounts service, previously known as Windows Live ID and Passport. This was a natural step, as cloud service providers continue to shore up security by improving their  authentication systems, occasionally prompted by a security breach as  in the recent case of Twitter. It was even foreshadowed by earlier appearance of an associated mobile app on Windows Phone store. The design also appears to have few surprises, sharing much of its DNA with previous two-factor authentication systems used in the consumer space:

  • One-time passcodes (OTP) are the second factor of authentication. Not USB dongles, smart cards, X509 certificates or some reincarnation of the extended CardSpace debacle. That choice simplifies integration and minimizes disruption to user-experience. Main difference is entering these additional codes during authentication in addition to the password. No software installation required, smart cards/readers to carry around, browser compatibility issues or  flaky device drivers. For frequently used machines, there is even an option to avoid asking for codes on each login.
  • Two ways to get OTP. Users can either have the code delivered via SMS to their registered phone number or they can use a mobile application to generate codes. This design also makes sense.
    • SMS has the largest reach, working equally well with a 10-year-old “feature phone” with no applications as it does with the latest Android or iOS device.
    • On the other hand, SMS requires users have connectivity to their wireless carrier– not just any old Internet access, but specifically their mobile carrier.  This may not be the case when the user is travelling overseas for example. SMS is also much less reliable in emerging markets than the US. (SMS does not guarantee delivery; it is best effort. Nor does it have a time-bound for successful completion.) It may also incur charges for the user and/or service sending the messages.
    • Mobile applications have the advantage that they can work offline, once provisioned. Downside is requiring a compatible application that can generate codes according to the appropriate scheme. MSFT has already released one for Windows Phone– a choice of platform that would be puzzling, were it not for the brand affiliation. Luckily both Android and iPhone already have compatible applications such as Google Authenticator and Duo Mobile.
  • Settled on TOTP standard described in RFC 6328 for generating the codes by mobile apps. This may have been forced by existing options on Android/iPhone: all of them implement TOTP as common feature.** This has some interesting consequences.
    • TOTP codes are generated based on a secret cryptographic key, referred to as “seed,” and current time. This naturally requires an accurate clock on the phone, up to some tolerance. Typically time is quantized into 30-second intervals and the verification logic attempts to accommodate drift by looking back/forward a few intervals. (Note that time-zones and daylight savings do not pose problems; “time” is always measured as Greenwich/UMT/Zulu time.)
    • Less obvious is that time-based codes are easier to clone than counter-based ones. Multiple users with the same key can independently generate the same sequence, without interfering with each other. The other leading contender is HOTP, which predates TOTP. That design uses a counter  incremented each time a code is generated. If multiple people tried to use the same cryptographic secret, they would quickly run into problems: once the counter is incremented, the server will not accept a second OTP generated using an earlier value. (This is actually useful for security, making it easier to detect inappropriate usage. Sharing of credentials is a strongly discouraged practice.)
  • The mechanism used to provision those TOTP seeds also sticks to established methods. Secret keys are packaged into URLs and rendered as QR codes on the web page, intended to be scanned with phone camera. Even the URL format follows an earlier convention introduced by Google Authenticator, using the custom otpauth protocol scheme. While MSFT was free to pick a different one in principle, compatibility with existing Android and iPhone apps is helped by sticking to the same scheme.



Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s