This is fantastic, thank you. It has everything I needed, I'm going to see if I can migrate from FreeOTP to this. Thanks again.
EDIT: I wrote a short Python script that will migrate your tokens from FreeOTP to andOTP, I have posted it as an issue on the repo: https://github.com/flocke/andOTP/issues/66
If a search box is desirable I'd recommend upvoting an existing feature request on there or submitting a PR for that if you're an android developer too.
Could you guys push an update to the App Store please? The current version is 3 years behind. I also thought the project was unmaintained until just now.
I'm glad to hear that, but I don't know how valid your assertion is when scrolling just a bit down the first page brings up commits from 2014. I went to file/upvote the search box issue a few weeks ago, and the 71 open issues weren't encouraging.
Then, I figured I'd learn Android development and submit a PR, but saw 15 open ones from years ago and figured the project was unlikely to ever merge my PR and just left.
In my defense, those signs don't scream "maintained project" to me.
> fedorahosted.org was retired on March 1st, 2017. If you are viewing this page, odds are it's after that date and you have been redirected here by attempting to go to some project on fedorahosted.org.
Further down the page it says [if you are a maintainer]:
> We are also happy to setup redirects for your project to a new location. Just file a issue in https://pagure.io/fedora-infrastructure and we will try and help you out.
Know nothing about FreeOTP (though sounds interesting!), but my first impressions was also that it probably isn't active, given they haven't decided to set-up a 301 to the new project home.
When I was on Android, I never saw any reason not to use the open source Google Authenticator version (still available via F-Droid, or relatively easy to compile yourself). It's simple, it's fast, it's open, and it works.
MD5 APK signatures are still supported by Android and are accepted by Google Play when you upload an APK there.
See https://forum.f-droid.org/t/many-old-unmaintained-apps-have-... for more discussion about this in the context of F-Droid. I believe F-Droid was (is) using Oracle jarsigner to verify APK signatures and this is what causing F-Droid to reject APKs with MD5 signatures.
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.
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.
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?
I think the most useful threat model for 2FA is the case of a leaked password.
Malware on a trusted device or a local attacker are very hard to circumvent, though for that we have u2f which is reasonably safe against both.
I put 2FA in my password manager for that reason. If I have malware on my PC, I'm pwned, there are plenty of services without proper 2FA (looking at you paypal, amazon and my email provider) that I can consider myself pwned. However, preventing malware has become easier over this year alone, browsers do a lot and simple A/Vs like MS' built in one or ClamAV for linux can catch most of the dangerous ones.
So I'm not worried about malware.
I consider local attackers a more exotic attack vector and they are rare from my experience so I'm willing to take this risk in favor of making my life easier.
I agree that U2F is generally a more secure 2FA solution than soft tokens on a phone. If you use U2F (hardware), then what are you storing in your password manager (software)? Maybe, the 2FA secrets for sites that don't support U2F yet? If so, care to share which sites you use frequently that do not yet support U2F?
Also, which password manager do you use? I ask specifically because if it is a popular commercial option (1password, LastPass, Dashlane), then your attack vector on your password vault is larger than just local malware. It also includes remote attack directly on the servers of the commercial company. Sure, your vault is encrypted on their servers, but if a hacker gets their hands on your encrypted vault via malware on your system or via their remote servers its the same outcome: they have your encrypted vault and can start to work on it. Make sure that your vault password is really strong so that it cannot realistically be brute forced (I'm sure you already know that).
well 1password has wifi sync, and also sync via icloud/dropbox, so unless you use their built in service, it’s not really an issue (at least for targeted attacks)
also, they store the vaults encrypted anyway; you unlock it locally with a password, so even with a hack you still are reasonably safe.
>Maybe, the 2FA secrets for sites that don't support U2F yet?
That, yes, I put the 2FA secrets in there. They're also on my phone but I believe these are mostly outdated now since I tend to swap 2FA secrets about once a year.
>Also, which password manager do you use?
I use KeepassXC, it's a C++ implementation of Keepass which has excellent cross-platform support (Linux and Windows both work very well) and has integrated Keepass HTTP.
I sync the password database to my selfhosted Nextcloud instance (hosted on a OVH dedicated server) and use a password with about 50 characters in length (I use XKCD style passwords with about 10 words in there)
FYI, Amazon (retail) does support TOTP. Here is a direct link to the 2FA settings so you don't have to crawl through the account settings page looking for it: https://www.amazon.com/a/settings/approval.
Paypal supports TOTP everywhere, but it’s hidden on a page not reachable via any of their sites, in their old site, and you need to run a custom python script to even generate the token you want.
Wow, that is horrible. Given that, I would argue that, for all intents and purposes, they do not support TOTP then. An average user has zero chance of doing all of that correctly. Bummer the don't support it as a first class citizen in their security UX on their main site.
Care to share a direct link to the TOTP configuration site though?
Firstly, I really appreciate the thoughtfulness and thoroughness of the reply, you've clearly invested significant thought into these issues, which in and of itself is a good sign.
Secondly, I do agree that the threat model for 2FA lacks concise definition, I've had the same thought. It certainly does make it harder to think through how to balance the convenience-security tradeoff. I suppose the resolution to that is to acknowledge that ontologically the threat model may in fact attach elsewhere, and that the specific detail of the implementation choices within a 2FA framework (hard/soft tokens, time dependent/use dependent, etc etc) should be selected based on what threat model you are addressing. So for your implementation, I would think it speaks to the dominant use-case and its dominant threat model: an individual user's myriad personal accounts, and prevention of fraudulent access. (Unless your expected use case is within an organisation's authentication framework, in which case I'm sure you'd have policy-defined software behaviour set by administrators.) In other words, I expect your typical use case is more worried about opportunistic remote attacks (after, say, stale logins and passwords being breached, or successful phishing attack) than anything targeted, and so physical access by a skilled attacker is not considered a strong threat (though 2FA has a role in preventing opportunistic physical access as well, especially when used in financial transactions). I'm sure you've given that all a lot of thought too, so consider my thoughts only for what they're worth!
> This is obviously bad, but also obviously out of scope for 2FB.
Is it though? Let's assume that the malware functions outside the browser. Are you sure your extension cannot identify a QR code, identify that it is a valid seed for 2FA, and capture that information before the page finishes rendering, before the malware would have a chance to 'see' it? You could still offer your user the chance to display it if required. I honestly don't know enough about browser extension design to know if that's feasible, but if your app could in fact present a strong mitigation against a pre-installed malware attack then, my friend, you'd have hugely contributed to your user's security.
> 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.
This is an excellent concept, and sounds well executed. I'll have to give 2FB a try by the sound of it.
> One huge benefit of 2FB being a web extension is that it can help prevent a user falling victim to a phishing attack.
This is a good benefit that I hadn't considered.
> Finally, I am curious which specific portions of NIST 800-63B are you referring to in your comment?
The new advice on memorised secrets is laid out in 5.1.1 and subsections[0], with important discussion and rationale in Appendix 1[1]. It differs significantly from what is widely presented as 'best practice'. Though advice on memorised secrets is probably out of scope for 2FB.
Am happy to discuss in email anything you like on this, I'll flick you a quick message.
> Are you sure your extension cannot identify a QR code, identify that it is a valid seed for 2FA, and capture that information before the page finishes rendering, before the malware would have a chance to 'see' it?
I am sure that any browser extension cannot defeat malware running on the system. We have to assume that the malware is robust and sophisticated. If that is true, then it can monitor my browser and steal the secret directly from the web page as soon as the response comes in from the server. Regardless of how the secret is presented to the user (QR code, plain text, etc) and how 2FB changes the rendered page, there is no way that the malware wouldn't be able to also steal it in that same time frame if it's written correctly.
> The new advice on memorised secrets is laid out in 5.1.1 and subsections[0], with important discussion and rationale in Appendix 1[1].
Gotcha. I literally downloaded this report last week and added it to my kindle along with a boatload of other 2FA related case studies, reports, and white papers. Lots of continued research reading to do. I'll keep an eye out for the section you highlighted.
Great to hear that you might kick the tires on 2FB! It is still heavily under development, but getting closer to a dev preview release. If you haven't already, join the mailing list to get notified of releases: http://eepurl.com/c7OBwj
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.
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.
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.
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.
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.
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).
With so many other recommendations in this thread I thought I'd say that I've used FreeOTP for several years now. Currently I have 10 "keys" in it that I use daily.
Never an issue and I enjoy using an open source product backed by my favorite company, RedHat.
I've used it for years with 25+ keys, and it gets a bit unwieldy. The main problem is that the only sorting mechanism is manual, so I can't sort by last used, or search the keys by name, so I keep having to read the entire list every time to find the key I want.
On iOS (and beta for macOS) I can't recommend OTP Auth[1] highly enough.
It does one thing and does it well. For a business/team case (i.e. if an account must be shared) I'd probably stick to Pass[2] with the OTP plugin[3] but for 99% of use cases, OTP Auth wins hands down.
There's also _totp-cli_, which also uses _pass_ as a backend. The big difference is mostly that _totp-cli_ uses a more human-friendly interface, rather than requiring machine-friendly input. It also predates pass's support for plugins.
OTPs suffer from being phished. If you accidentally log in to a phishing site, you would still type in an OTP when prompted, which the phishing site can pass along. While this does only give one time access, that can still do a huge amount of damage.
Solutions like U2F create credentials that are specific to the site you are currently on, enforced by the software. So the credential sent to www.goeglo.com isn't valid for www.google.com, and so foils phishing much more completely.
Having the tokens on the computer with the KeePass file feels a bit too close to home for me. I can heartily recommend a YubiKey for those, which plugs in to USB and you can use their very nice TOTP desktop app.
You can always keep the totp in a separate keepassxc database. It's not a separate device but unless your threat involves targeted machine access, it's a separate factor.
Keepass2android supports totp as well, and can lock the kdbx secret with the Android secret storage system giving you a little bit of trade-off there if you are interested.
How did you manage to do this. I switched to freeotp for this reason but am unable to make a backup following online instructions. Do I need to have my device rooted?
Switch to andOTP, I did it last night and it's much better than FreeOTP (maintained, more features, supports backups natively). You can even migrate easily from FreeOTP using this short script I wrote:
I'm a little bit confused about these applications' security model. Normally I'd want whatever secrets are kept by these apps never to leak in the iCloud backups (secure enclave storage? I don't know). Do they do this or do they do something else? I see that some apps boast about iCloud integration. That is certainly something I don't want. But for the others that don't have iCloud integration, isn't the secure data backed in iCloud as part of the (daily?) device backup?
Also, if they don't have iCloud integration, how do you switch devices?
I’ve been using FreeOTP for TOTP tokens for the last few years. No issues. I wish it had the ability to export tokens, although I can see why they practically wouldn’t want to give that ability to clueless end-users.
I use to use TB for everything but, new corporate requirements mean I can no longer run a rooted phone. Less I use a second phone for work specifically but I have no desire to carry two around with me.
Haven't been able to find a way around of backing up my tokens. Though admittedly the use case is small anyway, the backups are only valid for the device that the backups are from. Though this is by design, of course.
My problem with GA has always been that when you get a new device, you have to have a manual process to transfer your setup to it. Yes it’s more secure. Yes it sucks. I recently switched to Authenticator Plus, which is commercial, because it has iCloud backup. The seeds are locally encrypted before they hit the server. To me this is an acceptable trade off for not being locked out of my accounts if I lose my phone (no, not everyone has sane backup methods and SMS isn’t secure). Does FreeOTP have this feature? I can’t tell.
Oh, I see, I thought SecurID were just USB HSMs. I'm not aware of one, I'm afraid. Why do you need that much security (and why is a phone not good enough)?
I would like my “thing I have” to be physically separate from the device that stores my “thing I know.” I also don’t always have access to a USB port (or NFC).
Hm I see. I don't know any such device, I'm afraid. I only use my phone/Yubikey. It's not hard to make one, if you're so inclined (TOTP is a pretty easy protocol), and I'm sure someone will be selling one already.
I think software token that you setup with qr or password from page is still "something you know (but it was too long to remember)", not "something you have (like a private key that that was generated on and never left your security key)"
I don't know if there are many Jolla/Sailfish users here, but SailOTP works well for standard TOPT/HOTP authentication. I think at the moment it's the only non-default app I have installed on my phone.
Does anybody know how to transfer Google Authenticator entries on iOS? Getting an iPhone X soon and redoing all 2fa services is horrible and makes me cry.
pretty sure that would be a security disaster if apps could read other apps' storage. So no, no other app can import it unless a) the app exports it or b) you have root. Also, authy, duo and the like are proprietary apps with a lock-in model. No free clients, no documented protocol. Usually they just tack on some server side functionality for notifications etc. on top of TOTP.
I like this one. Maintained, open source, and you can even have encrypted backups.