Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

That's not how 2FA works

shkspr.mobi

Post reply on HN
Print view View original

251–260 of 269 posts

Re: That's not how 2FA works

#251

Post by BlackFly »

snarf21 wrote: post #222
mapgrep wrote: post #217

All the complaints made about yubikey and webauthn could be made about 2fa 5-10 years ago. Hardware tokens gated by software (ala yubikey + webauthn) are clearly the next step in auth. It’s an accident of circumstance you even need to buy a yubikey - your iPhone, iPad, laptop, android whatever can do everything a yubikey does. There just needs to be enough demand and time for OS and hardware vendors to come around to…

Yeah. It is mostly about integrating and standards. Private keys in the secure enclave already does everything Yubikey does. All phones already have it. The OSes just need to support FIDO and then we don't need passwords anymore (assuming a passcode lock on device). Essentially everyone would have 3FA (something you know, something you have and something you are)

Secure enclaves as a second factor break the assumptions of 2FA threat models. If I compromise a single factor (your device) then I can gain both your password and your second factor.

The best second factors are separate devices with their own screens that indicate what you are authenticating to/for before you provide your authentication.

Of course, nothing ever stops a user from deputizing malware.

Re: That's not how 2FA works

#252

Post by red_admiral »

FIDO is a subset of 2FA, and it's one of the protocols that yubikeys etc. implement. While it won't protect you from all attacks, it does make the standard MITM harder.

To take the OP's example, if by mistake you are tricked into visting githud.com or something, they can get your password (bad!) but if they try and MITM the FIDO, they'll send a digitally signed message for githud.com on to github.com. This will not work as intended (except for the user, because their github account isn't compromised yet.)

Indeed the point of FIDO as I see it is that it's less security critical for the end user to validate the identity of the site, which optimistically speaking about 95% of users will fail at anyway.

Re: That's not how 2FA works

#253

Post by snarf21 »

BlackFly wrote: post #251
snarf21 wrote: post #222

Earlier quoted context omitted.

Yeah. It is mostly about integrating and standards. Private keys in the secure enclave already does everything Yubikey does. All phones already have it. The OSes just need to support FIDO and then we don't need passwords anymore (assuming a passcode lock on device). Essentially everyone would have 3FA (something you know, something you have and something you are)

Secure enclaves as a second factor break the assumptions of 2FA threat models. If I compromise a single factor (your device) then I can gain both your password and your second factor. The best second factors are separate devices with their own screens that indicate what you are authenticating to/for before you provide your authentication. Of course, nothing ever stops a user from deputizing malware.

I guess I'm not seeing the difference between the secure enclave in a phone and the secure chip in a Yubikey in regards to threat models.

Re: That's not how 2FA works

#254

Post by dane-pgp »

md_ wrote: post #245
dane-pgp wrote: post #79

Earlier quoted context omitted.

> Krypton is built on top of an end-to-end verified and encrypted architecture. This means zero trust. We, Krypt.co, cannot access your keys or see where you're authenticating. The keys only live in the Krypton app on your phone. Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero t…

Sure, I agree that RPs should not use attestation in most cases. (Enterprise use—where the company has issued specific hardware to clients—is an obvious exception.) Vanguard, for example, only trusts Yubico keys, and it's a pain in the ass. That said, your complaint about Secure Enclave/Keystore trust doesn't make sense to me. Is there an architecture with on-device authenticators where you don't have to trust the de…

> Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no?

I was trying to draw a distinction between the OS (which could in principal be built from a trusted set of source code) and the firmware controlling the tamper-proof SE/Keystore.

In the case where the SE/Keystore is controlled by something like the Intel Management Engine, that distinction might be meaningful, but you're probably right that in general if you don't trust the device manufacturer then it doesn't matter how the SE/Keystore is implemented or managed.

Moreover, I suppose if you trust the OS to be doing what it's supposed to, the only things a malicious SE/Keystore can do are cause a denial of service or fail to keep your secrets (in the worst case by broadcasting them with a hidden antenna).

Re: That's not how 2FA works

#255

Post by chaz6 »

dathinab wrote: post #149
8ytecoder wrote: post #140

Earlier quoted context omitted.

How many websites allow U2F as the only 2FA? Every website I tied it wanted a backup authentication app added.

Normally you can create backup hardware recovery keys (or alternate fallback 2F). (EDIT: Keys as in e.g. alphanumeric on time use tokens lie "23430240392") This is necessary as you would else wise be permanently be locked out if you lose your U2F key. That is assuming you can't reset your U2F key using mail password recovery. But your mail being a single point of failure is something U2F normally tries to prevent. Th…

I have 4 keys which are stored safely. I do not want a fallback mechanism because that reduces the security of my account. The downside is I have to manage my keys on each site separately. It is a shame that the original OpenID never stuck around as I could have just had one secure account, without having to be part of the current ID provider cabal.

Re: That's not how 2FA works

#256

Post by als0 »

> WebAuthn and hardware tokens are probably the future. And they’re probably the best way we have to verify site legitimacy. But they’re also currently a poorly supported usability disaster.

I was looking for the punchline but it seems like there isn't one. Complaining about hardware tokens and then saying they are the future doesn't contribute much...

Re: That's not how 2FA works

#257

Post by md_ »

dane-pgp wrote: post #254
md_ wrote: post #245

Earlier quoted context omitted.

Sure, I agree that RPs should not use attestation in most cases. (Enterprise use—where the company has issued specific hardware to clients—is an obvious exception.) Vanguard, for example, only trusts Yubico keys, and it's a pain in the ass. That said, your complaint about Secure Enclave/Keystore trust doesn't make sense to me. Is there an architecture with on-device authenticators where you don't have to trust the de…

> Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no? I was trying to draw a distinction between the OS (which could in principal be built from a trusted set of source code) and the firmware controlling the tamper-proof SE/Keystore. In the case where the SE/Keystore is controlled by something like the Intel Man…

Oh, I get your point.

I mean, in the extreme, yeah, malicious hardware can exfiltrate secrets. A hidden antenna, as you say—or more subtle attacks (e.g. https://dl.acm.org/doi/10.5555/1267336.1267341, though this would require more than just the Secure Enclave to be malicious).

But yeah, I think for the ordinary consumer this is not a useful distinction. For vendors who are thinking about supply chain attacks, for sure this is a real consideration.

Re: That's not how 2FA works

#258

Post by gnufx »

bsder wrote: post #185
gnufx wrote: post #100

Earlier quoted context omitted.

I don't think the kickstarter is relevant now. You just buy them from solokeys.com. There's been Somu since that, and Solo2 is in the offing, with plenty of storage, apparently. I bought Somu partly for convenience, and partly for the promise of PGP support, which unfortunately hasn't been added yet (though there is a development version). In answer to the expense question, two Solo keys appear to set you back 38 qui…

> I bought Somu partly for convenience, and partly for the promise of PGP support, which unfortunately hasn't been added yet (though there is a development version). It is sad that with PGP being so horribly broken, it still casts its shadow over security products. PGP should have been dead and buried eons ago.

> It is sad that with PGP being so horribly broken, it still casts its shadow over security products.

How is ssh with a PGP key horribly broken? There's no shadow over Solo/Somu from where I'm standing.

Re: That's not how 2FA works

#259

Post by chris37879 »

paranoidrobot wrote: post #249
dathinab wrote: post #146

Earlier quoted context omitted.

Not all 2nd Factor solutions allow stealing the 2nd factor. Mainly U2F incorporates the domain and (should) only work if an TLS connection with a valid certificate for given domain is used. Furthermore it uses a key exchange. This means: - The attacker needs a valid certificate for the applications login domain, which wrt. web security is normally assumed to not be possible but tbh. might be possible in case of an st…

U2F is so infrequently used on public sites compared to SMS and TOTP. Of the things I use regularly, that arn't for work, that have a 2FA option - I think two (Google, and my password manager) supports U2F. For either of those methods, stealing two SMS/TOTP codes isn't that much harder than stealing the first one - you just display a fake error saying that it failed, and try again. For all but the most attentive folk…

Yeah, I really wish more things worked with U2F. I especially hate when I enable U2F on a site it works on (Twitter) and then every time I log in it does an sms code anyway, even though I have U2F enabled and would much prefer to use it, but like having my phone number as a recovery backup.

Re: That's not how 2FA works

#260

Post by chris37879 »

girvo wrote: post #221
dmurray wrote: post #214

Earlier quoted context omitted.

The article's first and most prominent criticism is that it costs at least $30-$60, which might be a barrier to mass adoption but for most HN readers is not a serious reason not to use it.

I own two (one as a backup in my safe in case I lose this one. They all have the same TOTP stuff and setup in every service side by side where possible), to agree with you. Though it’ll be lovely when your iPhone can be a U2F key through their hardware security chips and some OS support, if I’m dreaming out loud.

I do like phones are building in these keys, it makes them way more accessible to the general population, and generally not a pain to use. And then those of us with physical keys get better support too :)
Post reply on HN