Hello,
The FIDO alliance created a standard called passkeys that will be deployed in the following months. Passkeys are a new authentication method that aims to avoid passwords. It is more secure and also more user friendly.
Is passkey support in the roadmap for PureOS?
That doesn’t sound good.
I guess a bigger question would be: is relevant support in the roadmap for the upstream distro? (Debian)
If the primary use case is logging in to web sites then it may require support in the roadmap for the relevant browser?
Seems to be biased towards use on a smartphone (rather than desktop / laptop).
That makes sense, I will enquiry on this way. Thank you.
These two platforms are given as examples. We can hope that every password manager will support this in the future.
Yes, web sites too will have to implement modifications to support this. It’s not only on the operating system.
It is multi-device FIDO credentials. “Multi-device” can be desktops, laptops, or phones. Smartphones are used by a lot of people nowadays so I guess that majority of people will have a smartphone among their devices where their passkeys will be stored, but a smartphone is not mandatory.
Is the passkey a separate piece of hardware like the current fido key?
I believe its software, like OTPs are software.
Passkeys really are cryptographic key pairs as defined by the FIDO protocol:
As the whitepaper defines it, the new features of passkeys are:
For more information:
So it would always require access to the internet?
Not sure about this as this is quite new, but I don’t think so. Here are my suppositions.
Case of "Using a phone as a roaming authenticator"
If you register on a service from your computer/phone, this will create keys pairs on this device.
If you want later to authenticate with this same device, the local credentials on your device would be used.
If you want to authenticate on another device nearby the one you used to register, I suppose you will be able to do it using bluetooth without internet.
Case of "FIDO credentials can survive device loss"
The paper describes that passkeys have to be synced, but it is not detailed how, so I think every solution can be available, even offline ones.
If your passkey database is similar to a password database today, maybe it will be possible to export and import or copy and paste from one device to another?
You could also self-host a syncing solution at home without exposing it to the internet. It syncs on your devices once they are connected to your local network, by wifi or network cable. Once synced, the credentials stored on your device used to sign-in will be used.
But in this “syncing” scenario I think the overwhelming majority of users will use internet to sync their passkeys across their devices. Maybe solutions from GAFAM will need internet while other solutions wouldn’t need it.
In a lot of authentication use-cases today you need internet to access the service anyway.
When would that be a problem?
I don’t think it does technically require access to the internet but since 99.9% of the use will be to authenticate with online resources, you are probably going to have access to the internet at the time that you need it anyway.
As a hypothetical … when web browsers have this support and web servers have this support and, if needed, you have some kind of sync solution … you can probably use it on an airgapped network or a network that is otherwise too isolated from the internet i.e. you could use it on a private network provided that you run all of the pieces on that network.
As an even greater hypothetical … you could in theory use it strictly within a single, isolated computer where one process authenticates to another process within that computer.
Sometimes loss is a good thing. 
This topic left me wondering how this differs in functionality from TLS client certificates. Almost no web sites (or other servers that are accessed using TLS) use that functionality but it has been around for many, many years.
That’s an excellent point. Its good enough for the bank to prove its identity, it should be good enough for me to prove mine.
I’m sorry but I don’t get it.
I didn’t know TLS client authentication before so feel free to correct me in case my understanding is wrong.
From my understanding, FIDO and TLS client authentication both use cryptographic key pairs and a challenge is used to avoid replay attacks.
But I fail to understand how a multi-factor authentication solution would be enforced for every user and every certificate with TLS client authentication.
Certificates are only something you have.
In FIDO, the private key is something you have, but you need something you know or something you are to use it. It is part of the specification. One so-called FIDO authenticator has to enforce this behavior, else it is not FIDO.
Same kind of situation for the device loss use-case. It’s up to the users to manage this case securely with TLS certificates, which is not easy for a lot of users. Passkeys provide a simple way to do it.
Banks have enough resources to have professionals manage all the technical details to ensure good security practices.
Average users do not apply basic security practices.
I’m not pretending that if you have the knowledge and dedicate the necessary time and attention you cannot enforce good security with something else than passkeys. I think that passkeys would improve my accounts’ security a lot without being more cumbersome than what I do today, and I think that I’m not the only one in this case.
Passkeys do not refrain you from continuing to use what you use today. They offer a new possibility for users who are not satisfied by current methods.
There are multiple scenarios where loss is a good thing. A generic buzzword that covers it is “the right to forget”.
As a background comment, cryptographic key pairs are generally very large numbers and numbers that are unique to you. So looking at a couple of practical examples:
True.
In either case (TLS client certificates or Passkeys) the security of it is only as good as the security that protects the private keys in the key pairs.
In a typical TLS client certificate use case, you would enter a password that only you know in order to unlock the keystore (or keyring) and give the local software access to the private keys. However any keystore implementation is possible and any protection mechanism for the keystore is possible. (You might instead unlock by using a PIN to unlock an OpenPGP card which in turn is then used to unlock the keystore.) It is unlikely that any fair dinkum keystore software would simply store the private keys in plaintext, so device loss isn’t really an issue.
If you look at a typical Linux computer (well, typical for me anyway ), you can find two different keystore implementations. There is seahorse (aka Passwords and Keys) and there is the one built in to Firefox. In the latter case, it is convenient because that means the process of acquiring and storing a new TLS client certificate from a web site can be fully automatic. It’s just that “noone” is using this longstanding functionality. (In theory Firefox could store the certificates in seahorse but I suspect that, being cross-platform, it does not do that.)
I would imagine that it is very similar with Passkeys, except that Passkeys also talks about biometrics instead of a password.
Biometrics are generally considered suspect from a privacy and security point of view e.g. can’t change the “password” if it is compromised and e.g. you can be legally or physically compelled to use biometrics to unlock.
Biometrics are slightly biased against more basic hardware configurations. If you have a desktop that lacks a webcam and lacks a fingerprint reader … you probably can’t use biometrics, so you are probably going to use a good old password to protect your private keys in either case.
More advanced biometric hardware may only come with drivers for Microsoft Windows, so no use at all to me.
So, yes, I’m down on biometrics but, really, protecting the private keys can be done using your choice of mechanism in either case, right? (as long as there is some second factor, either something you are or something you know)
If you really want to use biometrics then biometrics can protect your keystore that contains your TLS client certificates.
The right to forget implies the user chose it. By “device loss” I wanted to describe the cases where the user lost his device unwillingly, such as theft. In this regard, device loss is always a bad thing, because if you had nothing in place as credentials backup, then you loose access to your accounts unwillingly. And it is a good thing that an implementation finds ways to solve these issues.
In this case one does not want any syncing solution at all. This is not against passkeys specifically. Due to the number of people enjoying sync technologies today, I think passkeys can be useful to them. But of course if you do not want any syncing solution nor Bluetooth then passkeys are not for you.
And passkeys do not aim to replace other authentication solutions. You will still be able to authenticate with the methods you use today. This will just add new possibilities for users.
This is not part of my threat model and I am not able to secure my digital life against state-funded organisations.
Besides, what an authoritarian government would do: 
I agree with that but there can be other implementations than Big Tech ones.
This is exactly what I want.
As it is a two-factor authentication solution, the second factor exists to mitigate the effects of “loosing” the “something you have” factor. But I agree that average users will not take care of that before selling their device. So having a secure disposable device to store the keys would be better, but people do not do that and keep using passwords instead.
True.
TLS client certificates as you describe them seem very similar to FIDO. But in case of a new device or a device loss, you have to take care of certificates transfer or backup in a secure way yourself. Passkeys do this with a standard that is easy to use and secure for a lot of threat models.
I agree with you on biometry.
You can choose between different methods as the private key unlocking method, yes: https://www.w3.org/TR/webauthn-3/#user-verification
User verification MAY be instigated through various authorization gesture modalities; for example, through a touch plus pin code, password entry, or biometric recognition (e.g., presenting a fingerprint)
The comic you included is a good reminder to look at realistic threat models. If a government is after me, I am most likely screwed because I stay on the grid. But right now the odds of a government targeting me directly are small.
I use full-disk encryption as a means to safeguard my data in case I lose a device someplace public, like left behind on a train or something. That way accessing my data that could be used to steal my identity isn’t just a simple step of plugging the drive into another computer.
Yep I understood that. I was just generalising from “device loss” to “loss”.
… which is one reason to be down on biometrics.
However it would be wrong to think that “authoritarian government” is the only scenario where “compelled production” will occur. In the good old days of biometrics it used to be said, perhaps unreasonably, that the mafia would just cut off your finger in order to use the fingerprint to unlock something.
It isn’t obvious to me that that is true.
I can imagine that a Big Tech company like Google, who is a FIDO alliance member, if it suddenly wanted to push Passkeys, would implement it in Google Chrome (if not already) and start using its formidable internet clout and bag of underhanded tricks to get web sites to change over.
I can imagine that if I am the implementer of a new web site, I do not wish to support three authentication mechanisms
so I pick one.
If Google Chrome implements Passkeys, I as the web site implementer, having chosen Passkeys, just say to all those who refuse to use Google Chrome, well, 60% of the world uses Google Chrome, our web site is tested with and works with Google Chrome, so tough luck to you. If you want to log in then you have to submit to surveillance by the GoogleBorg.
I think it would be quite confusing for users if a web site lets them associate two or more authentication mechanisms with the same account, or the opposite, and confusing for support staff and site administrators.
For sure, that’s not going to happen overnight. In fact it isn’t really obvious what the migration strategy would be for an existing site. I expect that existing sites that have millions of users all using a password will still be using passwords for a long time to come.
Maybe. Firefox has been pushing its sync solution for a while now. I don’t know whether the keystore is within the scope of what gets synched but clearly it could be. (I personally configure so as not to allow Firefox to sync.)
In terms of backup, well, you have to do backup anyway, right? For all my “real” computers (and I include the Librem 5 in that), I just back up the entire disk. By definition that then includes the encrypted keystore - and everything else.
It’s only the iPhones where I have this OMG feeling … I have no idea what I just backed up, no idea what format it’s in, no idea whether I would be able to restore it in the future etc.
Encryption is indeed a good solution to mitigate device loss risks regarding access to data. If one is worried about losing a device with passkeys or certificates stored on it like irvinewade was mentionning, the second factor mitigates the risk to a successful authentication, and if the device was encrypted, I think we can consider the account(s) safe in regard to most threat models.
Encryption is spreading even for average users, especially on smartphones, but it is not yet present everywhere sadly. I’d like that it becomes a default instead of requiring knowledge and effort on user’s side.
You are right. I am suspicious about biometry as an authentication factor for the following reasons:
It seems also more difficult to implement a “plausible deniability” system than with “something you know” factors. This point is not really relevant regarding my threat model but I prefer to keep that in mind just in case things change.
I hadn’t considered that and you make a point. But in the same time for the services I’m interested in, few propose something else than passwords only. You aknowledged yourself that TLS client authentication is very rarely used. Some services propose multi-factor authentication, often SMS-based. So it seems more like passkeys have the opportunity to fill a void instead of replacing safe and broadly used authentication methods.
I do not see a momentum going for something else today, so I see passkeys as a clear gain in this context. I feel like “blocking” the use of passkeys hoping for something better to emerge will leave everyone with passwords only, for years to come.
I do not want that either, this is why I would like that things get moving from the privacy-respecting tools and services regarding passkeys, to provide good alternatives.
And this would bring no benefit as the security of the account would be the one of the less secure method.
It will be the case for years for sure.
You’re right. I just think that backing up something that is synced across devices potentially on different platforms is easier than backing up each device. I do not think that most users back up their entire devices especially for all of them.
In my case I backup my password database today and I expect the same complexity to backup a passkey database in the future. I also backup my one-time-password database and I would like to get rid of it.
Regarding the GoogleBorg, I note that Mozilla is a sponsor level member of FIDO, as is Red Hat - so there is some interest outside of proprietary Big Tech.
Yes. I think that is, sadly, correct.
I assure you that whether Debian or whether any web browser on Linux implements Passkeys will be 100% unaffected by this discussion.
Anyway, to summarise it as I see it …
On the client side, for a typical desktop / laptop (and maybe even smartphone) I don’t think Passkeys is going to be more secure than using a password manager with randomly generated strong passwords. In either case the secret information will be protected by a password and if that password is compromised then every single web site login for that user is compromised.
In other words, for the typical reader of this forum, Passkeys won’t be an improvement. (And in one very select case, it will be less secure i.e. where the user uses a randomly generated strong password and, because the web site is so important, chooses not to record the password in the password manager, and just remember it. I also use multiple password stores, with different passwords, segregated by “importance”, so that even if one password store is compromised, not all passwords are compromised.)
(The previous two paragraphs would very much summarise how I use a password manager.)
However for the average slacko, who uses weak passwords and reuses them across web sites, and commits other password sins … Passkeys will be an improvement.
In either case (user of this forum or average slacko), this summary considers only the authentication solution in isolation, and not any flow-on effects or effects in the wider IT ecosystem.