
FreeOTP – An open-source solution for authentication soft tokens - bsilvereagle
https://fedoramagazine.org/freeotp-an-open-source-solution-for-authentication-soft-tokens/
======
burner47
andOTP (Open-source two-factor authentication App) -
[https://f-droid.org/app/org.shadowice.flocke.andotp](https://f-droid.org/app/org.shadowice.flocke.andotp)

I like this one. Maintained, open source, and you can even have encrypted
backups.

~~~
StavrosK
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](https://github.com/flocke/andOTP/issues/66)

------
StavrosK
FreeOTP is great, unfortunately it's unmaintained. There are so many easy
features it could get (e.g. a search box) but nothing is going on.

~~~
iou
As a current contributor, I know that's just not true
[https://github.com/freeotp/freeotp-
android/commits/master](https://github.com/freeotp/freeotp-
android/commits/master)

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.

~~~
gareim
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.

------
conorgil145
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=0BxEuMs2jIxWfVDlMTmRHTExQSG...](https://drive.google.com/open?id=0BxEuMs2jIxWfVDlMTmRHTExQSGs)

[2] [http://eepurl.com/c7OBwj](http://eepurl.com/c7OBwj)

~~~
jwfxpr
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
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-...](http://www.zdnet.com/article/google-prompt-you-can-now-just-tap-yes-
or-no-on-ios-android-to-approve-gmail-sign-in/)

~~~
zaarn
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.

~~~
conorgil145
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).

~~~
rickycook
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.

can’t comment on others

------
INTPenis
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.

~~~
StavrosK
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.

Other than that, it does what it says on the tin.

------
callahad
Article is from 2014, though the project is still minimally active:
[https://github.com/freeotp/freeotp-
android](https://github.com/freeotp/freeotp-android)

------
stephenr
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.

1: [http://cooperrs.de/otpauth.html](http://cooperrs.de/otpauth.html) 2:
[https://www.passwordstore.org](https://www.passwordstore.org) 3:
[https://github.com/tadfisher/pass-
otp#readme](https://github.com/tadfisher/pass-otp#readme)

~~~
hobarrera
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.

[https://github.com/WhyNotHugo/totp-cli](https://github.com/WhyNotHugo/totp-
cli)

------
advisedwang
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.

------
dndneux
I think storing TOTP secrets on a YubiKey is the most secure option, since the
secrets can't be extracted from the device. See
[https://developers.yubico.com/OATH/YubiKey_OATH_software.htm...](https://developers.yubico.com/OATH/YubiKey_OATH_software.html)
for the software needed for usage.

------
w8rbt
If you prefer command line programs and you like keeping your TOTP secrets PGP
encrypted, try goathen:
[https://github.com/w8rbt/goathgen](https://github.com/w8rbt/goathgen)

~~~
StavrosK
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.

~~~
scrollaway
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.

Edit, dug up this post of mine which talks about totp strategies among other
things.
[https://news.ycombinator.com/item?id=15421444](https://news.ycombinator.com/item?id=15421444)

~~~
StavrosK
Oh huh, I use keepass2android but didn't know it had TOTP support, thank you!

------
shaan7
I love FreeOTP because you can then use adb to grab a backup to restore to a
new phone.

~~~
aequitas
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?

~~~
StavrosK
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:

[https://www.stavros.io/tips/migrate-freeotp-to-
andotp/](https://www.stavros.io/tips/migrate-freeotp-to-andotp/)

------
4ad
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?

Thanks!

------
wyager
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.

~~~
StavrosK
If you're rooted, I use Titanium Backup for that.

~~~
FuckOffNeemo
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.

~~~
StavrosK
Actually, someone posted a very good solution above:
[https://play.google.com/store/apps/details?id=org.shadowice....](https://play.google.com/store/apps/details?id=org.shadowice.flocke.andotp)

It allows backing up to GPG encrypted files, and seems great overall. It's my
new TOTP client of choice.

~~~
FuckOffNeemo
That's awesome, thanks! I'll give it a go.

------
IgorPartola
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.

------
slim
Also freeOTP is 400k in size. I love tiny apps

------
wadkar
2014 - the title could use an update. Also, long time user here. Thanks for
keeping the FreeOTP app updated and working!

------
fergbrain
Is there a good solution for a hardware-based TOTP, similar to RSA SecurID but
for HMAC TOTP (RFC 4226) instead?

~~~
StavrosK
Yes, a Yubikey.

~~~
fergbrain
YubiKey isn’t self contained. I was asking about a hardware-based device that
has a built-in display (like SecurID does).

~~~
StavrosK
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)?

Ideally, we'll all move to U2F soon.

~~~
fergbrain
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).

~~~
StavrosK
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.

------
hobarrera
The lack of backup/export is the killer for me.

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.

------
mm4
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)"

------
wvh
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.

------
nodesocket
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.

~~~
esseti
authy has backups. check if it can also import from google authenticator..

~~~
bubblethink
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.

------
mfreeman
Obsidian for iOS and MacOS has probably the best UI and usability.

