I don't really want to replace it. It works fine. But the toolchain for other platforms is becoming difficult to manage. I use pass with PGP Yubikeys as backing for each encrypted password. But the developer of the Android version has stopped supporting it and the person who took it over has removed yubikey support because he doesn't use it himself and doesn't care about it.
Of course I need to access my passwords on Linux, Windows, Mac, Android. Only iOS is not possible because Apple doesn't allow raw APDU access to NFC tags so you can't do OpenPGP functions.
I also don't want to use a password manager with a single master password like bitwarden. I want each password to be encrypted individually with the public key from a number of hardware tags (multiple, that's also a hard requirement). This way not my whole password database is instantly leaked when my master password gets compromised. Even when my endpoint gets completely compromised, the only passwords they will have are the ones I decrypted on it since it was compromised. Yubikeys require a physical touch for every decryption so you also can't 'milk' them for credentials when they're inserted and unlocked. Also, any password manager I use must be self-hosted, I hate and don't trust the big tech companies.
I wonder if this could be a new backend. And have support on all platforms (though iOS I don't care about personally, but it would be a nice to have).
faeranne · 8h ago
Checkout passage: https://github.com/FiloSottile/passage which has done part of this by using age instead of pgp. I used it for a while, and last I checked there was sadly no android app (the pass android app hardcoded too much PGP to be a useful base, so I was told), but the work is def there.
Nice! But I can't really use it until it works on Android too (with hardware keys). I'll definitely try it out though.
> the pass android app hardcoded too much PGP to be a useful base
The original one did not. It leveraged the OpenKeyChain external app which basically handles all the PGP stuff. So there was no PGP code in the app. Similar to how it's done on a PC with the gpg suite
But someone rewrote it with an internal library which also removed Yubikey support.
VTimofeenko · 5h ago
Android pass+[yubi|nitro]key work fine through openkeychain:
I think my dream password manager currently is a Pinephone with a special custom UI that allows for managing and securing a list of accounts/passwords that can type them out via USB HID keyboard gadget when prompted.
No way to prompt it for data, or compromise it remotely.
No other features, no OS userspace, no wifi, no adb, no nothing. Just a Linux kernel + a tiny single userspace static binary based on lvgl for UI and libsodium for encryption/storage. Normally powered off, boots in 2 seconds. :)
bkettle · 6h ago
I made one of these a while ago in school, it was fun! I think it's a great idea. Mine really had nothing: an overly complicated MCU, since it was provided by the class, but otherwise no need for an OS or anything: https://benkettle.xyz/projects/password-keeper/
megous · 5h ago
Nice. My wishlist also includes something similar looking with Luckfox Pico Mini + small OLED for displaying info about requests (via USB), to authorize various crypto operations with secret material stored on the device. :)
70rd · 3h ago
Check out Precursor (FPGA device with softcore CPU running on it for trustability).
Xous (microkernel OS for Precursor) has an application called Vault that does FIDO2/U2F as well as password management and USB HID emulation.
Much more on the dev board side and probably overkill for just this purpose but a really cool device.
lxgr · 8h ago
Tons of ways to compromise it between your computer's USB port and the server's database, though. If you already have dedicated hardware, FIDO authenticators make much more sense.
> Just a Linux kernel [...]
That's several orders of magnitude more lines of code than any FIDO authenticator implementation.
> Normally powered off, boots in 2 seconds. :)
Yubikeys boot even faster!
wkat4242 · 7h ago
Yeah and also it's huge for just a password manager.
odo1242 · 5h ago
> Tons of ways to compromise it between your computer's USB port and the server's database, though. If you already have dedicated hardware, FIDO authenticators make much more sense.
I mean, if you have the amount of access needed to compromise a USB connection, you have way more than enough access than needed to just yoink the authentication token or encryption key from browser storage.
megous · 6h ago
None of this is a problem.
FIDO2 works only with websites that support it.
bee_rider · 8h ago
Why a phone, though? The device doesn’t need any connectivity other than to act as a USB “keyboard,” right? Maybe a raspberry pi zero could do it.
megous · 6h ago
Cheaper, with integrated display, battery, touchscreen, working software, and nice form factor for the use case, sane fully open bootloader and firmware, full documentation for everything, much more power efficient.
defraudbah · 10h ago
I follow Filippo for years and he's doing amazing job for crypto and golang communities. Excited to see your bikes adventures too. If it wasn't for you who knows, maybe golang wasn't that popular in the fields where cryptography matters.
keep up, Filippo!
dariosalvi78 · 10h ago
I was waiting for the prf to be implemented since a long time exactly for this type of applications (e2e encryption), but , as usual, Safari doesn't support it
Huh, iCloud Keychain supports the prf extension when used with Chrome, so I had assumed they added support to Safari as well, but I just tested it and sure enough, you're right.
Edit: well https://webauthn-passkeys-prf-demo.explore.corbado.com/ works with an iCloud Keychain passkey on Safari on macOS 15.5, but Typage doesn't work with a YubiKey 5, so there is some support (the MDN data is out of date) but also something weird.
> Note that there’s no secure way to do asymmetric encryption: we could use the PRF extension to encrypt a private key, but then an attacker that observes that private key once can decrypt anything encrypted to its public key in the future, without needing access to the credential.
IMHO, it would move the world of privacy forward significantly if someone took up championing a web API that securely pipes the output of WebAuthn's PRF into the input seed of a WebCrypto ML-KEM/X25519 implementation.
Sure, we'll still have the (unenviable) job of securing the client side JS environment, but it would make it feasible to have E2EE in the browser with passkey managed private keys exposed only up to the point of the browser/OS.
crossroadsguy · 1h ago
On this topic — how to harden security of the keychain db on the Mac? One is — keep the Mac password long and difficult to crack. What else? Is there any other way to make it harder? Like is there a way to ensure that those db files can’t be accessed even with the mac password on any other hardware?
Also — on a mac why are these files not saved in a location that requires elevated access?
Because that file has everything — password, wifi keys, passkeys; and it is not very practical to have 8-10 word long passphrases for your daily computer.
Basically — I am thinking about the scenario when the data of passwords/keychain db might be compromised but not the Mac password itself.
neutrinoq · 9h ago
For a simple web app that encrypts files with passkeys, check out https://filekey.app
Crontab · 3h ago
I recently started to plan for off-site, cloud-based storage and I have pretty much decided that I will be using Age to encrypt my backup files. It basically does everything I need.
My appreciation to the creator.
mkw5053 · 10h ago
Very cool! Clever use of WebAuthn’s PRF to reuse synced passkeys for file encryption without the hassle of managing private keys directly. The catch is credential revocation: leaked passkeys mean full rotation and bulk re-encryption of files. That works fine for casual backups, but production usage will need tooling to handle automated rotation cleanly.
lxgr · 8h ago
> Clever use of WebAuthn’s PRF to reuse synced passkeys for file encryption
Agreed on the clever part, but arguably that's exactly what PRF was designed for :)
> The catch is credential revocation: leaked passkeys mean full rotation and bulk re-encryption of files.
That's where the PRF input of key derivation comes in. The idea is to have that input be rotate-able.
That's also why there is two of them: So you can "atomically" (or at least using only one WebAuthN interaction) rotate the derived keys.
packetlost · 10h ago
I feel like only one extra layer of indirection (encrypt a symmetric key with the age key) would enable rotation.
9dev · 10h ago
Yeah, envelope encryption is the only sane solution. That also allows decryption with multiple passkeys, for example.
johnisgood · 6h ago
Can someone sum up the difference between "passkeys" and "SRP, PAKE (like OPAQUE), and ZKPs"?
Besides being related to the web (only?), it seems.
hoppp · 7h ago
What devices support the prf extension?
Been waiting for it to get support for years
9dev · 9h ago
This enables a few cool use cases, like uploading sensitive, client-side encrypted documents, and storing them on behalf of the user—without even being able to peek inside—all with the convenience of passkeys!
skybrian · 8h ago
This could simplify things a bit for website owners since they don’t need to protect a database where they store encryption keys. Bugs or supply-chain attacks on client-side software are still a vulnerability, though.
For the customer, they are unlikely to be able to audit the client-side software and any updates to it, so it still requires trust. The software could still have a lot of telemetry baked in.
Maybe someday there will be something like certificate transparency for software?
SchemaLoad · 3h ago
Sometimes the company cares more about not having access than the end user does. If you physically don't have the decryption keys, you can't get hacked and have user data leaked. You can also respond to government data requests with "Sorry we don't have access to that"
megous · 9h ago
Nothing that the user can trust, though.
Only way to upload sensitive data is to encrypt it yourself, while handling all the secret key material yourself, and then upload the result. You can't trust the website, when it has access to the secret key, regardless of whether it was derived from FIDO2 HMAC or whatever.
lxgr · 8h ago
Trust isn't absolute.
Deploying a malicious version of a given webapp is still harder (and much more visible) than just silently dumping a backend database, so I'd trust an implementation that client-side encrypts my data using PRF and passkeys significantly more than one just uploading everything in plaintext.
9dev · 8h ago
Huh? But that’s the entire point. The website only knows your public key. The encryption happens locally, within the secure code of the authenticator, far away from the website.
skybrian · 8h ago
The decrypted data is stored in a JavaScript variable. The JavaScript is under full control of the website owner. Adding telemetry to a website is pretty easy.
It would simplify website operations and eliminate some kinds of security bugs, though.
megous · 5h ago
No it does not. Website knows the secret key, it just is not supposed to store it (user has to trust that the website stores just salt and not the derived secret key):
What good timing. I am gearing up for a 1.0 release of a tool I wrote that stores secrets on disk (sort of like a local hashicorp vault/aws secrets manager) that uses age internally.
It has a tiered architecture where several different types of “unlockers” can access the main vault key. I haven’t added passkey support yet but it does do gpg and macOS keychain, and secure enclave support is planned (but delayed due to the fact that you cannot use the secure enclave even on a local device you own without a paid/doxxed Apple Developer Program membership for the correct entitlements).
andrewmcwatters · 10h ago
Say you wanted to share sign in details with someone and the only way to sign in to a website or service was a magic email link (tied to an IP address) or a passkey (tied to the physical user).
How do you do it without the service implementing guest sign in as a feature? I’m asking as someone who has implemented auth.
lxgr · 10h ago
iOS allows sharing passkeys via Airdrop, I believe, and presumably 1Password also allows storing them in shared vaults?
Regarding email, nothing prevents somebody wanting to share an account from just forwarding the magic link to the intended recipient without clicking on it, right?
andrewmcwatters · 6h ago
Depends on the magic link implementation, really. Some tie the login request to specific request details.
degamad · 6h ago
Many (most?) sites that I have used passkeys on allow having multiple passkeys linked to the same account.
perching_aix · 10h ago
Sounds like a rhetorical question? Maybe you could explain the usage context instead?
phoronixrly · 9h ago
Now do one for signing Linux packages with <insert anything else but GnuPG>...
FiloSottile · 9h ago
You'll never believe what I (and a bunch of folks) have been working on for years :)
I don't really want to replace it. It works fine. But the toolchain for other platforms is becoming difficult to manage. I use pass with PGP Yubikeys as backing for each encrypted password. But the developer of the Android version has stopped supporting it and the person who took it over has removed yubikey support because he doesn't use it himself and doesn't care about it.
Of course I need to access my passwords on Linux, Windows, Mac, Android. Only iOS is not possible because Apple doesn't allow raw APDU access to NFC tags so you can't do OpenPGP functions.
I also don't want to use a password manager with a single master password like bitwarden. I want each password to be encrypted individually with the public key from a number of hardware tags (multiple, that's also a hard requirement). This way not my whole password database is instantly leaked when my master password gets compromised. Even when my endpoint gets completely compromised, the only passwords they will have are the ones I decrypted on it since it was compromised. Yubikeys require a physical touch for every decryption so you also can't 'milk' them for credentials when they're inserted and unlocked. Also, any password manager I use must be self-hosted, I hate and don't trust the big tech companies.
I wonder if this could be a new backend. And have support on all platforms (though iOS I don't care about personally, but it would be a nice to have).
Nice! But I can't really use it until it works on Android too (with hardware keys). I'll definitely try it out though.
> the pass android app hardcoded too much PGP to be a useful base
The original one did not. It leveraged the OpenKeyChain external app which basically handles all the PGP stuff. So there was no PGP code in the app. Similar to how it's done on a PC with the gpg suite
But someone rewrote it with an internal library which also removed Yubikey support.
https://f-droid.org/app/org.sufficientlysecure.keychain
No way to prompt it for data, or compromise it remotely.
No other features, no OS userspace, no wifi, no adb, no nothing. Just a Linux kernel + a tiny single userspace static binary based on lvgl for UI and libsodium for encryption/storage. Normally powered off, boots in 2 seconds. :)
Xous (microkernel OS for Precursor) has an application called Vault that does FIDO2/U2F as well as password management and USB HID emulation.
https://www.crowdsupply.com/sutajio-kosagi/precursor/updates...
Much more on the dev board side and probably overkill for just this purpose but a really cool device.
> Just a Linux kernel [...]
That's several orders of magnitude more lines of code than any FIDO authenticator implementation.
> Normally powered off, boots in 2 seconds. :)
Yubikeys boot even faster!
I mean, if you have the amount of access needed to compromise a USB connection, you have way more than enough access than needed to just yoink the authentication token or encryption key from browser storage.
FIDO2 works only with websites that support it.
keep up, Filippo!
https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
Edit: well https://webauthn-passkeys-prf-demo.explore.corbado.com/ works with an iCloud Keychain passkey on Safari on macOS 15.5, but Typage doesn't work with a YubiKey 5, so there is some support (the MDN data is out of date) but also something weird.
IMHO, it would move the world of privacy forward significantly if someone took up championing a web API that securely pipes the output of WebAuthn's PRF into the input seed of a WebCrypto ML-KEM/X25519 implementation.
Sure, we'll still have the (unenviable) job of securing the client side JS environment, but it would make it feasible to have E2EE in the browser with passkey managed private keys exposed only up to the point of the browser/OS.
Also — on a mac why are these files not saved in a location that requires elevated access?
Because that file has everything — password, wifi keys, passkeys; and it is not very practical to have 8-10 word long passphrases for your daily computer.
Basically — I am thinking about the scenario when the data of passwords/keychain db might be compromised but not the Mac password itself.
My appreciation to the creator.
Agreed on the clever part, but arguably that's exactly what PRF was designed for :)
> The catch is credential revocation: leaked passkeys mean full rotation and bulk re-encryption of files.
That's where the PRF input of key derivation comes in. The idea is to have that input be rotate-able.
That's also why there is two of them: So you can "atomically" (or at least using only one WebAuthN interaction) rotate the derived keys.
Besides being related to the web (only?), it seems.
For the customer, they are unlikely to be able to audit the client-side software and any updates to it, so it still requires trust. The software could still have a lot of telemetry baked in.
Maybe someday there will be something like certificate transparency for software?
Only way to upload sensitive data is to encrypt it yourself, while handling all the secret key material yourself, and then upload the result. You can't trust the website, when it has access to the secret key, regardless of whether it was derived from FIDO2 HMAC or whatever.
Deploying a malicious version of a given webapp is still harder (and much more visible) than just silently dumping a backend database, so I'd trust an implementation that client-side encrypts my data using PRF and passkeys significantly more than one just uploading everything in plaintext.
It would simplify website operations and eliminate some kinds of security bugs, though.
https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-cl...
https://git.eeqj.de/sneak/secret
It has a tiered architecture where several different types of “unlockers” can access the main vault key. I haven’t added passkey support yet but it does do gpg and macOS keychain, and secure enclave support is planned (but delayed due to the fact that you cannot use the secure enclave even on a local device you own without a paid/doxxed Apple Developer Program membership for the correct entitlements).
How do you do it without the service implementing guest sign in as a feature? I’m asking as someone who has implemented auth.
Regarding email, nothing prevents somebody wanting to share an account from just forwarding the magic link to the intended recipient without clicking on it, right?
https://www.sigsum.org
https://github.com/FiloSottile/torchwood/tree/main/cmd/apt-t...
https://www.youtube.com/watch?v=SOfOe_z37jQ
https://c2sp.org/tlog-tiles