Hacker News new | comments | show | ask | jobs | submit login
Why Johnny Doesn’t Use Two Factor – A Study of the FIDO U2F Security Key [pdf] (ifca.ai)
49 points by eaguyhn 3 days ago | hide | past | web | favorite | 44 comments

Why I‘m using my three or four U2F keys rarely: almost nobody supports them.

Yeah, Google, GitHub, Facebook.

But my bank doesn‘t. My insurance companies don‘t. My broker doesn‘t. It‘s all very sad.

> But my bank doesn‘t. My insurance companies don‘t. My broker doesn‘t. It‘s all very sad.

Disappointingly, my (former) bank, insurance, and broker companies only supported "2"FA via SMS, which is even worse--in my opinion--than not supporting anything at all because it gives a false sense of security. My bank and my mobile phone provider would both allow me to completely reset my credentials using solely a verification via SMS, so anyone who hijacked my phone number could steal from me.

Even more obnoxiously, lots of businesses don't accept "VoIP" SMS numbers because they are deemed "insecure," even though my VoIP numbers are hardened behind much better account security than anything my mobile provider offers.

Recently I tried adding U2F support to my chat bot. It was so complicated and I couldn’t find comprehensive documentation for it so I gave up.

Admittedly, the chat bot is a hobby project so I was only looking for a couple of weeks in my spare time, maybe I “looked wrong” but everything I found was focusing on clients and rarely on servers.

The MDN docs look adequate to me.

You do need to go into this either understanding what's actually going on or open to just being told what to do rather than trying to plug it into a model you have from, say, using password authentication.

Your code (typically JavaScript) running on the client is going to feed input from your server (getting it to the client is your problem, inline it in the HTML, read it from a WebSocket, whatever) into this API and get back a result. The result needs to go to server - again how you do this is up to you. The server verifies stuff, I guess that could be handled in a library or something, and then you've authenticated the user, done, set a session cookie or whatever.

My broker does! Vanguard supports U2F, though weirdly only with Yubikeys.

Vanguard requires you to enable fallback SMS 2FA before you can enable U2F, which results in a net decrease, rather than increase, in account security.

How does an insecure second factor affect the security of the original factor?

EDIT: apparently the OP meant SMS password reset without requiring the second factor, not SMS 2FA. Of course that's terrible.

> How does an insecure second factor affect the security of the original factor?

If I want to compromise your account, I force fallback and then compromise your SMS. Security is as strong as the weakest link.

I understand that it could reduce your security to the level of one-factor authentication. That's really easy to do. It is not reducing the security below what one-factor authentication provides, like the OP argued it did.

I compromise your SMS. I initiate password recovery, and tell Vanguard "I forgot my password -- but look! It's still me! I can receive SMS challenges!"

That's a SMS password reset mechanism, e.g. one-factor authentication, not two-factor authentication.

That's my point. Adding an SMS number to your account reduces the security of your account to one-factor SMS authentication.

The point here is that if you cannot remove the much lower sms sec then it's no more secure than sms only

How does a wooden screen door on the back of your bank vault affect the security of the vault door?

That analogy doesn't make sense.

It's more like you have a deadbolt and a regular lock. Sure, you can open the regular lock with just a credit card, but that doesn't help you with the deadbolt...

No, because in your scenario, you have to get through the deadbolt AND the regular lock. In the Vanguard scenario, you have to get through the deadbolt OR the regular lock.

That's not what the OP said originally. It's a bit disappointing that people are dispensing security advice without understanding the difference between password reset mechanisms and 2FA mechanisms. :-(

Oops, I see, sorry, you're totally right.

Yeah, I bring this up to them roughly once a year. It's crazy that they don't allow you to disable SMS.

Same problem I had. I got a bunch of keys, and everything I actually want to U2F does not support it.

Sure - Google, Github, Fastmail. But nothing financial. Not even the more startupy stuff like TransferWise and Revolut. Fastmail forced me to enable SMS 2FA to use U2F, which I suspect is actually worse than not using 2FA.

Also, a inherent problem: I would really like to keep a backup key in a galaxy far, far away in case my house catches fire, but I cannot enable a key if I do not have it at hand.

You can disable SMS on Fastmail after you enable 2FA. I had asked their support, and IIRC the trick is to hold down CTRL when you're on the settings page, which will enable the "Disable SMS" option.

This was years ago, so YMMV.

That's the craziest thing ive ever heard, Easter egg to disable bad security options. What is this a video game?

You wouldn't be surprised if you saw the amount of people that said "hey can you remove my 2FA? I kept my codes on my phone and it broke".

It's a real UX issue, the average person just can't back up their TOTP codes at all. Hell, I have a Yubikey as a backup and enroll the TOTP code to both places, and to the Yubikey as U2F.

FWIW I now checked and I could remove SMS without tricks. It definitely forced me to set that up first.

Ah, good. It does force you to set up SMS, but, when I tried, I had to contact support to disable it without disabling 2FA completely.

Title (original from TFA) is very misleading. The study is too late in the process of setting up 2FA. No one in the study was motivated to set up 2FA in the first place. This is "merely" a UX study that benefits Yubico. It doesn't address (at all) why people do or do not want 2FA in the first place.

To use my own insight: regular joe does not want to buy an expensive product and install some hardware. (the "cheap" $20 ones are literally worse than useless. but even $20 is too much.) 2FA's future is in touchID (integrated into touch bar on mac) and push to a phone app. The latency of push to a phone app is more acceptable than the confusion and vagary around adding an expensive usb key that you don't understand and then doesn't work on your mobile anyway.

> the "cheap" $20 ones are literally worse than useless.

How so?

> 2FA's future is in touchID (integrated into touch bar on mac) and push to a phone app.

As another person pointed out, this is quite literally what krypt.co's Krypton app does and it integrates with existing U2F/FIDO standards so either a hard or soft device can be used.

I find that quote odd too. I find the $10 USB-only ones useful, I just wish they had dual normal/micro USB like some flash sticks.

I don't want Bluetooth, NFC or software u2f devices for security reasons, but I also think they could each have additional support problems if given to family members.

The ideal option for me would be an applet on a smartcard in my phone's 2nd sim bay and a hard power toggle for the 2nd bay. Then I suppose my phone could also provide proxying of u2f as a USB device.

But last I looked Android was blocking access to simcard slots for general purpose..

Krypt.co looks pretty nice, I have a Yubikey and andOTP but I hate either getting up to fetch the hardware key or fumbling about for the right TOTP code, so the soft-approve by Krypton looks like the most convenient option, and reasonably secure, to boot.

"then doesn't work on your mobile anyway." The yubikey neo works perfectly on your mobile, as long as it has NFC support.

i'm sure the neo is flying off the shelves at $50 ...

it's awkward enough for desktop use that push to mobile is a superior UX

U2F through the yubikey doesn’t work on iOS devices because iOS NFC is only 1-way outside of Apple Pay.

I hate private APIs. There ought to be a law that vendors can only use public APIs.

So Apple is out, right?

What? iPhone 6s and newer supports NFC.

6s supports NFC for EMV only. 8 and newer has generic NFC support.


The "generic NFC" support you refer to is read only which means that protocols like U2F still don't work so usability of U2F for iPhone users is still not there (without bluetooth keys which have their own problems).

The neo NFC works with iPhones 7 and above

Only for Apple Pay, which is another reason Apple are disingenuous when it comes to security.

Sadly my Xiaomi device doesn't..

What about krypt.co ?

This article is good as far as UX goes. Myself, I love my Yubikey. I use it to store my ssh keys, then tunnel them using ssh-agent/gpg-agent, something along the lines of this article. https://www.bootc.net/archives/2013/06/09/my-perfect-gnupg-s... and this article https://wiki.gnupg.org/AgentForwarding. It's set up so that you have to have the key to get into the bastion host first, then you have to tunnel your key through the bastion to get to the other side. If you remove the key it breaks your connection. A good way to ssh w/out having your private keys sitting on a disk.

A usability study prsented in a pdf that is quite difficult to read on mobile. Funny.

Johnny does not want to use a physical FIDO U2F security key, because he regularly loses his phone and regular keys, and does not like to think about losing his entire digital life because he mislaid this FIDO U2F key.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact