Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This considers the route where somebody does not use the SMS option, but rather using TOTP, and the site offers a generated seed to input.

Two factors questionably at use:

  • password: something KNOWN
  • TOTP: does this count as something you HAVE?

What proof is there that I am using my cell phone to generate the TOTP codes? You can write the algorithm in maybe 30 lines of most languages, what if I have a script on my computer do it? Or have the same seed/script on all of my computers? Does this still count as a HAVE?


Extra followup if this use of TOTP does not count as two-factor (if I'm allowed followup questions): Is any use of TOTP acceptable for HAVE?

share|improve this question

3 Answers 3

up vote 2 down vote accepted

In a previous job we were looking at implementing two-factor, and had long discussions about what actually counted as a separate factor. For example, sending SMS to a phone is sort-of "something you have" although it's not as secure as a dedicated token. The solution to the long discussions was to abandon the term "two-factor" altogether and instead talk about "multi factor authentication". Because while things like TOTP and SMS codes are not as good as dedicated hardward, they are definitely better than a password alone.

share|improve this answer
1  
"Out Of Band" would be a way to describe an SMS'd message. I like your practical approach to dealing with the issue. Arguing about the name doesn't really get you nearer to solving the problem of risk acceptance: is it secure enough to protect your assets? Of course, it's ultimately just a guess (and it might be wrong.) –  John Deters Dec 17 '13 at 23:03

TOTP is an extension of the HMAC-based One Time Password algorithm (HOTP). Both TOTP and HOTP require an secret key to be incorporated into the algorithm. Devices and tokens that implement TOTP (Yubikey, Google Authenticator app) are designed to protect the secret key against extraction.

For example, Yubico mentions:

Secure manufacturing process The YubiKey is manufactured in Sweden, in a fully access automated process, using YubiHSM technology to ensure that no staff or IT administrators can have access to encryption keys.

Easy to program own secrets The YubiKey requires no special hardware for programming, enabling you to easily program and control your own encryption keys. If required, Yubico offer optional password write protection of the settings, but all YubiKeys sold on our web store can be re-programmed. For security reasons Yubico firmware is not upgradable, it’s a write only device and the encryption key can never be read out from the device. [Emphasis mine]

Tamper proof casing The YubiKey is based on standard components, high-pressure moulded into plastic, making it practically impossible to tamper. If tampered, it will require sophisticated equipment to read out the secrets and cannot be done without physically destroying the device. Each YubiKey is seeded individually, so any breach would be for that unique Yubikey only, there is no systemic breach. If lost or stolen, the user administrator can easily disable the YubiKey so that it no longer can be used.

If we assume that the secret key cannot easily be extracted from the token (and the above examples indicate that we can make that assumption), then it counts as "something you have". Even though the token may be mass produced, once combined with the secret key it becomes unique for the purposes of two-factor auth.

Edit: Thank you to Terry Chia who has pointed out that the Google Authenticator app stores the key in cleartext in a sqlite database on the device. This was reported in a bug report in March 2013. Google promptly noted that this is a "won't fix" issue:

Reported by wolfka...@gmail.com, Mar 26, 2013 What steps will reproduce the problem? 1. Open the databases database from within /data/data/com.google.android.apps.authenticator2/databases/database...

klyu...@google.com Thank you for your report. This is working as intended/designed. Step #1 assumes you have root access or have otherwise compromised the security of the Android device. Security of data stored on or processed by such devices cannot be guaranteed. ...

I'll note here that you can and should encrypt your Android device, and doing so will mandate a password to unlock the screen. This will protect against key extraction, among other things.

share|improve this answer
2  
"Devices and tokens that implement TOTP (Yubikey, Google Authenticator app) are designed to protect the secret key against extraction." - Not true. The Google Authenticator app merely stores the key in an sqlite database. –  Terry Chia Dec 17 '13 at 0:07
    
Fair comment, thank you. I'm going to add the bug report and response from Google into the answer. –  scuzzy-delta Dec 17 '13 at 0:21
    
"If we assume that the secret key cannot easily be extracted from the token (and the above examples indicate that we can make that assumption), then it counts as 'something you have' " is the token the code that TOTP produces given a time and secret key? How does a deterministic one-way algorithm turn it from KNOW to HAVE? does hashing a password also turn it into a HAVE? Does Google Authenticator storing secret in cleartext make it not a HAVE? –  Dan P Dec 17 '13 at 1:01
1  
A very philosophical set of questions. In my opinion: The token is the combination of the secret key and hardware device. It becomes a have because it's bound with the hardware. A password hash isn't a physical object, so it's not a have. The Google Authenticator situation makes it a less than perfect "have" factor. –  scuzzy-delta Dec 17 '13 at 19:59
    
"Devices and tokens that implement TOTP (Yubikey, Google Authenticator app)". FYI, Yubikeys don't implement TOTP, due to their lack of a clock. Helper apps must be installed to facilitate this. –  Walking Wiki Jun 4 at 2:18

OTPs, especially if they're SMS-text based are vulnerable to being intercepted by hackers. An out-of-band solution is needed to truly defeat/prevent man in the middle and man in the browser attacks. So, if OTPs are weak security and they add another step to the login process, they're not helping much. A really good out-of-band solution is Toopher - using the location-awareness of your mobile device, Toopher can automate normal behaviors so that when it's you logging in, no extra steps needed - when it's not you, Toopher notifies you and you can deny the fraudster.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.