People should drop passwords altogether

[tooki]

And you can't fix stupidy by replacing passwords with something else. Neither should you force users with a password manager to use a different method, just because you think it's idiot-proof.

And you shouldn't use biometric certificates, because when (not if) they become compromised, the user has zero alternatives and becomes disenfranchised!

Just a reminder, for the hundredth time, that the standard in question does NOT mandate biometric authentication.

[tooki]

And you can't fix stupidy by replacing passwords with something else. Neither should you force users with a password manager to use a different method, just because you think it's idiot-proof.

Nothing is ever going to be perfect. But moving from something that has proven itself to be bad in practice, to something that has proven itself to be better in practice makes sense.

[Someone]

And you can't fix stupidy by replacing passwords with something else. Neither should you force users with a password manager to use a different method, just because you think it's idiot-proof.

And you shouldn't use biometric certificates, because when (not if) they become compromised, the user has zero alternatives and becomes disenfranchised!

Just a reminder, for the hundredth time, that the standard in question does NOT mandate biometric authentication.

Which standard specifically? This topic rapidly gets into political level doublespeak.

FIDO UAF does have mechanisms for requiring biometric methods, given that option some services/platforms will use it to mandate biometric authentication.

[gmb42]

And you can't fix stupidy by replacing passwords with something else. Neither should you force users with a password manager to use a different method, just because you think it's idiot-proof.

And you shouldn't use biometric certificates, because when (not if) they become compromised, the user has zero alternatives and becomes disenfranchised!

Just a reminder, for the hundredth time, that the standard in question does NOT mandate biometric authentication.

Which standard specifically? This topic rapidly gets into political level doublespeak.

FIDO UAF does have mechanisms for requiring biometric methods, given that option some services/platforms will use it to mandate biometric authentication.

I quite happily use FIDO2 keys for MFA without any requirement for biometrics whatsoever, so any claim that they are required is just FUD mongering.

Authentication implementers can, if they wish, choose methods that do require biometrics, which then leaves users a choice on whether to use such a service or not.

[Someone]

And you can't fix stupidy by replacing passwords with something else. Neither should you force users with a password manager to use a different method, just because you think it's idiot-proof.

And you shouldn't use biometric certificates, because when (not if) they become compromised, the user has zero alternatives and becomes disenfranchised!

Just a reminder, for the hundredth time, that the standard in question does NOT mandate biometric authentication.

Which standard specifically? This topic rapidly gets into political level doublespeak.

FIDO UAF does have mechanisms for requiring biometric methods, given that option some services/platforms will use it to mandate biometric authentication.

I quite happily use FIDO2 keys for MFA without any requirement for biometrics whatsoever, so any claim that they are required is just FUD mongering.

Authentication implementers can, if they wish, choose methods that do require biometrics, which then leaves users a choice on whether to use such a service or not.

Yes, that's the point, the service/platform gets to decide what is/inst acceptable for their users. FIDO is a method by which they can start requiring biometrics. The standard its self does not mandate biometrics on any/all systems, but has mechanisms for biometrics to be mandated in implementations.

using FIDO* as a login method does not mandate biometric authentication
using FIDO* as a login method does not prevent mandate of biometric authentication

The user may not have a choice to go somewhere else when that platform/service is a government service.

[tooki]

And you can't fix stupidy by replacing passwords with something else. Neither should you force users with a password manager to use a different method, just because you think it's idiot-proof.

And you shouldn't use biometric certificates, because when (not if) they become compromised, the user has zero alternatives and becomes disenfranchised!

Just a reminder, for the hundredth time, that the standard in question does NOT mandate biometric authentication.

Which standard specifically? This topic rapidly gets into political level doublespeak.

FIDO UAF does have mechanisms for requiring biometric methods, given that option some services/platforms will use it to mandate biometric authentication.

I quite happily use FIDO2 keys for MFA without any requirement for biometrics whatsoever, so any claim that they are required is just FUD mongering.

Authentication implementers can, if they wish, choose methods that do require biometrics, which then leaves users a choice on whether to use such a service or not.

This.

FIDO makes it possible to rely on biometrics, but does not mandate it. There are alternatives, and countless people in this thread actively ignore this fact and instead devolve into hysteria about biometrics.

[Peabody]

It makes no difference to the user whether the FIDO standard requires biometric authentication, or the server using FIDO elects to require it.  In either case his biometric data is now part of the login process, even if only on his phone, and potentially subject to compromise.

But on a different subject, Steve Gibson (Spinrite) spent several years developing a password alternative called SQRL (Secure Quick Reliable Login) which uses a method similar to FIDO2, but is simpler, and offers the user the option of printing out as text or QR code his master key.  Each user has only one master key, not one for each site.  The elliptic curve private key for a site is a hash of the master key and the site's name, modified slightly to make the hash a valid private key.  Since it can be calculated on each visit to the site, there is no need to save each one.  Then the public key is calculated from the private key, and given to the website.  At login, the usual cryptographic exchange takes place, which verifies that the person logging in has the private key, but without revealing the private key.

There is no third party backup of the master key, and no third party involvement in the login.  Since each user has a written copy of his master key, recovery from lost or dead phones, or transfer to new devices, is straightforward.  Access to the master key on the device is available only after the user logs into his SQRL app - in whatever manner provides the most security the user can tolerate, which may be very little, at the user's option.

My understanding of FIDO2 is that a separate random key pair is generated for each site, which means that a user may have hundreds of them.  And FIDO2 does not allow the user know them or to make a copy of them.  That means that Apple, if it chooses, can limit transfer of the keys only to other Apple devices, which would make it impossible to switch to an Android phone.  Do we know yet what the major players' intentions are in this regard?  Are we going to have FIDO2 silos?

[madires]

Just a reminder, for the hundredth time, that the standard in question does NOT mandate biometric authentication.

Unfortunately multiple companies are going that direction. One payment card vendor just started something like "pay with your smile". So POS terminals get a webcam too.

[madires]

And you can't fix stupidy by replacing passwords with something else. Neither should you force users with a password manager to use a different method, just because you think it's idiot-proof.

Nothing is ever going to be perfect. But moving from something that has proven itself to be bad in practice, to something that has proven itself to be better in practice makes sense.

I fully agree. However, so far any other solution comes with new/other problems. A lot of tradeoffs, but nothing really better.

[tooki]

It makes no difference to the user whether the FIDO standard requires biometric authentication, or the server using FIDO elects to require it.  In either case his biometric data is now part of the login process, even if only on his phone, and potentially subject to compromise.

Well, it does offer the possibility of choosing an alternative product/service, at least.

But on a different subject, Steve Gibson (Spinrite) spent several years developing a password alternative called SQRL (Secure Quick Reliable Login) which uses a method similar to FIDO2, but is simpler, and offers the user the option of printing out as text or QR code his master key.  Each user has only one master key, not one for each site.  The elliptic curve private key for a site is a hash of the master key and the site's name, modified slightly to make the hash a valid private key.  Since it can be calculated on each visit to the site, there is no need to save each one.  Then the public key is calculated from the private key, and given to the website.  At login, the usual cryptographic exchange takes place, which verifies that the person logging in has the private key, but without revealing the private key.

There is no third party backup of the master key, and no third party involvement in the login.  Since each user has a written copy of his master key, recovery from lost or dead phones, or transfer to new devices, is straightforward.  Access to the master key on the device is available only after the user logs into his SQRL app - in whatever manner provides the most security the user can tolerate, which may be very little, at the user's option.

Amusingly, I was just reading about Spinrite, and how it seems pretty much settled that there is no way Spinrite can work on modern storage devices. The fact Gibson still sells it and still makes the same grandiose claims about it makes me extremely skeptical of his integrity.

My understanding of FIDO2 is that a separate random key pair is generated for each site, which means that a user may have hundreds of them.  And FIDO2 does not allow the user know them or to make a copy of them.  That means that Apple, if it chooses, can limit transfer of the keys only to other Apple devices, which would make it impossible to switch to an Android phone.  Do we know yet what the major players' intentions are in this regard?  Are we going to have FIDO2 silos?

Good question.

[tooki]

Just a reminder, for the hundredth time, that the standard in question does NOT mandate biometric authentication.

Unfortunately multiple companies are are going that direction. One payment card vendor just started something like "pay with your smile". So POS terminals get a webcam too.

But… why?

And you can't fix stupidy by replacing passwords with something else. Neither should you force users with a password manager to use a different method, just because you think it's idiot-proof.

Nothing is ever going to be perfect. But moving from something that has proven itself to be bad in practice, to something that has proven itself to be better in practice makes sense.

I fully agree. However, so far any other solution comes with new/other problems. A lot of tradeoffs, but nothing really better.

Well that remains to be seen. I think most of the people dismissing the new systems (and fawning over passwords) don’t actually know what they’re talking about. I’m not a cryptography or security researcher, so I defer to those who are. My feelings aren’t equivalent to their experience and expertise — a sentiment I wish more people would embrace.

[madires]

Unfortunately multiple companies are are going that direction. One payment card vendor just started something like "pay with your smile". So POS terminals get a webcam too.

But… why?

Because someone at that company thinks it's a good idea?

[BradC]

Amusingly, I was just reading about Spinrite, and how it seems pretty much settled that there is no way Spinrite can work on modern storage devices. The fact Gibson still sells it and still makes the same grandiose claims about it makes me extremely skeptical of his integrity.

It does do one thing that nothing else does, which is the thing he calls "Dynastat". Repeated reads to the device where it returns the read data whether its correct or not. It does this thousands of times and builds a statistical picture of each bit in the sector (ie, is that bit likely to be a 1 or 0 based on what it returned over the last 1000 reads).

This is becoming increasingly less useful as drives technology improves, and if you look at it with a critical eye you'll see it's guessing the contents of the sector and then writing it back, calling it recovered.

In practice on smaller drives it does a reasonable job, particularly when you have a 4k sector size of which one 512 byte chunk is flaky. It can make the difference between "The word document is complete garbage vs only slightly corrupted".

I bought it many, many years ago. Would I buy it now? Probably not.

[madires]

Amusingly, I was just reading about Spinrite, and how it seems pretty much settled that there is no way Spinrite can work on modern storage devices. The fact Gibson still sells it and still makes the same grandiose claims about it makes me extremely skeptical of his integrity.

It does do one thing that nothing else does, which is the thing he calls "Dynastat". Repeated reads to the device where it returns the read data whether its correct or not. It does this thousands of times and builds a statistical picture of each bit in the sector (ie, is that bit likely to be a 1 or 0 based on what it returned over the last 1000 reads).

I don't think that feature is unique to Spinrite. It's a logical thing to do for old HDD technology, and I wouldn't be surprised if data recovery companies had that feature in their homegrown tools for a lomg time too.

[Peabody]

I don't think it guesses at anything.  It keeps trying until it gets a result where all the error correction works, so the read is valid.  If it can't ever get that, it reports the sector as unrecoverable.

In any case, it's currently under a complete rewrite to deal with today's huge drives in a more reasonable time.  The new version will be free to current owners of version 6.

Anway, back on topic, I still wonder how someone's FIDO2 key pairs will be transferred between devices made by different manufacturers.   Is there anything in the FIDO2 documents addressing that?

[gmb42]

Authentication implementers can, if they wish, choose methods that do require biometrics, which then leaves users a choice on whether to use such a service or not.

Yes, that's the point, the service/platform gets to decide what is/inst acceptable for their users. FIDO is a method by which they can start requiring biometrics. The standard its self does not mandate biometrics on any/all systems, but has mechanisms for biometrics to be mandated in implementations.

using FIDO* as a login method does not mandate biometric authentication
using FIDO* as a login method does not prevent mandate of biometric authentication

The user may not have a choice to go somewhere else when that platform/service is a government service.

What factors an authentication provider requires to use the service has very little bearing on the technology used in the authentication service.  Comingling biometrics where they aren't required is just more FUD.

[tooki]

Amusingly, I was just reading about Spinrite, and how it seems pretty much settled that there is no way Spinrite can work on modern storage devices. The fact Gibson still sells it and still makes the same grandiose claims about it makes me extremely skeptical of his integrity.

It does do one thing that nothing else does, which is the thing he calls "Dynastat". Repeated reads to the device where it returns the read data whether its correct or not. It does this thousands of times and builds a statistical picture of each bit in the sector (ie, is that bit likely to be a 1 or 0 based on what it returned over the last 1000 reads).

This is becoming increasingly less useful as drives technology improves, and if you look at it with a critical eye you'll see it's guessing the contents of the sector and then writing it back, calling it recovered.

In practice on smaller drives it does a reasonable job, particularly when you have a 4k sector size of which one 512 byte chunk is flaky. It can make the difference between "The word document is complete garbage vs only slightly corrupted".

I bought it many, many years ago. Would I buy it now? Probably not.

Yes, that’s the “feature” that chews up hard drives that are already failing. Much better to attempt to copy everything to another drive first, THEN go back and try and re-read. (That’s what real recovery software does.)

Bear in mind that people more knowledgeable than me concluded ages ago that this function can’t do what it says because drives don’t even have an ATA command to output the raw data. The drives already (automatically) perform heroic measures to recover data, more than SpinRite could ever do.

So if others don’t actually do this, it’s because it’s a) not possible, and b) pretending to do it endangers data by thrashing an already-failing drive.

[Someone]

Anway, back on topic, I still wonder how someone's FIDO2 key pairs will be transferred between devices made by different manufacturers.   Is there anything in the FIDO2 documents addressing that?

The approach I would be taking is to always register multiple clients against any service/provider. Lose/destroy/revoke a specific device? you've got another ready to go, immediately setting up the new primary client to always retain at least 2 sets of keys for any service.

Platforms/services really hate this with a passion, they want you to have a single client (for their misguided reasons) which we already see with RFC 6238 authentication implementations.

[Someone]

Authentication implementers can, if they wish, choose methods that do require biometrics, which then leaves users a choice on whether to use such a service or not.

Yes, that's the point, the service/platform gets to decide what is/inst acceptable for their users. FIDO is a method by which they can start requiring biometrics. The standard its self does not mandate biometrics on any/all systems, but has mechanisms for biometrics to be mandated in implementations.

using FIDO* as a login method does not mandate biometric authentication
using FIDO* as a login method does not prevent mandate of biometric authentication

The user may not have a choice to go somewhere else when that platform/service is a government service.

What factors an authentication provider requires to use the service has very little bearing on the technology used in the authentication service.  Comingling biometrics where they aren't required is just more FUD.

It isn't FUD, when the new incoming standard requires biometrics (to meet certain "levels"). And those biometric enabled devices will be widely deployed its pretty certain all sorts of providers will jump on the bandwagon and require unnecessarily "secure" authentication just because its zero/no cost to them. We have already seen this with mandated 2FA for students, oh you want to go to school? you must have a XXX or XXX brand mobile device with OS XX.X or newer and XXX biometric features, coming soon!

[Peabody]

Anway, back on topic, I still wonder how someone's FIDO2 key pairs will be transferred between devices made by different manufacturers.   Is there anything in the FIDO2 documents addressing that?

The approach I would be taking is to always register multiple clients against any service/provider. Lose/destroy/revoke a specific device? you've got another ready to go, immediately setting up the new primary client to always retain at least 2 sets of keys for any service.

Platforms/services really hate this with a passion, they want you to have a single client (for their misguided reasons) which we already see with RFC 6238 authentication implementations.

I don't think multiple personalities is a good option.  In the first place, it might work for lose/destroy/revoke, but what about adding a device?  Also, if the site is a forum like this one, I  want to have only one identity.  As I understand it, if you have multiple key pairs set up on a site, you have multiple identities there.

Well, there needs to be a uniform protocol to export and import your FIDO2 stuff to/from a different device.  I just haven't seen that yet, and will be reluctant to use FIDO2 without it.

[Someone]

they [platforms] want you to have a single client (for their misguided reasons) which we already see with RFC 6238 authentication implementations.

As I understand it, if you have multiple key pairs set up on a site, you have multiple identities there.

But that is purely a platform choice. Some places happily let you (once confirming your identity with client A) register/enrol device/client B to the same identity on the platform. But there is this push from other platforms that you may only have one secret key to use and you may never transfer/back it up (because SecURIty HoLEs !!$$@). Its that bit which is so infuriating, given that losing access to a key is something that will happen.

I lost a captive/hidden RFC 6238 key and had to abandon the identity associated with it, starting from scratch to build up a new trust and new identity (basic government services access) so its a real problem that just gets shrugged off as part of necessary "security".

[Peabody]

Well it will be interesting to see what they end up doing.  But somehow I am not optimistic that they will pass up the opportunity to build silos.

[tooki]

For what it’s worth, it appears Apple’s upcoming implementation will sync the saved keys using iCloud Keychain, just as they do now for saved passwords. (FYI, the key syncing happens peer-to-peer between a user’s devices. More recently, they added a keychain recovery function, which obviously necessitates it being stored on a server. I haven’t had a chance to look into exactly how it works.) Since Apple already offers iCloud for Windows, and it supports the password manager functionality via a browser plug-in, I don’t think there’s any evidence that Apple would actively try and silo users now.

[gmb42]

The FIDO Alliance announced in May their plans, supported by Apple, Google and MS, to allow users to use credentials on multiple devices without having to re-enrol.  Not entirely certain this fixes the issue if your "primary" device (phone, key etc.) is lost\stolen.

• Allow users to automatically access their FIDO sign-in credentials (referred to by some as a “passkey”) on many of their devices, even new ones, without having to re-enroll every account.
• Enable users to use FIDO authentication on their mobile device to sign in to an app or website on a nearby device, regardless of the OS platform or browser they are running.

[Ed.Kloonk]