Let’s start with a smartphone. A user creates an account with a passkey for a service, that passkey gets stored on their smartphone, and they can use biometrics to sign in from then on. The private key is stored on the smartphone. Great.
But then how do you sign into that same service from a different device?
If it’s by using a password manager, some third party piece of software, How do you sign in on a device where you’re not allowed to install third party software?
How do you sign in on a device where you’re not allowed to install third party software?
You don’t. Passkeys are very ecosystem-centric right now. If you are in apple, google, or Microsoft entirely, they will all allow you to move your passkeys around to different systems using the same basic mechanism they used for password keeping. Moving across ecosystems is absolutely broken - or rather - has never worked.
I think there are mechanisms to allow passkeys to work via Bluetooth or even via camera, as an external authenticator essentially, but I’ve never personally tried them.
Some password managers support passkeys, such as one password and proton pass, which will allow you to use multiple different devices. Personally, I am waiting for key pass to have proper support before starting to migrate to them.
Is keepass actually going to have support for passphrases? The author works in archaic ways and I have a feeling he’s never going to truly support it.
Keepass or keepassxc? Xc i think is a community fork.
I mean regular keepass, I feel like XC is more likely to implement passkeys
Okay, I see I have never used a regular one. I think I read to use XC by default. Somewhere. And so that’s the one I’ve always used. I’ve never even downloaded the original one.
Bluetooth and QR code passkeys are built around CTAP, but that’s judt an implementation detail.
You don’t have to use Apple, Google, or Microsoft, though. 1Password and Bitwarden also support passkeys, though you’ll need platform support for them to work as well as the native implementations do; for instance only Android 14 and up can have an arbitrary app act as a passkey provider, older versions will have to deal with Google’s fallback implementation.
In theory these independently provided passkey can even be exported, though I haven’t tried this myself.
I use camera one for github on a device outside my icloud, works great. A few websites also allowed me to add second passkeys (bitwarden in addition to icloud)
This doesn’t exist
FYI there’s a bug currently that lets everyone see the comment even after they are deleted
I use sync on android but I believe it’s a bug in the API so it should be everywhere
Just try to reply to the comment and you’ll see it
this has been a thing for a few months now
Good to know
Service shows you a code that you scan with your device. This code transfers some challenge and information where to send a response. Your device checks if you’re you and then sends a response telling the server you try to log in that hey this guys is indeed the guy, here’s the problem I solved using my private key (asynchronous encryption).
I use 1Password as my Passkey holder so it’s device agnostic. But if 1Password ever pulls a LastPass, it won’t seem like a clever solution anymore.
1Password can’t fail that hard easily. They’ve done great write-ups to compare their architecture to that of LastPass. Long story short: it’s the secret key that protects you: https://blog.1password.com/what-the-secret-key-does/
I would suggest to move to KeepassXC, which already shown that even when KeepassX was too slow to implement features the community was healthy enough to fork it and make it the main fork.
The wallet itself is nice, but managing the database transfers between devices isn’t really something I want to do manually, especially given that devices like Apple’s iPhones don’t support background syncing, crippling Syncthing clients, or alternatives
I’ve used it on a iPhome once with a Syncthing alternative client and some alternative Keepass app. It worked very well but it was only for a month or two and I don’t change passwords often so I might not realized that syncing doesn’t work well.
If 1Password becomes annoying, you might want to consider Bitwarden, which, if worst comes to worst, you can host yourself. Unlike Keepass you don’t need to manually sync a password blob. However, that also means that if Bitwarden’s/your server is down, synchronising will be impossible.
We’re in the process of adopting BitWarden at my job. I’m liking it so far. Not enough to convince my family to switch (yet), but enough that I wouldn’t hesitate to jump over there if I needed to.
Depending on the site, you can use one device to login to another without installing additional software. For instance, if you have an iPhone with a passkey for microsoft.com stored on it, you can login to Microsoft.com using the iPhone.
Here is a webpage that has some screenshots to show you what I mean. You can probably google some other examples.
It is possible to sync passkeys across devices but at this point is mainly within a single ecosystem.
Passkeys should display a QR Code for you to scan with a trusted device if you try to use them on a device that doesn’t have your passkey stored.
Short answer: they don’t very well yet.
deleted by creator
I’ve got a pair of YubiKeys that I use to back my passkeys. Works great; I’ve got passkeys that work within the Apple, Microsoft and Google ecosystems and don’t have to worry about password prompts for the most part — but I DO need a YubiKey handy to validate that it’s actually me at the device.
My keys use both NFC and USB-C and work across all my passkeys supported devices when I add in a USB adapter.
One spends most of its time in a safe deposit box, and the other lives on my physical keychain.
To use it, the person would need to be logged in on a device I own (that’s password protected) AND have one of the keys (which also requires a PIN).
deleted by creator
Definitely. Costs extra, has an extra step to set up, and has an extra step to use, but is so much more secure.
That said, biometrics are better than “1234”. I have no issues with people who have bad password hygiene moving to biometrics, which at least add an extra barrier for account compromise.
But for the rest of us, physical security tokens are definitely the way to go.
Unless you’re using a random 10+ alphanumeric passcode and are fine entering it every time you log into your phone, with a short auto-lock period, you’re much better off enabling biometrics (assuming it’s implemented competently) in combination with a longer passcode and understanding how to disable it when appropriate.
I recently replied with this comment to a Gizmodo article recommending the same thing you did for similar reasons, if you’d like to better understand my rationale: https://ttrpg.network/comment/6620188
deleted by creator
I can’t speak to Android as a whole, but here’s how often Samsung Face Unlock will require you to re-auth with your phone’s passcode:
- after 4 hours of not using the phone
- after restarting
- at least once every 24 hours
iPhones do something similar, but it’s after 48 hours of non-use (instead of 4) and at least weekly instead of daily. Having to enter your password daily should help most people keep it memorized pretty well, but weekly - maybe not. So you definitely have a good point there.
One thing that can make it easier to remember - and just as secure - is to use a longer pass phrase instead of random characters.
If you using the diceware approach (“correct horse battery staple”), then 5 words has 32 times / 5 bits more entropy than a 10 character mixed-case alphanumeric password (64 vs 59 bits of entropy) (4 word passphrases aren’t random enough to be recommended - they have fewer bits of entropy (51) than even 9 character mixed-case alphanumeric passwords (53), though notably 10 same-case alphanumeric characters also have only 51 bits of entropy).
The EFF has a word list that’s been improved for usability. They also have a short list, comprised of words with at most 5 characters each, where you roll 4 dice instead of 5. With 6 words from that list you get 62 bits of entropy, which is good enough to be able to recommend.