I like passkeys*
Uncategorized
31
Posts
12
Posters
36
Views
-
@whitequark Hm, are they actually removable once installed?
Like, if that phone flies down a cliff, would i typically still be able to log in with the password on a new device or a computer?@theartlav yes (otherwise I would not use them as I value availability far more than security)
-
I like passkeys*
* resident, non-hardware-token-based public key authentication mechanism for websites and Android apps, not to be confused with other things also called "passkeys" indiscriminately
all of my passkeys* live in a KeePassXC database and I am both safe from phishing and from the services becoming unavailable because I lost a hardware token, which is why I like them
-
I like passkeys*
* resident, non-hardware-token-based public key authentication mechanism for websites and Android apps, not to be confused with other things also called "passkeys" indiscriminately
@whitequark
so, like, who has these things and how do they work? they send you a nonce and you sign it?i haven't seen this as an option on any site or within keepassxc but I haven't been looking either.
-
@whitequark
so, like, who has these things and how do they work? they send you a nonce and you sign it?i haven't seen this as an option on any site or within keepassxc but I haven't been looking either.
@dlakelan you have to enable it within the keepassxc browser extension; most major webtech companies (starting with google) have been pushing passkeys for a while
cryptographic details are explained on a high level here: https://www.passkeys.io/technical-details
-
all of my passkeys* live in a KeePassXC database and I am both safe from phishing and from the services becoming unavailable because I lost a hardware token, which is why I like them
@whitequark
I get the lost hardware token situation which is bad, but IMO the underlaying issue is that there's not many services that accept more than one hardware token which is a shame. Having at least two token registered, where one is with somebody at all time and the other one in a safe and is never out unless the first one is missing, would fit many threat models (not all, granted) -
@whitequark
I get the lost hardware token situation which is bad, but IMO the underlaying issue is that there's not many services that accept more than one hardware token which is a shame. Having at least two token registered, where one is with somebody at all time and the other one in a safe and is never out unless the first one is missing, would fit many threat models (not all, granted)@magnetic_tape I agree with this in principle but personally since the effort to register/replace one hardware token is already too high, two is worse, not better
-
@dlakelan you have to enable it within the keepassxc browser extension; most major webtech companies (starting with google) have been pushing passkeys for a while
cryptographic details are explained on a high level here: https://www.passkeys.io/technical-details
@whitequark
got it. my impression was these required some TPM and or proprietary stuff from windows etc I was treating them as trash. but if keepassxc can be the secure store I am on board -
@whitequark
got it. my impression was these required some TPM and or proprietary stuff from windows etc I was treating them as trash. but if keepassxc can be the secure store I am on board@dlakelan a lot of people have this misconception thanks to some enormous communication failures by the big tech companies. the underlying technology is fine, it's just described in a completely unhelpful and misleading manner
-
@dlakelan a lot of people have this misconception thanks to some enormous communication failures by the big tech companies. the underlying technology is fine, it's just described in a completely unhelpful and misleading manner
@whitequark
yeah my impression was a third party holding keys or proprietary hardware stuff was how they work. if you think I'm gonna let someone else have all my keys then forget it. but yeah I'll be looking for the keepassxc browser extension settings now... thank you for clarifying this -
all of my passkeys* live in a KeePassXC database and I am both safe from phishing and from the services becoming unavailable because I lost a hardware token, which is why I like them
@whitequark you can still lose your KeePassXC database or missync it
-
@whitequark you can still lose your KeePassXC database or missync it
@lnl i have hourly backups and multiple replicas within a literal arm's reach
-
all of my passkeys* live in a KeePassXC database and I am both safe from phishing and from the services becoming unavailable because I lost a hardware token, which is why I like them
@whitequark same here.
-
all of my passkeys* live in a KeePassXC database and I am both safe from phishing and from the services becoming unavailable because I lost a hardware token, which is why I like them
@whitequark I want to like them, but when I recently went to go register a different hardware token to my Google account it decided that Firefox on Linux isn't supported to register a passkey, so I got locked out. I'm now in the process of removing my passkeys from other accounts since I can't trust them. That and Microsoft's dark pattern of forcing you to enroll one on login if you don't have one.
That being said, I also want a clean export opportunity. The fact that KeePassXC supports them gives me a little hope but I would like a format that I can export, archive, and import in to another program without having to do some double fiddly import/export on my phone or whatever. I think the latest Apple iOS version lets you transfer between apps using their own propitiatory process but I want something cross platform.
-
@whitequark I want to like them, but when I recently went to go register a different hardware token to my Google account it decided that Firefox on Linux isn't supported to register a passkey, so I got locked out. I'm now in the process of removing my passkeys from other accounts since I can't trust them. That and Microsoft's dark pattern of forcing you to enroll one on login if you don't have one.
That being said, I also want a clean export opportunity. The fact that KeePassXC supports them gives me a little hope but I would like a format that I can export, archive, and import in to another program without having to do some double fiddly import/export on my phone or whatever. I think the latest Apple iOS version lets you transfer between apps using their own propitiatory process but I want something cross platform.
@gibwar I think sites can and do sometimes place additional (mostly ridiculous) requirements, Google being the main one in my experience; but then if you don't trust the website it's kind of a lost cause to expect it to reliably authorize you
KeepassXC does let you export passkeys but I can't tell if it's a standard format or if there is even a standard format
-
@whitequark
yeah my impression was a third party holding keys or proprietary hardware stuff was how they work. if you think I'm gonna let someone else have all my keys then forget it. but yeah I'll be looking for the keepassxc browser extension settings now... thank you for clarifying thisThe downside of a pure software implementation is that a kernel vulnerability can still exfiltrate all of your keys. Hardware (including TPM)-based implementations are robust against this because the kernel can ask the device to do the signing, but that only allows online attacks: while someone compromises your machine, they can log in as you, but they can't exfiltrate your credentials.
Apple's design is nice because the keys are resident only in the secure element, but they do have a flow for copying them to another secure element (encrypted with a key that's negotiated during the exchange), but that locks you into their ecosystem.
The problem that they're trying to solve is a very hard one: How do you make it easy to copy your keys to another device but make it hard for a malicious person to force or trick you into copying the keys to their device? This is relatively easy within a closed ecosystem, but it's much harder to do in an open model.
-
The downside of a pure software implementation is that a kernel vulnerability can still exfiltrate all of your keys. Hardware (including TPM)-based implementations are robust against this because the kernel can ask the device to do the signing, but that only allows online attacks: while someone compromises your machine, they can log in as you, but they can't exfiltrate your credentials.
Apple's design is nice because the keys are resident only in the secure element, but they do have a flow for copying them to another secure element (encrypted with a key that's negotiated during the exchange), but that locks you into their ecosystem.
The problem that they're trying to solve is a very hard one: How do you make it easy to copy your keys to another device but make it hard for a malicious person to force or trick you into copying the keys to their device? This is relatively easy within a closed ecosystem, but it's much harder to do in an open model.
@david_chisnall @dlakelan for sure, there is a tradeoff; in my nearly 20 years of actively being on the Internet I've been phisned 0 times and stranded in a country whose language I don't speak because of a stupid 2FA login issue... significantly more than that. so I don't value security all that much, and I think the focus on preventing key exfiltration at all costs (including a significant cost to availability) is both myopic in general and too easily turned anti-end-user
-
@david_chisnall @dlakelan for sure, there is a tradeoff; in my nearly 20 years of actively being on the Internet I've been phisned 0 times and stranded in a country whose language I don't speak because of a stupid 2FA login issue... significantly more than that. so I don't value security all that much, and I think the focus on preventing key exfiltration at all costs (including a significant cost to availability) is both myopic in general and too easily turned anti-end-user
With Catherine 100% here. The number of times that I've had my Linux laptop or desktop kernel compromised is ZERO in 30 years while the number of times I've been locked out of my brokerage account because of a failed piece of hardware that was the only hardware 2FA they allow is non-zero in the last year. It would be significantly easier to catfish the fallback security overrides with the brokers on the phone than it would be to kernel compromise my infrastructure.
-
@gibwar I think sites can and do sometimes place additional (mostly ridiculous) requirements, Google being the main one in my experience; but then if you don't trust the website it's kind of a lost cause to expect it to reliably authorize you
KeepassXC does let you export passkeys but I can't tell if it's a standard format or if there is even a standard format
@whitequark It doesn't do it any more, but when I registered my Yubikey as a second factor on my Google account, it would for quite a while prompt me to use it as a standard passkey (as a replacement for, not in addition to, my password). So that has certainly diminished my view of their implementation.
-
I like passkeys*
* resident, non-hardware-token-based public key authentication mechanism for websites and Android apps, not to be confused with other things also called "passkeys" indiscriminately
@whitequark I'll be honest that I don't. I've set them up for a few accounts, and universally regret it.
The reliability of logging in with them seems to be abysmal. The implementations on some major websites seem very sketchy, and then my PW manager and my browser sometimes fight over who should be prompting me to use a passkey. I would estimate that ~50% of the time I try to use them it fails, and then I get buggily transferred into some kind of backup login flow.
-
@whitequark I'll be honest that I don't. I've set them up for a few accounts, and universally regret it.
The reliability of logging in with them seems to be abysmal. The implementations on some major websites seem very sketchy, and then my PW manager and my browser sometimes fight over who should be prompting me to use a passkey. I would estimate that ~50% of the time I try to use them it fails, and then I get buggily transferred into some kind of backup login flow.
@whitequark I share your desire for availability, but I've mostly achieved that by using 2fac authentication code generator apps, which I have set up on redundant devices.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@jaredwhite longtime fan of your podcasts, Jared! I still keep "Just a Spec" in my podcast app wishing for new episodes 🤗
-
@UltimateHackingKeyboard
Custom-shaped keys and row stagger? Naah
-
@krans@mastodon.me.uk That's a real and legitimate grievance, but it's a different argument from the one we were having.
Your employer using LLM translation to cut costs on documentation for a massive Korean customer (while having the resources to do it properly) is a decision made by someone with power, to save money, at the expense of Korean users. That's worth being angry about.
But I'm an individual trying to participate in a public conversation. I can't hire a personal interpreter every time I want to respond to a post. The choice I actually face is: use available tools, or stay silent. Those aren't the same situation, and the same tool can mean very different things depending on who's holding it and why.
If anything, your example reinforces the point. The problem isn't the tool, but it's who gets to decide when it's “good enough.”
-
Epilogo tristissimo. Quanto tempo passato nei reparti della loro libreria.
Hoepli, l’assemblea dei soci decide la messa in liquidazione
https://www.ilsole24ore.com/art/hoepli-l-assemblea-soci-decide-messa-liquidazione-AILzlksB
-
@Blogsdaseguire son due lavori diversi e delicati.
Competenze, non di studio, ma di pratica professionale, diverse.
-
-
@hongminhee My employer is perfectly capable of affording to translate our product manuals into Korean professionally — I'm here in Korea right now supporting a *massive* customer.
Instead our official policy is that Korean users will be fed LLM slop that our tech writers won't even attempt to read and validate.
That's exclusion and condescension packaged as providing access.
-
@krans@mastodon.me.uk The analogy is structurally interesting, but I think it breaks down at a crucial point.
With tax credits, the argument is that the subsidy lets employers off the hook—pressure that would otherwise force wages up gets absorbed by the state instead. The discomfort falls on capital, or at least that's the intent. But when you apply the same logic to language access, the discomfort doesn't fall on the Anglophone center. It falls on the people who were already excluded. The implicit suggestion becomes: non-English speakers should communicate less fluently, so that English speakers are eventually pressured into… what, exactly? Learning Korean? There's no mechanism there.
The deeper problem is that “lowering the bar for communication in English” is not the same thing as accepting English hegemony as permanent. I use these tools to participate in a conversation that would otherwise exclude me. That's not capitulation—it's the same logic as using a wheelchair ramp. You don't refuse the ramp because its existence lets architects keep building stairs.
The structural critique of hegemony is real and I share it. But it shouldn't cash out as advice to the marginalized to make themselves less legible. That's a cost I'm not willing to ask people to pay on behalf of a structural shift that may never come.
