Hacker News Reader

Yubico Authenticator is a fork of Google Authenticator and is a drop-in replacement.

I have never had any problem helping someone that has used google authenticator set this up. Scan barcode and tap.

Also users have a much easier time when they get a new phone. Just tap to new phone and get codes. There is no data to transfer.

As for people getting locked out, that is what the printable backup codes are for, or a secondary key, depending on your threat profile.

In a corporate setting this is a non-issue as an admin can bail you out.

That's a desktop TOTP application. Now not only do they have to have their computer with them to log into their Google account from their phone, but they have to have 2 security keys on the account to remove their phone number from it, and all their backups are physically separated from them, so unless they bring their backup codes with them when they travel, if they lose their key, they're boned.

And all this for what real additional security?

If you want to nerd out and get your security key to do pet tricks like handling your TOTP secrets, I do not have a problem with that. But please don't tell ordinary users they're wrong when they don't do that.

I have Yubico Authenticator installed on my phone and my desktops/laptops.

The android app is a direct fork of google authenticator and has nearly identical UX.

I tap/plug my key to either of them to get a token.

If you want to make the argument TOTP via hardware token is overkill for most users, that is totally fair. On that note though, there is no point in having hardware token via U2F.

Security is ahout the weakest links. All I am saying is anyone going through the trouble to set up U2F as this guide suggests, might as well spend the extra 10 seconds to store their TOTP secret on the key as well, vs exposing it on the phone.

I assume someone that has a hardware token is getting it for a reason: To have assurances an attacker can't log in as them without that token.

You keep saying that, and it keeps being false. The point of U2F isn't to put your secrets in super-secure hardware so you can walk around feeling like you have an HSM hanging from your keychain like a bad-ass. The point of U2F is to defeat phishing attacks, which is how people actually get compromised.

It would not be much of a stretch to say that this U2F guide was written deliberately as a corrective to this mindset.

I disagree with regards to your risk analysis.

Your cost/benefit considerations prioritize relatively miniscule security improvements without considering usability costs or diminishing returns. While we're at it, why don't we just use one-time pads? After all, those are impervious to any form of cryptanalysis.

The risk profile for most users does not require a hardware-based auth factor if it results in real world usability sacrifices that end in either 1) accidental misuse or 2) gradual disuse.

You're optimizing for someone compromising the device, great. But the point is that if that risk if on the table, all of this work is essentially meaningless anyway.

"if that risk if on the table, all of this work is essentially meaningless anyway"

I can't agree with this strongly enough. If someone's willing and able to hack your iPhone, then you need more help than a random art major writing a yubikey howto can give you.

Just an offshoot thought, but some random art major writing one of these guides giving a bird's eye overview of the entire process is something most businesses should be able to do themselves. But they don't.

I am only focusing on this bit because it is a few extra seconds of work if you are going to have a hardware token anyway. Why expose your TOTP secret if you don't have to?

I like knowing that if the phones and laptops of someone on my team were compromised, we have some damage control.

With the approach Yubico Authenticator takes an attacker with remote access to your Android Phone and a keylogger on your laptop still can't log in as you remotely.

Granted with more effort that combo can burn you in other ways, but TOTP on a hardware token still gives you some very real reduction in attack surface with no real added user burden. Why not?

Three people have answered that for you, and you keep ignoring them. We're protecting Google accounts, not TOTP secrets. We all understand that you can keep a TOTP secret more secure than a Google account. But since nobody cares about the security of a TOTP secret for a compromised Google account, I'm not sure why we're still talking about this.

Yes but you didn't address the main rebuttal, which is that encrypting or not encrypting the TOTP store is a red herring. If someone has access to the filesystem they can likely walk around the issue of encryption, just as they would on a desktop computer. And if they control execution, encrypting the data becomes utterly moot (and I'd argue most cases of someone gaining filesystem access where the individual cares enough to have 2fa are going to be a jailbroken device, which results in complete debugging and reversing capability, which makes this redundant).

This is not the thing to optimize for. Yes, optimize for ease of use, because take PGP as an example of great security vs horrid usability and look where that's got us. If you do the security improvement analysis from a cost/benefit perspective, you do not win by using a hardware key over regular 2fa apps. Users will shoot themselves in the foot, or simply not use it.

I guess I didn't understnd that bit. It sounds like there is som mistunderstanding about how Yubico authenticator works?

It does not store the secrets on the disk/memory of the phone/laptop at all. It just sends over a code. The device only sees one code and nothing else.

This is also why a user can get a new phone and and just tap the key to the new phone and truck on. Magic.

When a user drops their Google Authenticator phone in the toilet however... bad day.

No, I'm pretty clear about how Yubikey TOTP works. The point is that the threat model doesn't make sense. Any device you can use Yubikey TOTP on is significantly less secure than your iPhone.

Yes, I'm clear that the attacker in this scenario doesn't get your TOTP secrets. If your primary goal is to protect your TOTP secret, I see your point. My problem is, my goal is to protect my actual account. I kind of don't give a shit about my TOTP secret, because Google will give me as many new TOTP secrets as I ask it for, but I only have the one account. If the device I'm securely generating a TOTP secret for is compromised, I'm going to feel pretty silly doing a security theater dance with my Yubikey as my attacker steals my cookie and locks me out of my Google account.

Cookie theft is for sure a real issue. In the case of Google, if your cookie suddenly pops up in another country, it will often be quickly terminated.

Not all services do this, and Google does no do it all the time either.

Still, I see no reason not to take the super easy low-hanging fruit to reduce attack surface when you can.

Don't be evasive. It doesn't matter how you secure the channel, with cookies or magic beans: if the attacker controls the device you're using Google Mail from, they've compromised the account. What's the point of having a super secure key to a house with a wide-open hole in the side of it? There is no point, is the answer.

They may of compromised gmail, because gmail is logged in. They however won't get to the other 20 services that I have not recently logged into recently on the device that also use hardware tokens. They don't get the totp secret for my AWS account which I only log into from that device in emrgencies. Etc.

If someone gets remote access to your device it is a very bad day, but you -can- have damage control and a clear picture of what they had access to and what they did not.

If the attacker roots your phone and it has your unlocked password manager on it and google authenticator with all the 2fa secrets... well now they get the entire farm, including for services you don't have active cookies for.

Hardware tokens are not magic, but they are a very useful tool and if we combine enough tools we make the life of an attacker that much harder.

And then there is the recent story of someone getting private emails/password resets/paypal info sent because Gmail ignores the dot in their email address... https://news.ycombinator.com/item?id=14140569 - which makes one wonder if that's already an attack angle being used.

No, I understand that.

Let me simplify my point: Whether or not the TOTP secret is on the smartphone, encrypted or not, or sent to it from another device, is the wrong attack vector to optimize for.

Getting mainstream users en masse to consistently and correctly use any 2fa is a win.

Furthermore, you're moving the goalposts a bit by using the Yubikey in this scenario. So sure, if someone compromises your phone they don't compromise the Yubikey, but 1) how certain are you that your Yubikey is safer than a modern iPhone or Android model with the crypto and security engineering that entails and 2) how certain are you that accessing your iPhone's filesystem or execution state does not bypass this whole dance entirely?

For you, the minimal security gains might outweigh the usability costs if you know what you're doing. But a hardware token for most people, as the technology currently stands?

The device keeps the secret in self contained memory and never exposes it. It is on the other side of a USB bus or in some cases NFC. There have been local attacks against old designs via side channel attacks etc, but never once a remote attack. The model makes that pretty hard. The phone is essentially zero knowledge. Android and iOS allow arbitrary execution of user installed code and are a massive attack surface and have piles of pubished vulnerabilities.

By moving secrets to very simple easy to reason about devices we get substantial reduction in attack surface.

Also I have helped deploy these to several dozen people, taught workshops etc. It is no harder than teaching people to use Google Authenticator, but lower attack surface.

Use U2F where you can and when you must fall back to TOTP at least you can promise an attacker does not get a free pass to genreate codes whenever they want which is something.

Getting mainstream users to use 2FA? Is that like getting them not to use overly simple PWs? Or not use open wifi? Those people?make Not sound like an ahole but...How's that working out for ya?

I think ya might be able to argue that if you're going to add friction (e.g., Yubikey) you're also creating a great senses of seriousness. That sense of seriousness is seriously lacking.

All that said, the UN + PW idea is too weak. We need something that's up to the threat AND is also appropriate to the risk of loss. Best I can tell, as a general mainstream rule, we're not even close to that. It's 2017? Really?

  The attacker who gets access to the filesystem of your
  phone can almost certainly defeat any "encryption" a TOTP
  authenticator would use to protect secrets

Is Android's hardware-backed keystore no good? The documentation makes it sound like keys can't be extracted or used without user authentication.

It doesn't matter how good it is, because once the application is used, the (now-resident) attacker gets the (now-unlocked) secrets.

Who are the we in your post?

Clicking on his name [1] you can see he works at Latacora now [1]. Hopefully that helps answer your question

[1] https://news.ycombinator.com/user?id=tptacek [2] https://latacora.com/