Hacker News Reader

Comment by nickik | Hacker News Reader

I think this is great, but its time has come and mostly passed in my opinion. The future belongs to FIDO UAF and U2F.

They are building a hole ecosystem with all kinds of capability and additional security that SQRL simply can not provide. Most important being anti-phishing protection. They are working on mechanism that would allow you to use the phone as a authenticator even when working on your desktop, this is part of the upcoming version of the standard.

They are already very popular and in a lot of hardware, they are working with w3c to standardize, part of the Web Authentication group.

Some people wrongly assume that UAF is only about but it could also be somebody entering a password or pin. The main attraction is that it allows for independent evolution of authenticaters without the server having to know or care (he can care if he likes). This will be a game changer.

View on HN

Uh excuse me?? SQRL provides excellent anti-phishing protection. There are no reusable credentials across domains, and the domain can be displayed on your authenticator.

https://www.grc.com/sqrl/phishing.htm

Cool, I did not see that.

However, the limitation are there, FIDO goes further.

Domain displayed is no real protection, actually its weakness is what drives phishing. But the link you provided contains some interesting info:

> How SQRL changes things

> When using SQRL, users do not identify and authenticate themselves with a username and password. Instead, their unique user identity is derived from their secret master key and the website's full domain name.

So that's similar to what U2F does - domain name (origin) is part of the protocol.

The bad side of U2F is that it looks like yet another push of treacherous computing acceptance. It has attestation certificates that end-user (both legal and physical token owner) isn't supposed to have any control over.

SQRL is much simpler and doesn't have that.

Seems to me the attestation certificates allow people who want to restrict the type of token to do that in a reliable way.

Let's say you are a bank, you want to use U2F or UAF. Some cheap 5$ U2F stick is not acceptable, you want to require some high quality stick from trustworthy people. Or maybe you even want to give your costumers costume sticks.

In UAF its even more important. You want to be able to reliable exclude Finger Print sensors or something like that.

It adds security and options. As long as the certification is not highly restricted I don't see it as a problem.

> You want to be able to reliable exclude

As a vendor - oh, yes, of course, I would absolutely enjoy as much control as possible.

As an end-user - nope, I want to decide on my trust vectors on my own. Even if I'm utterly delusional about my abilities to do so.

I just believe that a freedom to make a decision - even a terribly wrong one - is better than a secure lack of any. I don't want "trusted" authentication tokens to access sites from a "trusted" browser on a "trusted" OS to be displayed on a "trusted" monitor and so on[1]. Even if that makes world much more secure place.

________

[1] Yes, that sounds far-fetched and alarmist, but it's really all the same - end user is out of control and "their" hardware is attested for the sake of security. We're already knee-deep in there, please don't let it spread on more things, gradually gaining acceptance.

I just don't think banks and so on would adopt the technology otherwise. This system makes it possible to use the same protocol for super high security application where you require a UAF authenticater with its own keyboard and screen. A bank just be hacked because somebody used a sup-par authenticater.

The good thing is that while a bank can force you to use some specific device, they can not stop you from using that same device in other places.

Lagging behind, but I'm sure they will.

Here, banks used to implement proprietary measures. ActiveX or Java applets, custom encrypting HTTP proxies, nonsensical password policies and all other sorts of weirdness you can imagine. It's still not unheard of (because those institutions are extremely inert), but I'm absolutely sure the norm is shifting. Saner stuff gets adopted.

And until they don't - YMMV, but that's okay with me. Personally, I'm better with them lagging behind, rather than leading us to the "trusted" computing future. Security is important and nice, but not when it has adverse side effects.

I've wondered why Yubico is the only u2f device manufacturer that has released a root certificate which validates the attestation certificates that the keys provide - maybe it is to discourage their use so they can't be locked out reliably?

I am not familiar with Fido but I am looking at their website. It looks like a complex protocol for enterprises. Not some simple library available for many programming language and platforms, which any website can easily implement and add as an alternative or a substitute for login/password.

It might help the google, microsoft and bank of america of this world. But these are not the ones leaking our credentials (most often). It is the smaller websites who will not have the resources to go through some certifications or implement these protocols from scratch.

What is really missing is a common, free standard protocol, that can be easily adopted by a small website.

Is Fido trying to answer this use case?

The protocol is open, so you can create open source lib and server. You do not need to certify the open source libraries. There is already a lot of code out-there. The browser have to implement it as well, chrome does, others should follow soon.

See this example Java library: https://github.com/Yubico/java-u2flib-server

But in general they seem to be doing a very good job of forcing hardware to be standards complaint. They are putting quite a bit of effort into standards testing suites that you can use to validate your code as well.

A good thing about it is that on the server it only saves site-specific public keys, so small websites that get hacked leak important information.

Is FIDO something that I can use instead of implementing email+password register/validate_email/change_password/reset_password/change_email over and over again? Is it finally here, what Persona promised us?

No. FIDO 1.0 and FIDO 1.1 are more narrow in scope. This is not a federated login system. These are point-to-point authentication protocols that don't involve any third party.

It is a replacement specifically to replace password login and multiple second factor solutions. It will make it far easier to implement registration and authentication but not radically, you still have to do it.

It will also not replace your recovery flow. How to handle recovery is still up to you.

FIDO 2.0 will add some notion of tying together different authentications but still not solve the problem of federation (as far as I know).

For Federation OpenId Connect is still the best, if not optimal solution.

I don't know what kind of future you're talking about. U2F gained 0 adoption and are doomed. What did they expect with $19 sticks that require USB?

First of all, Fido is not just U2F. UAF the more important in the long term.

Second, U2F is not about USB sticks only. It is a protocol that works over NFC or Bluetooth. Soon it will also be possible to use your phone as a U2F authenticator for your laptop.

Third, how is it not adoption when Facebook, Github, Dropbox, Google and many others have added it.

Forth, a lot of hardware already has support built in. Lenovo laptops, Samsung phones and so on. Android has added an API. The new Snapdragon chips have it implemented on a very low level that will allow key storage in a secure enclave with dedicated transport to the finger print reader for example.

Five, where are you getting this 19$? You can get sticks for as low as 5$.

When is the last time authentication technology has been adopted like that? I would think never.

Google has published a paper about their experience, https://www.yubico.com/2016/02/use-of-fido-u2f-security-keys...

>Third, how is it not adoption when Facebook, Github, Dropbox, Google and many others have added it.

adding != users are using it (they don't)

19 is price for yubikey, maybe some do for 5, it doesn't matter because it should be 0 and no hardware costs that. Making auth layer for general public as hardware is a mistake #1.

>When is the last time authentication technology has been adopted like that? I would think never.

Facebook Connect. Hell of a success. It's centralized, though (and we made decentralized securelogin.pw)

Google says some of their 50k employers are happy with experience. That's it, has nothing to do with users of Google.

> adding != users are using it (they don't)

I use it. My company uses it for Google GSuite (mandatory). I know many people who use it.

Also, this is pretty new stuff, of course its not used by everybody yet. The Spec has not been finalized for very long. U2F has actually shown very good growth. It has been adopted in some mainstream browsers and Firefox will have it soon as well.

Adding a completely new authentication layer to the hole web is a monster task. No solution will solve all problems in a couple years only.

> 19 is price for yubikey, maybe some do for 5, it doesn't matter because it should be 0 and no hardware costs that. Making auth layer for general public as hardware is a mistake #1.

Again, much future hardware will just have it built in. You have a smartphone anyway, why not use it as a second factor? Your wearable could be your U2F device. That's also U2F. U2F is a protocol, not a hardware stick.

Also, you don't need hardware. You can use software implementations if the server allows that.

> Facebook Connect.

That's federation layer and you can use U2F to make it saver for you.

I'd rather recommend people use google auth/facebook connect than go through u2f hassle. It's way too inconvenient and will never go mainstream. Did they figure out usable backups yet? Or they still recommend to just buy another stick?

Your backups are the generated Authenticator backup codes. Most services give you anywhere between 5 and 10 of these, giving you 5 to 10 chances to log in without your stick. That's plenty of leeway.

No reason not to just revoke the old factor and buy a new one.

The problem with this is the backup codes are different for each service. With one service, I can keep a backup card in my wallet, another in my house, and another at somebody else's house in a different city, giving me very high assurance of availability in the event of token loss or destruction. I can't maintain that level of backup for every service I sign up for.

Even multiple tokens isn't a good solution for lots of services, since you need possession of the token to enroll.

Its a point-to-point protocol. Its not a login and recovery flow. Its designed to be integrated in what people are already using as a direct replacement for other 2 factors, so it can be widely adopted instead of forcing everybody to something completely new.

Once this is established the hope to push the envelope further with future versions.

That's the reason this stuff gets adopted. Everybody understand that these issues still exist. Nobody believes that FIDO 1.0 is the solution for all problems that exist in auth.

I for one much rather buy two U2F sticks, then entering that stupid TOTP token one more time.

"Factor" is a marketing word. There is security threat model, and there are no "factors". u2f introduces another layer instead of fixing first one. That's why they failed - all we needed is a password replacement, not code generator on top of that.

Ok. So lets explain this ELI5-style.

Currently people use passwords then add TOTP to increase security.

FIDO wants to improve the situation so they introduce UAF to replace passwords, and they replace U2F to replace TOPT.

What exactly is your problem? They did exactly what you wanted, they invented UAF to improve on the first factor. For high security application you can add a second factor. Are you arguing there is never a case for a second factor?

I really don't understand your issues.

> so they introduce UAF to replace passwords

Oh, how is it going? Is there any UAF supporting app, ie no passwords? All I see is slides and presentations.

> Are you arguing there is never a case for a second factor

Correct, once first layer is fixed and password-related attacks are mitigated, there's no need for u2f as it doesn't stop malware.

Even something as basic as hmac(masterpw, domain)-app would do better job than FIDO stuff altogether.

Replacing passwords is incredibly difficult. Nobody has done it, many have tried. UAF is already supported in a wide number of hardware and applications.

You can verify PayPal transaction right now with UAF. Not exactly a small fish.

UAF does not jet have much browser support yet, everybody is waiting for Web Authentication API that is in standardization right now.

> Correct, once first layer is fixed and password-related attacks are mitigated, there's no need for u2f as it doesn't stop malware.

That's just stupid. If you use a finger print sensor as a convenient first factor then you might as well still want a second factor.

The idea that there is never a use for a second factor is just total nonsense.

> Even something as basic as hmac(masterpw, domain)-app would do better job than FIDO stuff altogether.

The security of that would be far, far worse. Not to mention tons of other practical problem with that idea.

> If you use a finger print sensor as a convenient first factor then you might as well still want a second factor.

You keep talking about factors, which is just a word, not a technical term. I repeat: you do not need u2f with fixed first layer. No plausible threat model. Malware attack gets delayed, not prevented. If you decide to reply please define word "factor".

The use of the term 'factor' is pretty established in any security discussion and I have heard the word mentioned in lots and lots of presentations on security conferences. So it seems to be you that has some sort of strange hang up about this.

U2F is designed to add additional security by you having to prove that you physically own something.

> you do not need u2f with fixed first layer

Again, that why there is UAF, it has nothing directly to do with U2F. In UAF you have to somehow (bio or knowledge) prove that you are who you are.

In high security application you might want to both have local authentication (UAF) and additionally prove of possession (U2F).

> Malware attack gets delayed, not prevented.

Of course it helps. If you use your laptops fingerprint reader as a first factor, somebody steals your laptop, gets the fingerprints from it, he will still not be able to access your online accounts because they need U2F.

If its a website that uses password and you get phished this will be completely useless if they don't have access to your U2F authenticater.

There's no established meaning of factor. I have trouble understanding UAF goals. We already have full disk encryption + pincodes on laptops and phones. Consider it "first factor" then? If laptop is stolen you cannot get in (see San Bernardino attacks). Yes, everyone must have it "on".

So we are left with attacks that control your computer once you unlock it. Malware. And with malware we can exploit your computer right now (no "second factor") or few days later (wait for you pressing that USB button). My point being these both cases are giving same security, but second one is much worse usability.

>If its a website that uses password and you get phished this will be completely useless if they don't have access to your U2F authenticater.

Pre-condition to this discussion is that "first factor" is not a password but some kind of client certificate, i.e. phishing and reuse is not in question. Then we are looking at what U2F offers us: horrible user experience with most browsers+devices not supporting it for the sake of just delayed exploitation? Thanks, no.

Just the other day I wrote an Oauth login feature in Go for fun. Facebook banned my account three days later for "suspicious" activity. Twitter banned my account in 48 seconds - I didn't even have a chance to setup an Oauth token. That right there shows the problem with being reliant on a 3rd party for access to your site, what if the 3rd party refuses to work with you? Suddenly your cut off from a percentage of your users. (It wasn't all bad, setting up Amazon login was quick and painless and they didn't ban my account!)

I do wish more sites allowed TOTP (Google Auth) because it works well and avoids the third party dependency, but I'd be happiest if sites would just stopped disabling paste so I can use strong passwords with my password manager. (Synchrony Bank, I'm looking at you and all your dozens of co-branded web sites)

currently, gauth connect is best option for general public. It's a fact, they are popular and have no passwords

I'm surprised they haven't gained wider adoption, their competitors charge yearly fees for their tokens, and in many cases you become dependent on their infrastructure to use them. U2F is a one time investment as long as the token isn't damaged, and your not beholden to Yubico in the slightest. I've got a box of RSA tokens from former jobs. E*Trade still gives out some token with a LCD display for $20 a year as their sole 2nd factor option.

because selling overpriced plastic sticks is a lucrative business which has nothing to do with security or threat models at all. It's just marketing

Reply on news.ycombinator.com