Slashdot Mirror

Here's the standard, as you can see it requires user interaction before authentication can take place:

https://fidoalliance.org/specs...

I have a lot of respect for DJB. And he's pointed out theoretical attacks, and a few points where it's easy to make implementation mistakes when developing crypto code. The thing with theoretical attacks is that they seldom are practical. Most of the issues he brings up are pitfalls specific to the algorithms, and good implementations don't fall into them.

DJB also found weaknesses in AES; that doesn't mean it's likely to ever have a practical break. DJB is a researcher, and is always looking for better solutions. If we ever get around to replacing ECDSA, his research will be a valuable resource -- assuming that Quantum computing is the reason we're replacing ECDSA.

Implementation issues don't necessitate that ECDSA is weak; ECDSA is at the heart of most modern TLS certificates, including many of Google's, as well as being central to BitCoin.

U2F is a wrapper around OpenPGP in one direction. It could have easily been a wrapper around OpenPGP in its entire, but it's not.

I'm unable to find anything regarding OpenPGP in the FIDO U2F specifications Everything points to it being a cryptographic authentication. The communication protocol is utterly unlike OpenPGP.

All the way down to the hardware level, including open-source U2F token designs. (The link can do U2F, but has zero OpenPGP capability)

As far as I've been able to research (and I'm implementing FIDO U2F for my employer), U2F is entirely separate from OpenPGP.

If you have anything that says otherwise, I'd appreciate it.

This isn't a DRM device. Go right ahead and emulate (provide a software implementation of) security keys, the server you're logging in to doesn't care how secure your security key is. Software implementations are discussed in the spec, if you're so inclined. Just realize that you're losing some security, like if you had a software TPM instead of a hardened chip to hold your private key.

If you want to deploy it in a corporate setting or if you really want more control, I suppose you could have the remote server check what issuer signed the keys on the security key, which allows you to ensure they came from a given manufacturer, like not one that makes a software implementation. At least for a publicly facing site, don't use a whitelist of manufacturers.

FIDO is what you are looking for: https://fidoalliance.org/speci...

When TeamViewer users where impacted, the initial reaction was TeamViewer itself had been hacked. They responded with the claim that users' reuse of passwords where to blame and TeamViewer security had not been breached. The fact an independent remote access software company is exhibiting the same issues seems to indicate that TeamViewer was probably correct that user behavior regarding poor handling of passwords is to blame.

While both TeamViewer and Citrix seem to now be pushing two-factor authentication, they both seem to be using solutions they created themselves rather than contribute to an industry standard method which is consistent for the user across websites. It would be nice as this problem becomes more common that more companies join the FIDO Alliance as this should provide a single method for the user to learn which them works the same across all U2F compliant sites.

GREAT... Just great... This will surely not cause the least bit of confusion at all with the existing FIDO Alliance. https://fidoalliance.org/

Even so, having a physical switch is already helpful. I don't need to worry about the firmware malware if I don't ever have the intention to flip the switch. I only need to take measures to secure the computer against the malware if I plan to flash the firmware. A physical switch is a very powerful countermeasure to thwart remote attackers. U2F tokens also use it to secure two-factor authentication.

Fido U2F overview

The security key won't respond if it doesn't receive the right message from the website. Some detail here: http://fidoalliance.org/specs/... (See section 6, page 11)

I was thinking this was more a leave it plugged in dongle, so Google has guaranteed tracking of all you do. After all, why would Google do anything if it doesn't add to the bottom line?

There's no need to speculate, Google doesn't make the security keys, and the protocol is public. The way it's designed actually offers some pretty strong privacy guarantees, the spec even calls it out explicitly "If this origin check was not present, a public key and Key Handle issued by a U2F device could be used as a 'supercookie' which allows multiple colluding sites to stringly verify and correlate a particular user's identity." (overview, section 4). There is one case the security keys can leak information though. If a website suspects that two users are really one person, and that person is using the same security key for both accounts, the website could see a log in attempt for user "bruce.wayne" and instead of sending the blob for bruce.wayne's key to decrypt, send the blob for "batman"'s security key to decrypt. Since it's the same security key decryption will be successful, and the website learns that someone with batman's security key also typed in the username and password for user bruce.wayne.

As for Google's motives, you'll have to ask Google.

The dongle doesn't have anything to do with Google? It's made by a third party and is based on a standard, U2F, created by a bunch of companies.

Google is only accepting it in Chrome, so there's that.

It's really sad to see Google turning inwards like this. What happened to working towards open standards for such things?

Too true. Couldn't they have used an open standard like FIDO's U2F instead of using proprietary technology like...

Wait, what was your objection again?

PayPal CIO wants to ditch all passwords.

He is suggesting as an alternative something from the FIDO Alliance.

It could be something as simple as the Google Authenticator that generates number that last for mere moments.