keep up, Filippo!
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?
I don’t think I understand the problem. Person A tries to log in; B receives a magic link, does not click it but forward it to A; A clicks it and gets logged in.
I’ve done this myself successfully, even with services pinning the link to A’s client IP (which is a bad idea anyway in an age of privacy proxies, CG-NATs, dynamic IPs etc.)
The first key is now safer, but now I have to manage 2 keys, master key and a the one I use per files group X.
In scenarios where you don't have multiple users, you can also just prepend the encrypted data key to the payload (as in, `<encrypted data key>.<encrypted payload>`), so effectively you'll only have to store an encrypted blob and the user key.
Edit: The AWS docs explain this way better than I do: https://docs.aws.amazon.com/encryption-sdk/latest/developer-...
I was thinking that master key is a wrapping key but that's the other way around, plus I can have many users who have access to the data. Neat
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.
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.
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...
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?
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).
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. :)
> 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!
FIDO2 works only with websites that support it.
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.
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.
Interestingly, Pinephone is in the almost good intersection of hackable and portable: :)
Maybe I don't have enough money to buy a pinephone just for this purpose but even if I would have, I would personally look more into soldering (esp32?) or some single board chip (SOC?) with a touch screen sounds nice too.
Now I am not kidding, there was this dumb phone which I was using and its cost was like 12.5$ and it had the features of camera, mic , text , messaging, audio, file manager and so much more... Basically it just didn't had a browser or ability to add apps ofc since it wasn't android. But yeah I do believe that something niche could be developed for people like you at maybe 1/10th the price
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://github.com/FiloSottile/torchwood/tree/main/cmd/apt-t...
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).
https://sneak.berlin/20200307/the-case-against-microsoft-and...
Besides being related to the web (only?), it seems.
The user is required to enter a pin or password to unlock the private key (e.g. stored on their Yubikey or in their password manager) but that's a local decision. Also because a Yubikey and implement local rate limiting you don't need to have a long complicated password but a simple pin might suffice. Or you can use biometrics . This makes a passkey an authentication method with two factors. You provide something you know or are, and something you have.
OPAQUE instead is a key exchange protocol where you establish a secure session with only your password without ever disclosing that password to the server.
However, it's a single factor. You only provide your password as input.
The other problem with OPAQUE is that unlike passkeys there is no anti-phishing guarantee. A user might be tricked into entering their password into another website .
I guess this could be mitigated with browser support that derives a unique key from your password for each domain. But that browser support doesn't exist whilst passkeys do.
In my opinion passkeys are more pragmatic than OPAQUE as the security doesn't rely on the user having to pick a secure password and because there is browser support today
My appreciation to the creator.
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.
Passkeys enable phishing-resistant and 1-click authentication.
The PRF extension discussed here enables end-to-end encryption of data (with envelope encryption). Think about secure chat backups, double factor disk encryption (password + security key) and much more.
Soon we will be able to sign apps bundle (APKs, IPAs) with hardware security keys.
Great times are ahead for those who care about securing their users' data.
We've had this technology for decades, TLS client auth with X.509 certificates has been in browsers for a very long time. There just never was any interest in it, and never any investment into making the UI/UX usable beyond the most trivial use cases.
Passkeys are trumped-up certificates with a maybe-optional (depending on attestation status) hardware keystore. And lots of vendor lockin for Google, Apple and Microsoft. The only reason that there is a push right now is that big-vendor interest in lockin.
Surprising how that didn’t become a slam dunk replacing passwords!
thadt•6mo ago
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.