6 ms·

I have used FreeOTP, Google Authenticator, Authy, and LastPass Authenticator. Of those options, I use Authy because it is also free and has hands down the best

I have used FreeOTP, Google Authenticator, Authy, and LastPass Authenticator. Of those options, I use Authy because it is also free and has hands down the best UX. However, I think that current solutions for soft token two factor authentication (2FA) generally do not provide a good user experience for end users. When trying to login and get work done, it is frustrating that the typical 2FA login flow requires a context switch to a completely different device, especially one that will likely distract you with non-work related notifications and content. That is why I am working on a project called Two Factor Buddy (2FB), which integrates directly with the browser to automate the entry of 2FA codes during the login process with all of your favorite third party services (e.g. Github, Google, AWS, Stripe, etc). This means you can maintain the 2FA level of security on your accounts and get to work more quickly. If 2FB sounds interesting, check out a short screencast of what the login flow looks like using 2FB [1] and add yourself to the email list [2] if you want to get notified when you can try it out. [1] https://drive.google.com/open?id=0BxEuMs2jIxWfVDlMTmRHTExQSGs https://drive.google.com/open?id=0BxEuMs2jIxWfVDlMTmRHTExQSG... [2] http://eepurl.com/c7OBwj http://eepurl.com/c7OBwj

directionless 9y ago
FWIW These days 1password supports TOTP directly, pretty smooth in the browser.
- conorgil145 9y ago
  1passowrd has a good blog post explaining why using 1password for TOTP is not 2FA [1]. If someone gets into your password vault, then they have both authentication factors: your passwords (what you know) and your 2FA secrets (theoretically, what you have). [1] https://blog.agilebits.com/2015/01/26/totp-for-1password-users/ https://blog.agilebits.com/2015/01/26/totp-for-1password-use...
ocdtrekkie 9y ago
The main issue I have with Authy is caused by their apparent efforts to convince websites to implement two-factor authentication in such a way that it exclusively works with Authy, despite offering no advantages over TOTP. (My understanding is that the API effectively creates a TOTP token, which if you can intercept, can be used in a normal TOTP client.) Cloudflare used this for years, and Humble Bundle uses it right now. It is hard to understand why this is a thing if Authy is not paying companies to restrict a critical security feature to users of their app.
- conorgil145 9y ago
  I have read about this a little from the user POV, but I have not yet used Authy to build a service which provides 2FA, so I do not understand the details enough to really talk intelligently about the differences. I do recall reading that Authy uses SHA256 and 7 digit codes instead of SHA1 and 6 digit codes like Google Authenticator (cannot find source). However, the Key URI Format documentation in the Google Authenticator project [1] does have optional support for SHA256 and configurable number of digits, so Google Authenticator could support that too if it wanted to. [1] https://github.com/google/google-authenticator/wiki/Key-Uri-Format https://github.com/google/google-authenticator/wiki/Key-Uri-...
jwfxpr 9y ago
IANAE in identification & authentication systems, but doesn't using a browser plugin for the 'something you have' portion of 2FA negate the principal benefit — that which, the algorithm/app/token providing the OTP is inaccessible to an attacker with access to the primary login interface? Let's say I'm following accepted best practice (ignoring for a moment the current NIST 800-63B draft[0] and its aggressively divergent recommendations about remembered secrets), and using unique, randomly generated passwords for every single account authentication. Being a human, I need a software-based password manager to enable this. This is installed as an extension in my browser. Excellent, so far I have followed the 'best advice' as it's universally given. Now I have more best practice advice, and I establish 2FA for accounts that support it. Aaaaand then I install another (your) browser extension. Have I not simply made the entirety of these security precautions vulnerable to a single vector of attack at this point? I grant there's a limited version of this risk if I have, say, LastPass and Authy both installed on the same mobile device (for the record I do not), but the colossal attack surface on a desktop/desktop-browser/human-user/intentionally-minimised-interactions-and-decision-points combo gives me cold sweats. [0]https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html
- conorgil145 9y ago
  Sorry this is so long, but I felt it important to be relatively thorough. It sounds like there are 2 distinct attack vectors you are considering: malware installed on a trusted device and a local attacker gaining access to a trusted device. I'll define "trusted device" as any device which has a 2FA secret on it (e.g. phone, tablet, laptop, etc). MALWARE Malware on a trusted device is absolutely a legitimate attack vector and there are a few distinct scenarios to discuss. First, assume malware is on the trusted device before 2FA is enabled for a given service. In this scenario, the malware can obtain the 2FA secret directly anytime the user configures 2FA when the QR code is shown on the screen, etc. This is obviously bad, but also obviously out of scope for 2FB. Second, assume malware is only installed on the trusted device after 2FA is enabled on a given service. In this scenario, the malware will most likely not be able to get the 2FA secret from the service because most services only show the 2FA secret during configuration (good!). The malware can then only get the 2FA secret if it is stored on the same trusted device as the malware (e.g. what 2FB does). There are some approaches to reduce the attack surface in this scenario. For example, 2FB can encrypt the 2FA secret vault on the trusted device with a user provided password so that all 2FA secrets on disk are encrypted. The malware will now have access to encrypted data on disk that it will have to brute force. This is a similar approach to how Authy cloud backups work [1] and is reasonably secure assuming that the user provided password is strong. 2FB can individually decrypt a given 2FA secret at the appropriate point during the login flow so that the secret is only ever available in plain text in memory and for a short time period. This does not reduce the risk to zero, but it does significantly decrease the risk and increase the complexity of the required malware to obtain the plain text 2FA secrets. Also, users who are (rightly) concerned about malware on their devices will have the option to explicitly not treat the laptop as a trusted device (disable storage of 2FA secrets on their laptop). In this scenario, 2FB will send a push notification to the 2FB app on your mobile device each time that a 2FA code is required during the login flow. This behavior will basically be the same as Google Prompt [2]. However, whereas Google Prompt only works within the Google ecosystem, 2FB will work for any sites that 2FB integrates with (e.g. Google, Amazon, Microsoft, Github, Stripe, etc, etc). I realize that this is not mentioned at all in the screencast I initially linked to and you had no way to know about this (unless you’re a good guesser or read all of my previous HN comments). ATTACKER WITH LOCAL ACCESS This situation begs the question of what the actual threat model is for 2FA. I have been trying to track down an authoritative definition of the 2FA threat model, but cannot find one from a reliable source. (If you know of one in any academic papers, security white papers, etc, please share!). I think that the threat model for 2FA primarily includes a remote attacker gaining access to an account via a leaked knowledge factor (e.g. password). I do not think that 2FA is intended to prevent against local attackers or device theft in general. That being said, I am in strong agreement that separating the knowledge factor and possession factor as much as reasonable is a great idea. In practice, I believe this means that your password manager on your trusted device should be configured to auto-lock after X minutes of inactivity so that, in effect, it is only unlocked when you are entering a password in a web page. In this case, the knowledge factors are reasonably protected on the trusted device (assuming the master password for your password vault is strong) and could basically be treated as if they weren’t there at all because a local attacker would need to brute force the encrypted file to gain access to the passwords. Similarly, as mentioned above, 2FB can optionally encrypt the 2FA secret vault locally on disk. Also, a local attacker will likely not even need to steal your authentication factors at all to gain access to your accounts because they can just steal your active session cookies to gain access to your accounts. A security measure which is more intended to solve the local attacker/stolen device attack vector is full disk encryption. Any device with full disk encryption enabled with a strong password should be reasonably protected from a local attacker assuming that the attacker does not gain access to the trusted device while it is running and logged in as a user. FINAL THOUGHT One huge benefit of 2FB being a web extension is that it can help prevent a user falling victim to a phishing attack. During each login flow, 2FB can verify that a given web page is loaded over HTTPS with a valid cert and that the domain matches the domain for which a 2FA secret was initially configured. Only then will the 2FA code be injected into the page. 2FB cannot be tricked by pages that look like the expected site and are actually on some bogus domain. I am working on a security white paper to explain 2FB’s architecture and address the concerns you raised and several others. My email is in my profile if you’re interested in continuing the discussion, which I would find incredibly valuable! Finally, I am curious which specific portions of NIST 800-63B are you referring to in your comment? [1] https://authy.com/blog/how-the-authy-two-factor-backups-work/ https://authy.com/blog/how-the-authy-two-factor-backups-work... [2] http://www.zdnet.com/article/google-prompt-you-can-now-just-tap-yes-or-no-on-ios-android-to-approve-gmail-sign-in/ http://www.zdnet.com/article/google-prompt-you-can-now-just-...
solotronics 9y ago
I use a ubikey (why not a bluetooth version with a physical button?) because its easier to use than unlocking your phone.
cormacrelf 9y ago
By far the best UX... for adding a token, which happens about 100x less frequently than using one. Google Authenticator gets to a valid token in about 2 seconds on my iPhone 6. Authy takes > 12 seconds, and is frozen - no spinner, no nothing - until that point.
- conorgil145 9y ago
  Interesting, I have not encountered that while using Authy on my phone (Android, Galaxy S5). I think that Authy has the best UX overall, especially when looking up a 2FA code, but generally because: - The overall design (color scheme, shapes, etc) is much more pleasant and friendly - each entry has a helpful provider icon, which makes it significantly easier to visually search the list and identify the correct provider. You can also manually change the icon (from a small list) if the one auto assigned is not correct. FreeOTP just shows a blue square icon for every single entry in the list. - after finding the correct account by scrolling through the list, you need to click on the account to show the 2FA code. I reallly like this (compared to Google Authenticator) because the only digits shown on the screen while I am manually entering it into the browser are the digits that I care about. I cannot tell you how many times I've used GA in the past and accidentally typed the 3 final digits from the incorrect row above or below and need to backspace and correct in the browser. Silly, but incredibly annoying. FreeOTP gets this UX right too. - when adding a duplicate entry in FreeOTP (scanning a QR code for a service and account combo that is already in FreeOTP), it silently fails to correctly update the 2FA secret (it just does nothing). This happens anytime I rotate my 2FA secret on a website. Authy and GA handle this scenario better. Authy create a duplicate entry with the same name and GA overwrites the existing entry. - though I don't use it myself, Authy can show either a list of entries (one per row), or a grid of entries. Some users will likely prefer one display over the other. FreeOTP only has a list view option. - I don't use Authy cloud backup myself, but that is one main reason that many people choose to use Authy. FreeOTP does not have any backup options that I am aware of. - When deleting a 2FA entry, Authy immediately removes the 2FA entry from your home screen list view, but gives you a 48 hour grace period before it actually deletes the entry from your phone. This significantly reduces anxiety when rotating 2FA secrets and generally gives me warm fuzzies in case I screw something up accidentally. Authy has some of its own warts for sure, but I personally find it to be the best of the mobile apps I've tried by far.
zimbatm 9y ago
Authy also has a Desktop agent that can link with the phone's OTP. It doesn't work on Linux though.
- conorgil145 9y ago
  Authy desktop is definitely a step in the right direction in terms of UX on desktop. However, I dislike that I still need to manually search for the correct 2FA entry and copy/paste the code into the browser. I mentioned in another comment [1] that I am working on a project called Two Factor Buddy (2FB) that integrates directly with the browser and automates the entry of 2FA codes entirely. IMO, a much more pleasant UX. Also, I do not like that Authy cloud backup relies on user provided passwords because users are notoriously, insanely, ridiculously bad at creating secure passwords. If an attacker gets ahold of the encrypted secret via Authy's servers, then they can work on brute forcing it locally. IMO, the ideal is to have a simple process to sync 2FA secrets between all of your trusted devices either directly and out of band (no servers used at all), or via the web using pub/priv keys, which would be significantly more secure than a user provided password for encryption. The key is to make sure it is still insanely simple to use, though. [1] https://news.ycombinator.com/item?id=15692691 https://news.ycombinator.com/item?id=15692691

directionless 9y ago

FWIW These days 1password supports TOTP directly, pretty smooth in the browser.

conorgil145 9y ago
1passowrd has a good blog post explaining why using 1password for TOTP is not 2FA [1]. If someone gets into your password vault, then they have both authentication factors: your passwords (what you know) and your 2FA secrets (theoretically, what you have). [1] https://blog.agilebits.com/2015/01/26/totp-for-1password-users/ https://blog.agilebits.com/2015/01/26/totp-for-1password-use...

ocdtrekkie 9y ago

The main issue I have with Authy is caused by their apparent efforts to convince websites to implement two-factor authentication in such a way that it exclusively works with Authy, despite offering no advantages over TOTP. (My understanding is that the API effectively creates a TOTP token, which if you can intercept, can be used in a normal TOTP client.) Cloudflare used this for years, and Humble Bundle uses it right now. It is hard to understand why this is a thing if Authy is not paying companies to restrict a critical security feature to users of their app.

conorgil145 9y ago
I have read about this a little from the user POV, but I have not yet used Authy to build a service which provides 2FA, so I do not understand the details enough to really talk intelligently about the differences. I do recall reading that Authy uses SHA256 and 7 digit codes instead of SHA1 and 6 digit codes like Google Authenticator (cannot find source). However, the Key URI Format documentation in the Google Authenticator project [1] does have optional support for SHA256 and configurable number of digits, so Google Authenticator could support that too if it wanted to. [1] https://github.com/google/google-authenticator/wiki/Key-Uri-Format https://github.com/google/google-authenticator/wiki/Key-Uri-...

jwfxpr 9y ago

IANAE in identification & authentication systems, but doesn't using a browser plugin for the 'something you have' portion of 2FA negate the principal benefit — that which, the algorithm/app/token providing the OTP is inaccessible to an attacker with access to the primary login interface? Let's say I'm following accepted best practice (ignoring for a moment the current NIST 800-63B draft[0] and its aggressively divergent recommendations about remembered secrets), and using unique, randomly generated passwords for every single account authentication. Being a human, I need a software-based password manager to enable this. This is installed as an extension in my browser. Excellent, so far I have followed the 'best advice' as it's universally given. Now I have more best practice advice, and I establish 2FA for accounts that support it. Aaaaand then I install another (your) browser extension. Have I not simply made the entirety of these security precautions vulnerable to a single vector of attack at this point? I grant there's a limited version of this risk if I have, say, LastPass and Authy both installed on the same mobile device (for the record I do not), but the colossal attack surface on a desktop/desktop-browser/human-user/intentionally-minimised-interactions-and-decision-points combo gives me cold sweats. [0]https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html

conorgil145 9y ago
Sorry this is so long, but I felt it important to be relatively thorough. It sounds like there are 2 distinct attack vectors you are considering: malware installed on a trusted device and a local attacker gaining access to a trusted device. I'll define "trusted device" as any device which has a 2FA secret on it (e.g. phone, tablet, laptop, etc). MALWARE Malware on a trusted device is absolutely a legitimate attack vector and there are a few distinct scenarios to discuss. First, assume malware is on the trusted device before 2FA is enabled for a given service. In this scenario, the malware can obtain the 2FA secret directly anytime the user configures 2FA when the QR code is shown on the screen, etc. This is obviously bad, but also obviously out of scope for 2FB. Second, assume malware is only installed on the trusted device after 2FA is enabled on a given service. In this scenario, the malware will most likely not be able to get the 2FA secret from the service because most services only show the 2FA secret during configuration (good!). The malware can then only get the 2FA secret if it is stored on the same trusted device as the malware (e.g. what 2FB does). There are some approaches to reduce the attack surface in this scenario. For example, 2FB can encrypt the 2FA secret vault on the trusted device with a user provided password so that all 2FA secrets on disk are encrypted. The malware will now have access to encrypted data on disk that it will have to brute force. This is a similar approach to how Authy cloud backups work [1] and is reasonably secure assuming that the user provided password is strong. 2FB can individually decrypt a given 2FA secret at the appropriate point during the login flow so that the secret is only ever available in plain text in memory and for a short time period. This does not reduce the risk to zero, but it does significantly decrease the risk and increase the complexity of the required malware to obtain the plain text 2FA secrets. Also, users who are (rightly) concerned about malware on their devices will have the option to explicitly not treat the laptop as a trusted device (disable storage of 2FA secrets on their laptop). In this scenario, 2FB will send a push notification to the 2FB app on your mobile device each time that a 2FA code is required during the login flow. This behavior will basically be the same as Google Prompt [2]. However, whereas Google Prompt only works within the Google ecosystem, 2FB will work for any sites that 2FB integrates with (e.g. Google, Amazon, Microsoft, Github, Stripe, etc, etc). I realize that this is not mentioned at all in the screencast I initially linked to and you had no way to know about this (unless you’re a good guesser or read all of my previous HN comments). ATTACKER WITH LOCAL ACCESS This situation begs the question of what the actual threat model is for 2FA. I have been trying to track down an authoritative definition of the 2FA threat model, but cannot find one from a reliable source. (If you know of one in any academic papers, security white papers, etc, please share!). I think that the threat model for 2FA primarily includes a remote attacker gaining access to an account via a leaked knowledge factor (e.g. password). I do not think that 2FA is intended to prevent against local attackers or device theft in general. That being said, I am in strong agreement that separating the knowledge factor and possession factor as much as reasonable is a great idea. In practice, I believe this means that your password manager on your trusted device should be configured to auto-lock after X minutes of inactivity so that, in effect, it is only unlocked when you are entering a password in a web page. In this case, the knowledge factors are reasonably protected on the trusted device (assuming the master password for your password vault is strong) and could basically be treated as if they weren’t there at all because a local attacker would need to brute force the encrypted file to gain access to the passwords. Similarly, as mentioned above, 2FB can optionally encrypt the 2FA secret vault locally on disk. Also, a local attacker will likely not even need to steal your authentication factors at all to gain access to your accounts because they can just steal your active session cookies to gain access to your accounts. A security measure which is more intended to solve the local attacker/stolen device attack vector is full disk encryption. Any device with full disk encryption enabled with a strong password should be reasonably protected from a local attacker assuming that the attacker does not gain access to the trusted device while it is running and logged in as a user. FINAL THOUGHT One huge benefit of 2FB being a web extension is that it can help prevent a user falling victim to a phishing attack. During each login flow, 2FB can verify that a given web page is loaded over HTTPS with a valid cert and that the domain matches the domain for which a 2FA secret was initially configured. Only then will the 2FA code be injected into the page. 2FB cannot be tricked by pages that look like the expected site and are actually on some bogus domain. I am working on a security white paper to explain 2FB’s architecture and address the concerns you raised and several others. My email is in my profile if you’re interested in continuing the discussion, which I would find incredibly valuable! Finally, I am curious which specific portions of NIST 800-63B are you referring to in your comment? [1] https://authy.com/blog/how-the-authy-two-factor-backups-work/ https://authy.com/blog/how-the-authy-two-factor-backups-work... [2] http://www.zdnet.com/article/google-prompt-you-can-now-just-tap-yes-or-no-on-ios-android-to-approve-gmail-sign-in/ http://www.zdnet.com/article/google-prompt-you-can-now-just-...

solotronics 9y ago

I use a ubikey (why not a bluetooth version with a physical button?) because its easier to use than unlocking your phone.

cormacrelf 9y ago

By far the best UX... for adding a token, which happens about 100x less frequently than using one. Google Authenticator gets to a valid token in about 2 seconds on my iPhone 6. Authy takes > 12 seconds, and is frozen - no spinner, no nothing - until that point.

conorgil145 9y ago
Interesting, I have not encountered that while using Authy on my phone (Android, Galaxy S5). I think that Authy has the best UX overall, especially when looking up a 2FA code, but generally because: - The overall design (color scheme, shapes, etc) is much more pleasant and friendly - each entry has a helpful provider icon, which makes it significantly easier to visually search the list and identify the correct provider. You can also manually change the icon (from a small list) if the one auto assigned is not correct. FreeOTP just shows a blue square icon for every single entry in the list. - after finding the correct account by scrolling through the list, you need to click on the account to show the 2FA code. I reallly like this (compared to Google Authenticator) because the only digits shown on the screen while I am manually entering it into the browser are the digits that I care about. I cannot tell you how many times I've used GA in the past and accidentally typed the 3 final digits from the incorrect row above or below and need to backspace and correct in the browser. Silly, but incredibly annoying. FreeOTP gets this UX right too. - when adding a duplicate entry in FreeOTP (scanning a QR code for a service and account combo that is already in FreeOTP), it silently fails to correctly update the 2FA secret (it just does nothing). This happens anytime I rotate my 2FA secret on a website. Authy and GA handle this scenario better. Authy create a duplicate entry with the same name and GA overwrites the existing entry. - though I don't use it myself, Authy can show either a list of entries (one per row), or a grid of entries. Some users will likely prefer one display over the other. FreeOTP only has a list view option. - I don't use Authy cloud backup myself, but that is one main reason that many people choose to use Authy. FreeOTP does not have any backup options that I am aware of. - When deleting a 2FA entry, Authy immediately removes the 2FA entry from your home screen list view, but gives you a 48 hour grace period before it actually deletes the entry from your phone. This significantly reduces anxiety when rotating 2FA secrets and generally gives me warm fuzzies in case I screw something up accidentally. Authy has some of its own warts for sure, but I personally find it to be the best of the mobile apps I've tried by far.

zimbatm 9y ago

Authy also has a Desktop agent that can link with the phone's OTP. It doesn't work on Linux though.

conorgil145 9y ago
Authy desktop is definitely a step in the right direction in terms of UX on desktop. However, I dislike that I still need to manually search for the correct 2FA entry and copy/paste the code into the browser. I mentioned in another comment [1] that I am working on a project called Two Factor Buddy (2FB) that integrates directly with the browser and automates the entry of 2FA codes entirely. IMO, a much more pleasant UX. Also, I do not like that Authy cloud backup relies on user provided passwords because users are notoriously, insanely, ridiculously bad at creating secure passwords. If an attacker gets ahold of the encrypted secret via Authy's servers, then they can work on brute forcing it locally. IMO, the ideal is to have a simple process to sync 2FA secrets between all of your trusted devices either directly and out of band (no servers used at all), or via the web using pub/priv keys, which would be significantly more secure than a user provided password for encryption. The key is to make sure it is still insanely simple to use, though. [1] https://news.ycombinator.com/item?id=15692691 https://news.ycombinator.com/item?id=15692691