Hacker News Reader

Comment by tptacek | Hacker News Reader

You can have a security key on Google without a phone number, but you have to enroll with a phone number and then remove it. Google won't allow you to remove the phone number unless you have some other backup 2FA method available.

The best Google (actually: everywhere) 2FA "stack" in Q1 2017 is:

1. Hardware U2F

2. Software TOTP (Authenticator app on your phone)

3. Physically secured backup codes

4. Disabled SMS

My experience with the Y4 hardware and, particularly, software has not been great. I'm using the Y4 for SSH access (through ssh-compat mode on gpg-agent) and it's mostly OK, but if I try to use PIV mode on the same token I run into all sorts of problems. I'm bullish on U2F, but bearish on Unix token applications.

View on HN

I have a concern about software TOTP. As tptacek knows (but I'll mention as background for other readers), the various authenticator apps use the standardized TOTP algorithm [1]. This algorithm uses a private key that the server and the client (your phone) have in common.

The question is, where is the private key stored on your phone? According to some posts from 2012 or so [2], on Android, Google Authenticator stores the key unencrypted in an sqlite database, which you can look at if you have rooted your phone.

This seems insecure. Is this still an issue with Android? Are Apple products any better?

[1] https://en.wikipedia.org/wiki/Time-based_One-time_Password_A...

[2] https://www.howtogeek.com/130755/how-to-move-your-google-aut...

You should basically assume your TOTP secret on your phone is as secure, and no more secure, than any other piece of sensitive information on your phone. If you don't trust your phone, that's a good reason not to use your phone to generate TOTP secrets. For users like that, you can configure a Yubikey to function as a TOTP token (but it's a pain).

For me, I trust my phone more than any other piece of computing equipment I own. I also rarely unlock my password manager on it, so there's no one attack that gets you everything you need by hitting either my phone or my computer.

If I had a generic, non-Google Android phone, or any kind of rooted phone, the equation would be different for me.

> If I had a generic, non-Google Android phone

Yeah, that's me. So I have started experimenting with the Yubikey 4. (For those who don't already know: the Y4 keeps the private key somewhere in hardware, and never lets it out; the Y4 itself does the TOTP calculation onboard). The Windows desktop Yubico Authenticator (which talks to the Y4) is not too painful.

I'm curious, why do you trust your phone to have a session token for your Google account, but not the TOTP secret? In my view they are essentially equivalent.

Both allow effectively unfettered access to your Google account (with the exception of some account security changes, for which both require your password), both can be revoked from the web interface (arguably a TOTP secret is worse as it can create new session tokens but revoking it doesn't revoke tokens it created). Both can be stolen from unencrypted flash, and stealing either requires root (or privilege escalation, which is effectively root).

This whole "TOTP is weak, use yubikey" argument seems 100% about convenience, with a smattering of pseudo-security backing it up.

> smattering of pseudo-security

That's a good description of the state of my knowledge.

To answer your question: the Google account that my phone has access to doesn't have anything important, so I'm not worried about any related keys leaking. The TOTP secret would be for something more important, that the phone itself doesn't have access to.

In other words, I'm wondering whether a generic Android phone is safe to use as an over-sized hardware security token (or rather, as backup for a more convenient hardware token). It seems the answer is no.

> why do you trust your phone to have a session token for your Google account, but not the TOTP secret?

Why would you trust Google or anyone else with your work (bank, Github, whatever you use TOTP for) credentials? I can't understand how anyone would think it's "pseudo-security". As you rightly say, your credentials are in plain text on that phone.

If this is a concern you might take a look at storing the secrets with keepass and keepass2android. It will keep them encrypted and let you generate them through the app once you've entered everything in (and can be configured to lock everything down again immediately). There's still other possible attacks but it should at least be as secure as your password on your database while not in use.

The story for security on Android is really, really sad. Google should be pressing really hard on the secure enclave button. Even game consoles have better security [here I wanted to add: "... than the most secure Android device", but that would be untrue, since I don't know all the Android devices out there. Let's just say the situation is sad, verging on terrible because it's Google, full of smart people who almost certainly know better].

Google probably can't get away with just trusting TrustZone, given the number of manufacturers of SOCs and the opportunity for the folks doing chip-level cut-and-paste of features to get things wrong.

I imagine there are patents in the way. Solve that with the realization that a united front against adversaries (crackers, state-level actors) is better than a fragmented one.

Solve the technical issues by getting the right 20 engineers in a room for a week or two, to set a proper direction. Android could have great security in a large set of phones inside of 18-24 months, with the right management.

Sigh.

While I agree with you, they do in fact have hardware-backed key storage these days; it's just only available (and reliably useful) in recent Android versions (namely those devices with fingerprint sensors).

Since we're on the subject, OP was talking about a perceived vulnerability with rooted Android devices. I highly suspect that even a decent secure enclave solution would warrant some skepticism if the system around it is wide open. For example, timing attacks or even plotting voltage draw on an oscilloscope could leak some key information.

If you're rooting your device anyway, you should probably invest in a hardware security key.

Depends on where you live.

If you assume that the US government is not trustworthy, and a possible enemy of you (possible if you're a journalist in these days), then an unrooted phone might be less trustworthy than a rooted one with custom software (such as a custom build of CooperheadOS)

Or just use an iPhone. The amount of marketshare Apple would lose if there was even a hint of a US-intelligence backdoor in their systems keeps them with a very, very vested interest to actively fight that.

> Solve the technical issues by getting the right 20 engineers in a room for a week or two

Oh man, I haven't laughed that hard in a while.

What do you mean we cannot fix the human factor?

> Google Authenticator stores the key unencrypted in an sqlite database, which you can look at if you have rooted your phone.

Interesting, actually that's exactly the reason why I like the TOTP algorithm over other two factor mechanisms. I can see what my private keys are, I can back up them, and I can even copy them to other phones I maintain.

Some would tell me it's not good for security, but I'd like to manipulate them in the same way I manipulate my SSH keys. It's just so convenient. If they are moved to TrustZone or something I'd be massively upset.

> but I'd like to manipulate them in the same way I manipulate my SSH keys.

You don't have per-client SSH keys so that only one needs to be revoked if you lose control of a particular client? I bet the red team LOVES you.

Why are you backing TOTP keys up? I hear this all the time and it never makes sense to me. You have a backup: they're your backup codes. You use them to enroll the device you get to replace the one you lost. The whole point of TOTP keys is that there's one per device; the idea is to simulate bearer tokens.

(replying to a dead thread, I guess)

One issue: where/how to store the backup codes? Paper in a box in the bank? Not very convenient if you are traveling and lose your primary device. Paper in your wallet? Not very secure (and the probabilities of losing your wallet and losing your phone are correlated). Encrypted file on dropbox? I don't trust myself not to make a stupid mistake and leave an unencrypted copy in a "temporary" file somewhere.

TOTP key: load it onto 3 password-protected Y4 keys. Take two of them with you on your trip, and leave one in the bank. No way (without very expensive expertise) to extract the TOTP keys from the Y4, which also means that a user blunder won't expose the keys, and hopefully your Y4 password is strong enough to give you time to change the TOTP keys before anyone cracks a lost Y4.

Lots of vendors offer TOTP but not backup codes.

I don't use the Google Authenticator for this reason.

There are some Apps in the Playstore which make use of the Security Chip, if present which is the case for me, such that even if the phone were compromised with a rootkit the attacker would not be able to read the TOTP secret.

Can you list one or more of those apps?

com.mufri.authenticatorplus is the app I'm using, however it's not free, which is why I'm hesitant to freely recommend it.

eu.overmorrow.thenticate also offers this by description and a friend is using it for this, however I have no personal experience with that app.

Yubico has "Yubico Authenticator", a Google Authenticator lookalike where all the codes are stored on the YubiKey and accessed over NFC (you need an NFC YubiKey, of course).

If you use this, you can also generate TOTP codes on your computer using the yubioath Desktop application. It's quite neat.

For general purpose operating systems, you can PGP encrypt the secrets and pipe them to a TOTP cli program such as oathgen (I wrote oathgen as a PoC when I was evaluating 2fa options a few years ago). This way, you have confidence in how your secrets are stored and used.

    https://github.com/w8rbt/oathgen

I share your concerns about mobile apps and browser extensions that do TOTP. All the ones I've seen store the secrets in clear text.

For Apple it won't matter since apps are heavily sandboxed and can only pass eachother data through predefined APIs. Jailbroken phones are another can of worms though, since you're literally leaving open an exploit to run unsigned code.

Where does Google Prompt 2FA fit into that scale? I'm unclear if it's it's roughly equivalent to Hardware U2F, since you would need to compromise google's push service, and gain access to my phone in order to bypass. I currently use my Yubikey, but I like the idea of Google Push.

I know it's really asking a huge amount, but my 2FA wish-list for 2017 is:

  1. U2F in all browsers.
  2. U2F on all the services I consider important (Google, GitHub, Facebook, etc.)
  3. U2F setup on the above services without a phone number -- just force acceptance of the backup codes.
  4. U2F integration in SSH.

I'm currently using TOTP through Google Authenticator. Not great, but definitely a step up.

I think with the above in place I'd move to LastPass (from KeePassX), as the security of my passwords becomes much less important. Still not a huge fan of putting my vault in the cloud though.

Oh, and a fire-proof "safe" for my backup codes.

What sorts of problems do you run into? I tried to set up this exact thing (PIV mode) a few days ago, and apart from the fact that gpg-agent won't accept the SSH keys for the card (which can be worked around with a simple alias), things have been great.

Authenticator app gives me just 6 digits, it does not seem to be safe. I wonder how much resources attacker would need to compromise google account by brute force method.

(of course he would need to know my google account password)

Its near impossible. Not only would they need to brute force it, but they'd need to brute force it in the 30 second window available before the code rotates again.

How about TPM？

That would be up there with U2F. It's successor is the W3C Web Authn spec, Microsoft is shipping an early version of it where it integrates Windows Hello in the Edge browser: https://blogs.windows.com/msedgedev/2016/04/12/a-world-witho...

Reply on news.ycombinator.com