I like this one. Maintained, open source, and you can even have encrypted backups.
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
Apparently some bug in lineageos causes the app to not save your keys.
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.
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.
(EDIT: Typo 'pointa' -> 'points')
> Secure: All data is stored in encrypted form on the iOS keychain
I suppose this means it's using the secure enclave behind the scenes?
Is the encrypted data (encrypted with what key?) part of the device iCloud backup?
EDIT: It looks like it was taken down because it uses an MD5 signature for the APK.
I know for a fact they use MD5withRSA for some of their own apks including YouTube -
* at least they did at the time that was written.
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.
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  and add yourself to the email list  if you want to get notified when you can try it out.
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.
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 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  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 . 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.
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?
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.
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).
also, they store the vaults encrypted anyway; you unlock it locally with a password, so even with a hack you still are reasonably safe.
can’t comment on others
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)
PayPal and Amazon both support TOTP, including for all support contacts, but it’s hidden. Personally, I’ve enabled these.
SMS 2FA is not acceptable and not secure.
I also don't recall Amazon (Atleast shopping side) having 2FA either but it's been a month since I checked.
Care to share a direct link to the TOTP configuration site though?
And a blogpost explaining the backstory: https://www.cyrozap.com/2014/09/29/reversing-the-symantec-vi...
But sure, for the average user, it’s basically useless.
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, with important discussion and rationale in Appendix 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, with important discussion and rationale in Appendix 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
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 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  does have optional support for SHA256 and configurable number of digits, so Google Authenticator could support that too if it wanted to.
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.
- 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.
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.
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).
Never an issue and I enjoy using an open source product backed by my favorite company, RedHat.
Other than that, it does what it says on the tin.
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 with the OTP plugin but for 99% of use cases, OTP Auth wins hands down.
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.
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.
Edit, dug up this post of mine which talks about totp strategies among other things. https://news.ycombinator.com/item?id=15421444
Also, if they don't have iCloud integration, how do you switch devices?
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.
It allows backing up to GPG encrypted files, and seems great overall. It's my new TOTP client of choice.
adb backup '-f /tmp/freeotp.ab org.fedorahosted.freeotp'
(non-rooted Nexus 5X)
Ideally, we'll all move to U2F soon.
When resetting the phone, or moving to a new iPhone, there's no way to carry over settings. The same applies if you have more than one device.
If you ever have any issues, you'll lose all your OTP keys.