LWN: Comments on "FreeOTP multi-factor authentication"

ye olde library bundling

mp — Sat, 15 Feb 2014 14:34:24 +0000

And - in addition to not having N extra copies of ZXing on the device - not bundling it should mean not having N applications needlessly requiring extra permissions to access the phone camera.

Soft-tokens

robbe — Fri, 31 Jan 2014 14:53:08 +0000

> [...] it's still an improvement [...]
I was specifically NOT contesting that.

I'll try to be a bit mor formal In all OTP schemes the server and client both know a client-specific SEED. SECRET (if used) is known to user and server. PASSWORD (if used) is known to user and client.

* The most naive scheme 1 is:
Client sends h(TIME, SEED) to the server to authenticate. h is a cryptographically secure hash.

An attacker that can steal SEED from the client device or a backup can break this.

* Scheme 2:
User types in SECRET, then the client sends (h(TIME, SEED), SECRET) to the server.

To break this, an attacker needs access to the SEED, as above, and in addition needs to sniff at least one authentication (to get access to the static SECRET).

* Scheme 3:
User authenticates to client with PASSWORD. This unlocks access to the encrypted SEED so that client can send h(TIME, SEED) to the server.

Access to a data-at-rest copy now only gets the attacker e(SEED). To get at the real SEED she either needs to be able to control the client during authentication (to key-log PASSWORD, or just read the cleartext SEED from memory).

* Scheme 4:
User types in SECRET, then the client sends f(h(TIME, SEED), SECRET) to the server.

If f(a, b) := a XOR b this corresponds to your scheme, how I understood it.
RSA has f(a, b) := (a + b) mod x with some known x.

For an attacker, this is very similar to scheme 2. He needs access to the SEED, e.g. via a backup, and to sniff one authentication.

* Scheme 5 (my proposal)
User types in SECRET, then the client sends g(h(TIME, SEED), SECRET) to the server.

Looks like 4, but this time g is a trapdoor function (e.g. SHA512). An attacker now has the same requirements as in scheme 3 -- access to the backup and sniffing a connection will not be enough.

In conclusion, I don't think your scheme is more secure than simply concatenating a static SECRET to the OTP (scheme 2) and less secure than schemes 3 or 5.

OTP is One Time Passcode, not One Time Pad

kraftcheck — Thu, 30 Jan 2014 14:43:54 +0000

Twice in this article the author uses the phrase "one time pad (OTP) passcode".

a) OTP is an abbreviation of "one time passcode", not "one time pad",

b) A one time pad is an encryption mechanism, not an authentication mechanism, and

c) If the only secret that is shared is a hash, then the underlying mechanism most certainly is not a one time pad.

Soft-tokens

dlang — Wed, 29 Jan 2014 07:09:25 +0000

two things

1. usually the secret is not sent over the network, it's used to calculate something else.

for example, in an SSL negotiation, there is a random secret picked by each side that the key material is used on.

the attacker would not only need the secret as stored on disk, and the data sent over the network, they would also need the random number generated for the session as well.

which leads to

2. this is not a defence against an attacker who's in control of your mobile device, this is an defence against an attacker who get access to a backup of your mobile device.

if you have an iDevice, this could be getting your backup from iTunes. If you backup your Android to your desktop, this is about someone getting access to your desktop (or it's backups).

Even if there is some ability to brute force they password from the XORd material on 'disk' and what's sent over the network, it's still an improvement from the default where the client checks the password, because that only needs the attacker to get a copy of the material stored on 'disk'

Soft-tokens

raven667 — Wed, 29 Jan 2014 05:22:50 +0000

I think what was said is if you can see the plaintext of a successful token usage then it is trivial to work out what the pin is by brute force by calculating all possible token codes and pins for that time range, to see which value matches the one actually used for the legitimate login, without involving the server or risking an account lockout.

This attack depends on seeing the plaintext of the auth, so would be mitigated by transport security (SSL). Of course it is moot if the vantage point for sniffing is the mobile device which we have presumed to be compromised to get the soft token seed in the first place, we just have o grab the pin when it is next used and save it along with the captured seed value.

Soft-tokens

dlang — Wed, 29 Jan 2014 01:21:29 +0000

I may be missing something, but I don't see how my method gives the attacker anything if they are able to capture the communications to the server?

If someone has control of the mobile device, they can capture the keystrokes and have full access no matter what you use. That's not the threat I'm trying to defend against. I'm trying to defend against the attacker getting a clone of your device and then being able to brute-force against that clone image.

to restate what I'm suggesting

the secret is stored on your mobile device, it gets XORd with a hash of the password you type in, that secret is then used to compute whatever you exchange with the server. If the password you type is wrong, the exchange with the server will not compute correctly.

Soft-tokens

robbe — Tue, 28 Jan 2014 15:20:38 +0000

RSA soft-tokens offer something similar as one of three options: the user enters his PIN into the application, which is added to the generated tokencode to form the one-time password.

Both this and your scheme have the problem that an attacker that has gained access to the seed, and therefore can generate tokencodes, is able to compute the password (RSA method) or the password hash (your method) from a sniffed OTP.

Using HMAC(password, tokencode) as the OTP instead should make it much harder to compute the password. -- you need a preimage attack.

Soft-tokens

dlang — Mon, 27 Jan 2014 23:28:49 +0000

The solution that I've been advocating for several years is to have the key data be in a binary format where you cannot tell if what you have is valid or not, then take what the user types in as their PIN/password, run it through some hashing algorithm and XOR it with the stored data. If they type the wrong PIN/password, then the data recovered will be incorrect, but the soft-token has no way of knowing this until it attempts to use the result to talk to a live server. That server can detect the failure and take the appropriate lockout steps.

Soft-tokens

raven667 — Mon, 27 Jan 2014 20:00:21 +0000

It's always good to think about the risks in these different failure modes, in one case you have just a username/password in which all accounts are vulnerable if the password hashes are stolen, including other accounts which use the same password (with graduated risk depending on how strong the hash is) in another case you have a username/password+soft-token which raises the bar quite a bit higher, especially if it's harder to get the seed values (via compromise on the server or mass-compromise of the mobile devices) than it is to get password databases and having off-line tokens which raises the bar even higher (although the seed values can still be compromised, as people who's token seeds were in a spreadsheet at RSA found out).

You have to figure out what level of risk you are comfortable with given the sensitivity of the data. Even for banking soft-tokens might be perfectly fine (it may be possible to reverse fraudulent bank transfers sometimes, for example), maybe hard-tokens are only really needed when immediate loss of life or limb is a direct consequence of an authentication failure.

Soft-tokens

dlang — Mon, 27 Jan 2014 19:47:15 +0000

> It's not the physical attacks I worry about. It's mobile malware exfiltrating this data.

exactly, if you have a pin/password protecting your secret key, and the software on the device can tell if you gave it the correct thing, then the bad guy can get a copy of your app data (by doing a backup of your device, breaking into your online backup, mobile malware, etc) and then load the software on their own device (or simulator) and brute force the password. lockouts/etc won't help because they can just restore from backup again and keep trying.

hardware devices can't be cloned like this.

Soft-tokens

robbe — Mon, 27 Jan 2014 11:38:59 +0000

> But that is not the whole story; using one's Android phone as if it is a
> hardware crypto-token is a bit of a fudge regardless of the passcode-
> generation technique.
Security issues be damned, it's a trend that is not limited to the free offerings. Organisations using the market leader in this segment increasingly rely on these so-called soft-tokens as well¹. Users just don't see the need to carry another device, when they already have their smartphone on hand at all times.

Arguably a hardware dongle is more easily stolen, because people will notice a missing phone much faster.

It's not the physical attacks I worry about. It's mobile malware exfiltrating this data.

Footnote:
¹ Which I also see as a big problem for said vendor. Once all your users use soft-tokens, there's no need to stay with the proprietary solution.

ye olde library bundling

robbe — Mon, 27 Jan 2014 11:27:39 +0000

> [FreeOTP] does score some points over Google Authenticator by including
> the ZXing QR code–reading library within the app;

I thought we were largely against this kind of thing in these parts?

> Google requires downloading and installing a ZXing app separately.

Seems like the Right Thing to me. Once you have ZXing installed, you can also use it for other scanning needs. The bundled library does not give you that functioniality.

The apps that I saw, that needed ZXing were very polite and offered a streamlined process for download&install. The code that pops this up is actually part of the ZXing SDK, so I guess most apps would work in a similar way.

Authy

robbe — Mon, 27 Jan 2014 11:21:20 +0000

> From the little I've played with it, it seems to be HOTP using your mobile
> number as the HMAC input, [...]

That would be highly insecure! Everybody knowing your seed can impersonate you. That would be all your contacts in this case.

FreeOTP multi-factor authentication

robbe — Mon, 27 Jan 2014 11:17:08 +0000

Shouldn't a backup contain application data, including this database? You could either snarf it from there, or use that to restore after a fastboot-induced wipe.

That said, rooting a device on first arrival should really enter our minds as an issue of routine personal hygiene. You do wash newly-bought clothes before wearing them, do you?

FreeOTP multi-factor authentication

Kamilion — Sat, 25 Jan 2014 01:29:15 +0000

So I've had google authenticator on my phones for quite a number of years now.

I just signed up for coinbase recently, and ran across (read, was forced to download):
https://www.authy.com/

Which also seems to be a HOTP/TOTP android generator. From the little I've played with it, it seems to be HOTP using your mobile number as the HMAC input, but to be honest, I've only launched the app twice in two months.

However, they also suggested that you can migrate to it from google authenticator.

They seem to have a github here:
https://github.com/authy

But no sign of the serverside, just some API wrappers for various languages.

This one in specific seemed a little worrisome to me:
https://github.com/authy/authy-ssh

I think I'll stick with my yubikey.

FreeOTP multi-factor authentication

npmccallum — Thu, 23 Jan 2014 18:29:20 +0000

Nathan, thanks for the great write up!

Everyone, we welcome your testing, ideas, code and reviews! Please let us know if you experience any bugs and we will attempt to resolve them quickly.

FreeOTP multi-factor authentication

mathstuf — Thu, 23 Jan 2014 15:23:50 +0000

Hrm. I know there is "fastboot oem unlock" for my Galaxy Nexus to get root, but that clears data, defeating the purpose :( .

FreeOTP multi-factor authentication

hawk — Thu, 23 Jan 2014 11:52:43 +0000

The "Manually Extract Your Credentials" bit at the end of eg http://www.howtogeek.com/130755/how-to-move-your-google-a... is what I was thinking of.

(Essentially getting your hands on the file /data/data/com.google.android.apps.authenticator2/databases/databases in one way or another and then opening that with sqlite3.)

FreeOTP multi-factor authentication

djc — Thu, 23 Jan 2014 08:49:40 +0000

More detailed steps for this would be most welcome!

Transitioning Google 2FA to a new(ly installed) device has always been a bit of a PITA, so it'd be nice not to go through that again.

On the other hand, since I have the secret for my Persona IdP (https://bitbucket.org/djc/persona-totp) readily, available, I could easily enter that. FreeOTP (for Android) looks pretty good!

FreeOTP multi-factor authentication

hawk — Thu, 23 Jan 2014 08:44:47 +0000

Afaik there is no UI for getting at the actual codes out of the Google Authenticator application but at least on Android the data is in a SQLite database that you can get at if you have appropriate permissions.

FreeOTP multi-factor authentication

mathstuf — Thu, 23 Jan 2014 03:14:25 +0000

Bleh. Wish I had known this before adding GitHub and DropBox two-factor to the old app :( . I'd add FarceBook to the list, but they have yet to actually ask me to use a code >.> . Anyone know of a way to migrate without chasing down new codes (and invalidating the old ones)?