25 ms·

Passkeys will come at a cost

• lusttforlife1 3y ago
  [dead]
• happyjock1 3y ago
  [dead]
• happyjock1 3y ago
  [dead]
• morelight11 3y ago
  [dead]
• morelight11 3y ago
  [dead]
• dante81 3y ago
  [dead]
• saulrh 3y ago
  That's a rather uncharitable take on the situation. I'll propose an alternative: If you want to take advantage of the new auth standard that will eliminate weak passwords and password reuse (thereby preventing 99% of casual account break-ins), you'll have to spend $30 to upgrade off the legacy yubikey you've been coasting on since 2013.
  • taeric 3y ago
    This doesn't really change much, though? My keys can only have 25 resident keys on them, and I also have more than 25 passwords stored in my password manager.
    • conradev 3y ago
      Password managers can store passkeys. I plan on storing passkeys in a password manager for most accounts, and then moving the few that matter to be resident keys. The theoretical advantage here is twofold: - Passwords are not guessable any longer - Password managers don't expose secret material in normal operation, because they sign requests with keys stored in TEEs (i.e. most modern devices have an embedded security key)
      • deleted 3y ago
        [deleted]
      • taeric 3y ago
        If passkeys become defined as resident keys, is this still true? And if this is acceptable, honestly, do we need a new standard? Password managers exist today. Such that I already do what you are suggesting here with passwords. Does it really become much more secure by the move to passkeys?
        • deleted 3y ago
          [deleted]
        • ericjmorey 3y ago
          Passkeys are for the people that don't even use password managers outside of what Apple or chrome provides by default if at all. Passkeys are trying to eliminate those ad hoc solutions by providing a different system. The transition will be slow and messy requiring most people to use passkeys and passwords (and maybe password managers) for a while.
          • taeric 3y ago
            But if the passkeys are copyable off of where you are storing them, then I'm not entirely clear on how they truly up the security? I mean, I get the obvious ways that a challenge system is better than a bearer token. But I feel a ton is lost as soon as you move to the exportable keys. Love to see an exploration on these topics. I confess I have not been following them much, lately.
  • vorpalhex 3y ago
    Is there a clear path to a yubikey device supporting 1000+ resident keys and doing so well in the near future? What does the cost look like? Are we talking $50 or $500?
    • radicaldreamer 3y ago
      I'm not sure why current keys cost so much...
      • RandomBK 3y ago
        My hunch is low volume and an enterprise-leaning customer base. Engineers aren't cheap, and those who can build security-sensitive products even less so. When I bought a (single) Yubikey from their website late last year, it was Fedexed to me directly from their Palo Alto downtown office, not some distribution center in the middle of nowhere. That can't be cheap.
        • darthwalsh 3y ago
          If you order a key and it comes from an Amazon warehouse, are you going to be worried about a supply chain attack? Maybe that's a benefit of sending by direct FedEx?
          • simooooo 3y ago
            When I bought mine they (current owners) were actively advising against buying from Amazon. But who knows. Probably very unlikely
    • saulrh 3y ago
      Presumably Yubico's upgrade path is to tweak the form factor slightly so they can fit more than a few kb of memory into the thing. I know that it's possible, I can buy 50GB flash drives in the micro yubikey form factor, the ones that are just a rectangle of plastic that fits in under a USB-A port's tongue, and they only cost like $10. So it's probably just something that Yubikey needs to design into the next gen of keys, and I suspect it won't make them cost much more than $5 more than the last gen.
  • kj4ips 3y ago
    I just looked a the technical manual for the 5 series, and it only supports 25. I only have two right now, but I have way more than 25 TOTPs. I don't know what the Bio FIDO ones have, but if it is similar, YubiCo may not have a product well placed for a large number of RKs. ~Edit: The Bio's have the same limit of 25
    • mixmastamyk 3y ago
      I think the FLOSS keys can handle more than that. But, I'd probably separate work and personal accounts to different pairs of keys anyway.
    • radicalbyte 3y ago
      As matthewaveryusa says above, you can have the key on the Yubi generate then encrypt the private key; that encrypted private key is then stored on mass storage (synced to iCloud etc). Then to use it you supply the key + data to sign the auth challenge. My issue then is that these keys allow total tracking. We need hardware implementing more complex and privacy protecting schemes (BBS+ etc).
  • gruez 3y ago
    Why should I be forced to upgrade? Non-resident keys also eliminate weak passwords and password reuse. Using resident keys only add marginal improvement (ie. you can plug in a key and the service knows which account it belongs to), and that doesn't seem like a good justification to deprecate all the existing authenticators in use today.
    • pornel 3y ago
      The number of existing old yubikeys is absolutely miniscule compared to the number of people who aren't using any keys yet.
    • joshgachnang 3y ago
      Maybe not for us, but for the vast majority of users, they'd pick not having to remember a username OR password for sure.
      • Aeolun 3y ago
        It’s also make pickpocketing a lot more lucrative if you can grab someone’s wallet and have immediate access to their bank account.
        • gooseyman 3y ago
          I had never considered this. Somewhat terrifying IF no biometric/pw attached. I expect most people will store on phone, thus it won’t be a huge issue.
          • froggit 3y ago
            Would this not lead back to "losing your phone = can't log in anymore = buy a yubikey"?
  • DangitBobby 3y ago
    Can you give me a high level description of why passkeys won't work with my current hardware key, and then explain why they went with that implementation instead of one that works with my current hardware key?
    • runiq 3y ago
      `rk=required` means your hardware is required to store each and every derived key, not just the master key, all in the service of you not needing to remember your username anymore. Current security keys can handle a couple dozen derived keys at most, _if_ they can handle any at all. This flies in the face of previous promises where 'every key can handle an unlimited amount of accounts'. In my eyes, this looks like a big push towards phones as passkeys, and nothing else. Would fit with the Bluetooth sync strategy as well.
      • BillyTheMage 3y ago
        As someone who doesn't and won't ever have a mobile phone, I can't comprehend why things are going in this direction.
        • pulpfictional 3y ago
          Because almost every human who has digital accounts does.
        • delfinom 3y ago
          Well, 1984 and Fahrenheit 451 were warnings of the world we are slowly heading towards.
      • DangitBobby 3y ago
        I guess that means passkeys are DoA for me.
  • cuu508 3y ago
    My worry is in the future there may sometimes be no other option than to take this "advantage". If a site implements the new auth standard, will it also keep the current username/password/2fa as an alternative option?
    • JohnFen 3y ago
      I think that probably depends on popular adoption. If going passkey-only causes a significant reduction in users being able to access the service, then there will always be a non-passkey option. Personally, I think there is significant friction to adopting passkeys, so there is little risk of being forced into using them in the near future. Longer term, though, I have no idea.
  • dathinab 3y ago
    I would go as far and say it's a too charitable take. Shared residual keys _should not exist_ (outside of short term temporary usage, e.g. not 2FA/FIDO). They are a liability, they are a security risk, they promote bad security practices. Best example TOTP (which from a security POV is quite flawed). You don't want to ever share the shared secret across devices (or back it up) but due to it being possible and flawed 2FA implementation being the norm not the expectation you are kinda forced into it. And as thinks look now passkeys will go into the same highly flawed user hostile direction.
    • 0cf8612b2e1e 3y ago
      > You don't want to ever share the shared secret across devices (or back it up) Hard disagree there. I do not feel comfortable unless I can backup a key. Phones get lost/broken/stolen all the time. Is it less theoretically secure? Sure, whatever, but I am not James Bond.
      • dathinab 3y ago
        you don't need to backup a shared secret to gain exactly what you get from backing up a shared secret, except more secure you have a backup of a _different_ secret with a similar degree of "authority" (or if it's "copyable" with the only authority to be used for restoring 2FA once or similar) then if you backup gets stolen you can just go into you account management API and disable/delete/flag it, in that case even if encryption is broken as long as you act fast enough the damage is trivially and conveniently contained (e.g. some password managers had insecure backup/storage in the past) with the same key not only do you have to disable it, you first have to create a new key and then sync it to all your new devices and backups and then disable the old key, which isn't grate if you have more then one device or some of you devices are temporary out of reach (e.g. you one a business trip) it's like reintroducing the "physical" problem of having to replace all locks when you loose your house key in a situation where you could have all the benefits one key per lock and a different door for each person (i.e. device) without any of the overhead/drawbacks this would normally introduce
        • 3y ago
  • somehnguy 3y ago
    Someone using easy to guess simple passwords probably isn’t using a Yubikey and also likely has no interest in getting one at all. Those 2 categories are very different people.
  • simooooo 3y ago
    Well no, because a brand new yubikey 5 has the same limit
• upofadown 3y ago
  This raises a question for me. Why are hardware keys so limited in storage? How much extra would it cost to have a secure processor that could access a mass storage device also built in to the key. This mass storage device would of course be strongly encrypted by the secure processor with a key that would be erased at the same time everything else is erased.
  • radicaldreamer 3y ago
    I think this is a conscious design choice made to keep these devices as "dumb" as possible. As soon as you add storage, you start opening up the same surface for vulnerabilities as any other storage device, next comes compute and eventually you have a full fledged computer instead of a dumb yubikey.
  • morelisp 3y ago
    I don't know if this is the only reason, but mass storage devices seem to have a ludicrously unacceptably high failure rate and short lifetime to be something I key large potions of my life to.
    • gruez 3y ago
      Usb drives have ludicrously high failure rates because they're optimized for cost rather than reliability. Other forms of flash memory (eg SSDs) are quite reliable, despite having much more flash chips (and thus points of failure).
    • tzs 3y ago
      Mass storage for resident keys would not need to be written to often. Just when you create an account at a new site. I'd guess that would greatly lower the failure rate.
  • taeric 3y ago
    I'm sure they can go up in storage, but the more you add to them the more you increase the chances of fault. And these things currently take a hell of a beating before they don't work anymore. There is also something a bit more auditable about a smaller storage. Though, even the small sizes are probably pushing the bounds of what can realistically be audited nowadays.
• dathinab 3y ago
  > rk=required why does that even exist, that shouldn't be an option this stuff is why I have been so worried/skeptical about Passkeys and the people related to it. They have the responsibility to design their protocols to not be a tool well suited for big coperations like Microsoft to seriously mess up security, compatibility and enact all kinds of "bad faith" market practices to kill competition. But instead again and again in their posts what they write, publish and explicitly how they do it is more like "fuck you, we make abuse extra easy". It's not just this nonsense about residual keys, but also e.g. how attestation is handled (and can be trivially abused to kill companies).
  • ballenf 3y ago
    > how attestation is handled (and can be trivially abused to kill companies) What's this issue?
    • Vecr 3y ago
      In the limited set of attestors anyone would use/accept, no one would attest for you. It could target clients, services, or both.
    • marwatk 3y ago
      Hardware tokens (Yubikeys, etc) are signed by their vendor. They support attestation which allows q site to disallow vendors not in a white list. Some banks (Vanguard was/is one) actually enforce this preventing all but a handful of hardware keys from working with their 2FA.
      • dwaite 3y ago
        From https://www.chromium.org/security-keys/ https://www.chromium.org/security-keys/: > Chrome’s users have an interest in ensuring a healthy and interoperable ecosystem of Security Keys. To this end, public websites that restrict the set of allowed Security Keys should do so based on articulable, technical considerations. They should regularly update their set of trusted attestation roots that meet their policies (for example, from the FIDO Metadata Service) to ensure that new Security Keys that meet their requirements will function. > ... > If Chrome becomes aware that websites are not meeting these expectations, we may withdraw Security Key privileges from those sites. If Chrome becomes aware that manufacturers are not maintaining their attestation metadata we may choose to disable attestation for those devices in order to ensure a healthy ecosystem. e.g., it is acceptable for a bank or other public-facing site to say "we'll only accept authenticators which have been L2 certified via this independent program that maintains an up-to-date list". It is not acceptable to say "we'll only accept this one vendor's products, and maybe another vendor after a 2 year audit if we feel a business need". And Chrome has stated publicly that they will remove some or all of the WebAuthn API from your domain if you do so.
• jefftk 3y ago
  For figuring out whether I should be worried about this, how can I check how many resident keys my security key can handle?
• Zamicol 3y ago
  We're working on an open source alternative to Passkeys starting with Coze https://github.com/Cyphrme/Coze https://github.com/Cyphrme/Coze. We have not yet published our next steps, but we will soon.
• wernerroland710 3y ago
  [dead]
• goalieca 3y ago
  A private key for curve p256 is 32-bytes. Let's say we have associated metadata (hostname, whatever) and round that up to 1KiB per key. A typical user has around 200 accounts but let's give room for 1000 since powerusers love hardware keys. That's 1000 x 1KiB = 1MiB. This is totally within our technical capabilities. It's not uncommon for small radio coprocessors to have more storage on die. Even old school SIM cards have 256KiB worth.
  • kccqzy 3y ago
    You aren't buying a USB mass storage device when buying a security key. Completely different product, different requirements.
    • gtvwill 3y ago
      No I'm buying a USB minimum storage device with a micro controller embedded and potted under some very hard plastics. Very much the same thing. Function different yes, manufacturing when it comes down to it. Exactly the same. I could print wafer for your security key, I could print wafer for your flash memory. IC's arent manufactured differently in security keys to normal IC's. The product is the same silicon just doped differently to make a different ic/circuit. its a small computer in a USB. it does a limited function. Stop making them out like they are some wizard stick fancy stuff. You can setup a ESP32 as a security key if you want.
      • drdaeman 3y ago
        > Stop making them out like they are some wizard stick fancy stuff But they are. Tamper resistance is a thing, and it's different from the engineering perspective. That's why Yubikey and FST-01 are entirely different beasts. Most folks probably don't need tamper resistant hardware, though. I mean, they've been doing fine with sticky notes on a monitor...
        • gtvwill 3y ago
          Most folks are better off with notebook in the table next to their bed/desk for passwords than anything else. Whens the last time you got broken into at home and someone stole your diary? Whens the last time you read about someone getting breached because they had their passwords written down in a book next to their desk? Pretty much never. Whens the last time someone got breached storing their PW somewhere digital? well shit probably a dozen happening every second and a few dozen breaches somewhere in the world before your done reading this.
• Ajedi32 3y ago
  Is it even a good idea to use physical security keys as passkeys in the first place? Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. IMO physical security keys are better left as second-factor authentication, to be used _in addition_ to passkeys in certain high-security contexts; particularly where resistance to cloning is a critical feature. Resident keys aren't necessary for that use case since by the time you get to the second factor step you already know the account you're trying to log into. Further, the autocomplete functionality afforded by resident keys is important for the UX of passkeys in my opinion. I don't think it makes sense to sacrifice that in order to to retain backwards compatibility with a small number of keys that only security nerds use. (Though if there were a way to maintain that UX without using resident keys I'd be cool with that.)
  • the_snooze 3y ago
    When I use a Yubikey for passwordless authentication (FIDO2), it challenges me for a PIN before asking me to touch the device. If I give it too many incorrect PINs, the Yubikey locks up and requires a device reset, which invalidates all previous registrations to use that key for authentication. It doesn't seem like a big deal if someone steals my hardware token. https://support.yubico.com/hc/en-us/articles/4402836718866-Understanding-YubiKey-PINs https://support.yubico.com/hc/en-us/articles/4402836718866-U...
    • e40 3y ago
      That's not how my YK works. When I go to a new computer and login to my Google account, it asks me to insert it and press the button. Did I configure it wrong?
      • the_snooze 3y ago
        If you're only using it for two-factor authentication, you don't need a PIN. But when I tried to registered mine as a passkey (passwordless authentication), my browser prompted me for a PIN. I didn't have one set at the time, so it kept rejecting whatever PIN I gave it. I had to use the YubiKey Manager to set a PIN before I could register it as a a passkey. https://www.yubico.com/support/download/yubikey-manager/ https://www.yubico.com/support/download/yubikey-manager/
• dcow 3y ago
  I think the author is taking the argument too far and also not being precise in their language which is the exactly the "passkey hype" they fault Apple and "Fido" for doing. Maybe just cut the exposition out of the article I don't think it helps the argument and makes the author sound angsty rather than contribute to the well thought out considerations towards the end. Point being, I think there's a point but it was hard to get there. Anyway: 1. Passkeys, to me, are the private key. It doesn't matter whether it's resident or not, or whether it's device bound (non-extractable) or not, whether a "genuine" authenticator made the signature or not, or whether user presence was verified or not. A Passkey is not the authenticator/library as the author claims, and it's not the protocol or some set of protocol features. 2. The world is better off if everyone uses WebAuthN instead of passwords irrespective of how the passkey is stored. Full stop. So let's start there. Additionally, where I diverge from the author, I don't think preserving the sanctity of decade old hardware keys which only conform to older versions of a TPM spec is of paramount concern, either. The author's fixation on that is a little strong, but it's understandable. 3. I don't think you need to discourage resident keys. But I also don't think RPs need to care about whether the key is resident or not. Let the library on the user's browser/device decide how to find the key. An RP wanting to verify user presence is one thing, but saying this key must be stored with the user IMO is a step too far. It's likely that RPs don't even care and are just avoiding wanting to store some extra bytes in their DB. Or their security team overly cares and is making up reasons why the RP needs to require resident keys (IMO bad security take all things considered) but I can see the tin-foil angle). So I think the simple solution is probably to, for WebAuthN specifically, deprecate the ability for the RP to specify that it needs a resident key. Problem solved. Oh and while we're at it, forbid hardware attestation. The web doesn't need that. If rk=required and hardware attestation need to exist for tightly controlled enterprise use cases then whatever, but relegate them there preferably in some non-required protocol extension.
  • dathinab 3y ago
    no not far enough residual keys are IMHO a security misdesign and shouldn't exist but now the industry hype is pushing to make the the de-facto mandatory way
    • 3y ago
• jabbany 3y ago
  I wonder if there could be a middle-ground software solution here? E.g. A piece of software (like a passkey manager or keychain service) that transparently simulates a resident key store by using an encrypted database that resolves services to credential IDs which are then forwarded and unlocked by a non-resident hardware key. One could then conceivably still sync the database around (using whatever services or method you want), and even if the encryption of the database were somehow broken, it wouldn't be the end of the world, as the actual signing is still done by the hardware key. (Disclaimer: I don't know enough about the actual protocols to judge if the above is actually technically feasible, but would be curious if it is)
  • dcow 3y ago
    We absolutely need to allow soft implementations to exist. The platform providers are already doing this. You should be able to use your password manager as a passkey manager. The RP shouldn't dictate any of this and the protocol should actively resist platforms locking people in to (their) blessed implementations.
• asdff 3y ago
  Passkeys make no sense. Its selling you something you already own, since a fingerprint or a retina scan makes a fine good two factor as well.
  • microtonal 3y ago
    Someone gains access to a Passkey. You generate a new Passkey and replace the registered Passkey for the server. Someone gains access to your fingerprints or retina scan... Game over?
    • asdff 3y ago
      Someone gains access to your passkey once, they can probably do it again I'm thinking.
  • wongarsu 3y ago
    In 2014 the fingerprints of Angela Merkel and the German Defense Minister were "cloned" by taking high resolution pictures at a press conference. Against targeted attacks, using something that's readily visible on your person isn't the best idea.
    • wkat4242 3y ago
      Yeah or that you leave impressions of thousands of times a day :) It's good as an extra factor but not as authentication by itself.
  • Nadya 3y ago
    What's your game plan for replacing your retina or fingerprints if compromised? Biodata is the least secure because it can't be easily changed and the technology already exists to compromise them.
    • secabeen 3y ago
      Compromise isn't even the most common issue, it's your incapacity or death. Your relatives need some way to get into your accounts when you can't.
• matthewaveryusa 3y ago
  Is this really how resident keys work? I thought the common use of all secure enclaves is to save keys outside the enclave, but symmetrically encrypted with a master key in the enclave, bypassing the memory limits. I can see the downside for yubikeys/usb enclaves being the keys are then no longer accessible, but for embedded enclaves this should never be a problem.
• simultsop 3y ago
  Everything comes at a cost. If a company has breaching issues to leak passkeys they will have bigger troubles. As many suggest the main problem this attempt of FIDO alliance tries to solve is "Passwordless accounts". Trusting passwords to password managers is a problem at raise. I guess this solution would mitigate password mess for next 10 years. Then by moving forward I believe tech sector would also be able to satisfy security guru's too, hopefully.
• dontupvoteme 3y ago
  Why are organizations that aren't NIST trying to do anything fundamentally in cryptography?
  • kj4ips 3y ago
    This is more of a use of cryptography for authn, not designing the cryptosystem itself.
  • dontupvoteme 3y ago
    why is this rated -1? NIST is right up there with DARPA and tennis in terms of unassailable institutions.
• microtonal 3y ago
  Since Apple didn't actually define it, this left a void for our thought leaders to answer that question for users hungry to know "what indeed is a passkey?". I have always understood that Apple defined a Passkey to be a key pair that is synced through iCloud Keychain. Even their WWDC 2021 presentation distinguishes passkeys to be different than security keys because they are "always with you" (the device sync aspect) and "recoverable". I think the definition was later extended to other cloud sync methods. I also think the article makes the wrong trade-offs. Security keys are not important [1]. They are only used by a negligible number of technical users and a small number of companies that really care about security. Getting people off passwords is necessary for improving web safety and 99% of the population is never going to use security keys unless they are forced to. Passkeys do have a good chance of getting people off passwords, especially with deep OS integration. We shouldn't optimize authentication for that 1% or less because they'd be running out of resident key slots. [1] I am the owner of 3 Yubikeys, 3 Yubico security keys and a SoloKey.
  • ptravers 3y ago
    passkeys are really defined by the FIDO Alliance Based on FIDO standards, passkeys are a replacement for passwords that provide faster, easier, and more secure sign-ins to websites and apps across a user’s devices. Unlike passwords, passkeys are always strong and phishing-resistant. [1] https://fidoalliance.org/passkeys/ https://fidoalliance.org/passkeys/
    • a_random_canuck 3y ago
      This does not tell me what a passkey actually _is_. The marketing around passkeys is absolutely infuriating.
      • gre345t34 3y ago
        Tell me about it. All of the terminology around FIDO is super confusing, and FIDO themselves make no effort to clarify or acknowledge the confusion. Everyone (including Yubico) uses the terminology incorrectly in a way that makes it super hard to get to the bottom things.
• spiznnx 3y ago
  I see a lot of comments mentioning "residual keys". Is that the same as the "resident keys" the article talks about?
  • Dylan16807 3y ago
    I think you mean you see three comments by the same person mentioning that. They're just using the wrong word.
• zaroth 3y ago
  They really just can’t get out of their own way in screwing this stuff up… Resident keys allow the browser to query the secure element for a list of usernames for a domain. It’s a nice feature, but you have to setup the protocol to reliably fallback to non-resident keys on secure elements that are space constrained. But then they came up with these resident key “preferred” and “discouraged” keywords which are sent by the site?! And then the various clients all interpret them differently so there’s no obvious way for a site to let clients with secure elements with practically unlimited storage to opt-in to resident keys while limited storage secure elements stick with the wrapped/derived key. The current situation is if you send “preferred” you’ll fill up limited space YubiKeys, and if you send “discouraged” then Androids with practically unlimited storage won’t use resident keys. Clients should decide based on their capabilities and should always opt for residency if they have unlimited storage. The protocol should have been defined with just a boolean ‘required’ field for residency, which would only be used in highly unusual circumstances (which I’m not sure what those are — what’s the justification for a site requiring residency?) One day we’ll get it right…
  • cameldrv 3y ago
    What I don't get is why can't the browser just maintain a list of accounts that it knows work with the non-resident key? The username is not secret information, so why does it need to be held in the key?
    • drdaeman 3y ago
      Because a key could be used with a brand new browser on an OS or machine that you've never used before. And the problem is that it's not usernames, they're IDs, not intended for humans, so manually typing those is not exactly a good idea.
• a-dub 3y ago
  this is probably a dumb question, but why not just store a secret seed that is used with an on device prng to generate as many secrets as you need where a sequence id gets shared with the counterparty?
  • wepple 3y ago
    how does authn happen here? RP sends ID and I respond with the secret code? that's subject to replay attacks.
    • kj4ips 3y ago
      It's a challenge-response with nonces. There is also the browser's role to ensure that a given RP's requests are marked with the origin (domain) they came from, so auth.example.com and auth.example.evil don't overlap. (U2F is mostly concerned about malicious sites, and less about malicious browsers and other nastyware)
  • kj4ips 3y ago
    I'm pretty sure that is how non-resident keys work on some platforms (like the first gen yubico U2F tokens). The main feature of resident (aka discoverable) keys is that the RP doesn't need to know anything about which key is about to be used, so it can just say "send me an auth for example.com", and the browser and key handle the rest. However, with non-discoverable keys, the RP has to provide a reference to the key, which could actually have encrypted private key matter in it.
• zb3 3y ago
  Any form of authentication based on "something you have, but can also lose" is fundamentally broken. Either I'll lose access if I lose the device, or their superior security doesn't matter because the weakest link has to be somewhere else.
  • TheFlyingFish 3y ago
    Wouldn't this include passwords? People lose those all the time. The proof will be in the pudding, but I suspect that widespread adoption of passkeys will make account lockout less common, rather than more, for the vast majority of people.
  • kmac_ 3y ago
    Just print backup codes or add second "drawer" key. The whole idea is great, but has several issues: very bad marketing, wierd configuration flow for average user, push for airdropable/cloud synced keys (this is a bad idea) and the most important one, the cost of keys.
• dandanua 3y ago
  Monopolies were shitting, are shitting and will be shitting on community standards. There will be no end to this until a radical change in the societal mindset.
• superkuh 3y ago
  HTTPS only like this blackhats.net.au site comes at a cost too. If there's a browser/server SSL mismatch the text becomes completely unavailable. While if it was an HTTP+HTTPS site I could simply visit the HTTP endpoint. Instead to protect against hypothetical downgrade attacks they've made their content inaccessible and effectively DoS themselves for a small fraction of visitors.
  • 8organicbits 3y ago
    > small fraction of visitors This site won't work on Windows 7 / Chrome 69 as it only supports TLS 1.3 [1]. I believe 5% of the web can't connect [2]. But the text on the site is for technically minded people and the content includes commands you should run and security configuration. Tampering of the content could be quite harmful. [1] https://www.ssllabs.com/ssltest/analyze.html?d=fy.blackhats.net.au&latest https://www.ssllabs.com/ssltest/analyze.html?d=fy.blackhats.... [2] https://caniuse.com/?search=tls1.3 https://caniuse.com/?search=tls1.3
    • superkuh 3y ago
      Tampering with the contents is quite unlikely. And anyone visiting a security site as a technically minded person probably has javascript disabled initially. Requiring HTTPS only for this is like requiring people wear bulletproof vests to visit your backyard BBQ. There is no doubt they are "safer". But it's also pretty silly.
      • tatersolid 3y ago
        > Tampering with the contents is quite unlikely No, it was shockingly common for ISPs and public WiFi to modify sites. And many did inject malicious scripts or redirect users to malicious sites in order to monetize.
• elzbardico 3y ago
  I think that 99% will use something they already have like an iphone, an Android phone, touch id on their mac books, or windows hello. Storage should not be a problem.
• bandrami 3y ago
  The difference between zero and one factor is infinite. The difference between one and two factors is huge. The difference between two and three is almost negligible. Except in Citrix-like situations where you're sharing the actual reader hardware, passkeys are only useful for a device you have physical access to, and that's already one factor. So in that sense they can replace passwords, I guess, but they seem like a strictly worse solution.
• wepple 3y ago
  > Are non-resident keys less secure? The answer provided by the author (TLDR: you'd have to break AES) is far from satisfying to me. With a resident key, the only thing an attacker on an endpoint could ever get is a challenge & a response to that challenge. It's more than nothing, but limits a lot of attacks. With non-resident keys, an attacker can not only do all kinds of offline attacks* against the HMAC and crypto, but also has a far better position of attack against the the security key: you've got decryption, HMAC, key parsing code all happening on untrusted data (if done correct, HMAC will have to fall first). Further, you've got twice the encryption happening on the key, which could provide a larger attack surface for side channel attacks. I'm not saying any of these are trivial or even feasible, just that "citation needed" for resident key == non-resident key, in terms of security. *if your idea of an offline attack of this nature is "break AES with a brute force" and that's about it, there's a lot more options
  • deleted 3y ago
    [deleted]
• stavros 3y ago
  Am I the only person who finds it unreasonable that security keys only have enough storage for 5-10 resident keys? Why can't I store millions of keys? What's that, 50 MB? Why isn't that standard?
• nathants 3y ago
  passkeys seem meh, but if they help fido2/webauthn spread then they are for great good. not your keys not your coins, except for passwords. the general public has been learning this for some time now due to endless crypto scams. plot twist, satoshi founded yubico!
• gtvwill 3y ago
  Gonna only say this once. Stop building your forts with only one wall and one gate. Build many walls to cross, many gates to open, observe the user through each of these. lol op assumes passkeys or pw's are the only lock being used to protect things. Well from a security implementation standpoint...I assume someone either you on the rust end or someone on the yubikey end is already a weak link and your password is probably already compromised. But thats ok. TBH from a security standpoint, yeah I expect your PW to be correct, but I also do assume that its not secret. Its only part of the parcel. I expect about a dozen other metrics to be correct too pending on how secure you need your stuff or how important the security is. If you don't tick most of these if not all of these boxes. I don't care if your password or passkey is right. Your not getting in. The pincode>push button on yubikeys is part of this. Your IP, your device ID, your TPM trusted data paths, the time of day your trying to make access, the frequency of it, the country of origin, the target your trying to get into, the wifi you are accessing this via....are all part of this. Stop being so old school about security and propping it up off one point of failure. Now this bit is going to be the real hard biscuit to bite for alot of folks, but Yes I get that its harder in web because you probably don't have the physical end of things under enough control that you can use those for your security checks/metrics as they are under user control, but maybe don't store super piss off secret data that needs to stay secret in systems like that. If your web app gets to X level of personal data/could be involved in X level of harm to society or its users if breached. Don't let people sign up without mfa, hardware keys and so on. Force users to detail more info about their fixed locations and regular usage areas and judge their access security on that. tldr I dont care if your PW is compromised its 1/X keys needed. I assume its compromised. I dont assume all other X keys are tho.
  • wkat4242 3y ago
    > Gonna only say this once. Stop building your forts with only one wall and one gate. Build many walls to cross, many gates to open, observe the user through each of these. Obviously that's better but if you make the user jump through too many hoops they're just going to pick someone else to do business with. This is why Fido is a good idea, it's not only more secure but also easier. In the security world that's kinda like magic, usually you're end up trading one for the other.
• TacticalCoder 3y ago
  > Obsession with passkeys are about to turn your security keys (yubikeys, feitian, nitrokeys, ...) into obsolete and useless junk. I'm sad about that too but I'm finding some relief in the fact that non cloneable / non shareable physical security keys aren't going to be totally obsolete though: they're supported by OpenSSH and shall probably be so for a very long time. Even Google teaming up with Microsoft teaming up with Apple cannot fuck that one up in the near future. Not that it's much of a consolation. But yup, it's really sad how a conglomerate of the biggest actors managed to fuck up security keys while riding on the security benefits non-cloneable keys do bring: "It's physical non cloneable non shareable security keys but better because... More convenient for they're actually not physical and actually cloneable and actually shareable". I saw it here on HN too on the various threads on passkeys: "It's better because it's more convenient". I won't post more because it'd be swear words.
• torstenvl 3y ago
  I'm not a security or crypto guy at all. I found this very difficult to follow, and I suspect others might too. My questions probably seem weird to someone with enough background context to understand the post, but I am getting wrapped around the axle every sentence or two. > It all comes down to one thing - resident keys. How/why? What's the connection to passkeys or HSMs? > we need to understand what a discoverable/resident key is Yeah okay... does this imply that all resident keys are discoverable keys? Or that all discoverable keys are resident keys? Or both? > You have probably seen that most keys support an 'unlimited' number of accounts. No. Does "keys" here mean passkeys? Or keys stored on HSMs? Or both? Or something else entirely? > This is achieved by sending a "key wrapped key" to the security key. Okay so an HSM can apply to an unlimited number of accounts because it can store... some kind of key wrapped in another key (of the same type? different type?)
  • dcow 3y ago
    It's a poorly argued point, agree. Essentially the author is arguing that the ability in the WebAuthN protocol for Relying Parties to be able to specify `rk=required` is considered harmful because it excludes tons of TPM hardware from being able to work as a Passkey wallet/db. I think most people in the comments probably agree. That doesn't excuse all the confusion the author creates by essentially bike-shedding the definition of passkey for half the essay.
    • torstenvl 3y ago
      I think the upshot is this: The hype around passkeys is high enough that basically all authentication layers are requiring passkeys when they're available. This is a problem because passkeys must be stored in the client-side authenticator (password manager, hardware token, whatever), some of which have very limited capacity for storing them. This is compounded by two problems: (1) Extant standards for storing these keys on hardware tokens don't allow deleting them individually, though this is changing in the newest standard; (2) Many current hardware tokens claim to have huge capacities, but this is based on a different challenge-response mechanism than passkeys. As a result, users will be pressured into using passkeys often, run out of precious passkey space despite thinking they have plenty, and then be forced to forego the benefits moving forward or reset and lose their keys. Is that more or less accurate?
• Melown 3y ago
  It's all about the FIDO2 hardware attestation. I'd rather use a FIDO2 authenticator with attestation. Call it a passkey or not, I don't want the to use the syncable passkeys without hardware attestation.
  • wkat4242 3y ago
    Apple doesn't do attestation so if you require that you're already leaving out the biggest platform. But it's a bad thing for self hosters anyway. Because parties will make exclusive deals or only wish to deal with authenticators they trust (eg that pay them for 'certification')
    • 0x4e53 3y ago
      At least for the enterprise - this decision should be up to the company. (i.e, flip a switch on your identity provider to enable or disable support for "no attestation") Some companies are comfortable with the idea of a two-factor method that can be airdropped to friends. Major organizations (AWS, among others) are not huge fans of passkeys for enterprise use. When passkeys released, our initial response at AWS was to give organization admins the ability to disallow passkeys. Overall, I think there are fixes coming across the board from Apple and the FIDO Alliance to address some of the early shortfalls of passkeys.
      • wkat4242 3y ago
        Well for the enterprise yes, but they shouldn't force these decisions on their customers. They can provide the total hardware package for their employees to sign in with anyway.
• NotYourLawyer 3y ago
  > The problem is that security keys with their finite storage and lack of credential management will fill up rapidly. In my password manager I have more than 150 stored passwords. If all of these were to become resident keys I would need to buy at least 5 yubikeys to store all the accounts How it is possible that THIS is the problem in 2023? Storage is cheap, tiny, and capacious. I feel like I’m reading an article from 1992.
  • makeitdouble 3y ago
    Isn't the physical key a whole computing device with high grade storage ? I can't imagine those using cheap consumer grade off the shelf storage parts.
    • NotYourLawyer 3y ago
      Whether it’s on-die or a separate chip, flash is just dirt cheap nowadays.
      • makeitdouble 3y ago
        Is it ? Looking at this for instance, we're still around 1 USD per GB for a reliable storage chip: https://www.amazon.com/Kingston-Industrial-32GB-microSDHC-Adapter/dp/B09CYH4KVG/ref=sr_1_4?keywords=Industrial+SD+Cards&qid=1689308792&sr=8-4 https://www.amazon.com/Kingston-Industrial-32GB-microSDHC-Ad...
        • NotYourLawyer 3y ago
          How much space does a key take though?
          • makeitdouble 3y ago
            Enough that it's an issue when you want to store them in a highly secure way ? I doubt that the yubico limited the number of useable keys and space available per protocol by sheer spite or trying to upsell larger "pro" versions that they never made. Using more space for encryption and other mechanism is probably a part of this, then it depends on how they allocate space (segmenting by category of data would totally be plausible for instance)
• wkat4242 3y ago
  I love this writeup. It explains a lot I didn't know about passkeys in a way that's easy to understand. As a total self host enthusiast with a prime interest in hardware tokens (I've been using smart cards to log in for decades) this is really a bad thing. I don't want to be dependent on Google or Apple or Microsoft. Absolutely not. There's also an extra factor the article doesn't mention: because passkeys are synced there's no need for the website to offer to enroll more than one key which makes using multiple keys difficult (needed for backup purposes) It finally explains how I can do usernameless work with M365 though on my Yubikeys. I hope a centralized solution comes out which allows us to use hardware backed tokens but still sync the resident keys using our own servers somehow. I know bitwarden is working on something but that's not good enough, it's not really token backed. It uses a master passphrase which is a big step back IMO.
• greatgib 3y ago
  In my opinion, this is a terribly shitty solution from a security point of view. A dream for government and companies like Apple an Google to control your digital life. With passwords, you are like "stateless", you can a private email account, or any account and pass a border, ... without anyone knowing that you have an account, forcing you to give access, extracting the access element from a hardware, or locking you out because you lost access to the device. Even if master keys and co would be stored on TPM, secure elements, ... it is just a matter of years and compute powers because some gov can access it. Most of the time it already proves that you have a credential for an account. Manufacturer of your machine or OS, can easily be forced by authorities to give access to the secure part. Willingly or not.
• 0x4e53 3y ago
  For context, we run a YC-backed passwordless company, and have rolled passwordless out at major organizations. While I think passkeys will definitely be the answer for consumer passwordless, I'm not sure this is quite reflected in the enterprise yet. Passkeys are wonderful for consumer use, because they're meant to enable your own ability to break glass, by backing up the credential to other devices. You can do this via iCloud (by default) or via things like Airdrop. Technically, the devices you share this credential to, cannot provide "attestation" - attestation is the "proof" that the keypair was created by a specific device (like a Yubikey, Apple Machine, etc). Manufacturers (like Yubico) ship a keypair / certificate onboard your key, that can't be extracted. There are no external methods to interface with this keypair - granting admins high confidence this is a real Yubikey. You can see where this starts to become a problem without attestation, and the ability to share the keys. Enterprises are not willing to inherit the risk of an airdroppable credential exposing access to a privileged employees' account. There is a non-risk of digital theft when it comes to a Yubikey. Ultimately - passkeys can't even be used to unlock your machines, or servers. FIDO2 (more importantly, OS developers) have a long way to go before we're done with passwords for good. Today, Yubikeys are filling this gap for most of the enterprise market, some of whom have spent multiple millions of dollars on hardware. Passkeys in their current state are going to be a hard sell.
  • androidbishop 3y ago
    yubikeys (5) can be used as passkeys
  • dwaite 3y ago
    >Passkeys are wonderful for consumer use, because they're meant to enable your own ability to break glass, by backing up the credential to other devices. You can do this via iCloud (by default) or via things like Airdrop. > Technically, the devices you share this credential to, cannot provide "attestation" - attestation is the "proof" that the keypair was created by a specific device (like a Yubikey, Apple Machine, etc). Manufacturers (like Yubico) ship a keypair / certificate onboard your key, that can't be extracted. There are no external methods to interface with this keypair - granting admins high confidence this is a real Yubikey. Passkey is not a technical term, but an experience term. So it somewhat falls apart when you use it for technical arguments. Apple supports passkeys. Android and Chrome support passkeys. Microsoft supports passkeys. Yubikeys supports passkeys. But the authentication process for user verification and the capabilities/restrictions around things like cloneability may differ wildly. A government agency may choose to support passkeys, but only when provided by a FIPS-certified authenticator which meets AAL2 requirements. Those won't come from Apple or Google, at least not today. An enterprise may choose to support passkeys that are generated via software/configuration provided by their MDM management product. Apple announced beta support for this. However, if you are doing government-to-citizen you may experience a lot of pain trying to mandate those particular hardware authenticators. It will be painful to convince citizens to spend $80+ USD on hardware. It will also be painful because web technologies are built around user choice, and WebAuthn API and user experience are unlikely to ever be optimized to help restrict user choice.
• dwaite 3y ago
  > A frequent question here is if non resident keys are less secure than resident ones. Credential ID's as key wrapped keys are secure since they are encrypted with aes128 and hmaced. This is incorrect. The strategy for how handles represent a public/private keypair is security-key specific. For example, Yubikeys shipped before firmware 4.4 used a different algorithm, and Solo keys use a third. Platforms may also ignore requests for non-resident credentials, and return a handle reference to a resident one instead.
• jojobas 3y ago
  Passkeys seem to be a prime case where the cure is worse than the disease.
• fuzztester 3y ago
  ELI5 Passkeys, Please https://news.ycombinator.com/item?id=36715358 https://news.ycombinator.com/item?id=36715358
• dmix 3y ago
  This is a bit unrelated to the harder crypto stuff but my mom called me freaking out she couldn’t get into her gmail. It turns out Google auto registered her new android phone with a passkey and made that the default Google login with a confusing passkey based interface (expecting her to know to click the second option to login via password or understand wtf a passkey is was too much IMO). It turns out when it said “passkey sent to android” the android never got any notification and I couldn’t figure it out after half an hour. You can’t even delete the auto registered passkeys. Nor turn off the default auth flow. Terrible UX by Google. I’m assuming it’s because her phone is some budget Samsung with a bastardized Android. Trusting those devices on a mass scale to run your auth system was dumb.
  • neycoda 3y ago
    Yep, this is how Comcast is for me. I never get the notification for the "registered device" even though it's a newish popular phone. I don't trust passkey because It relies on a certain device, instead of something you can just write down or save to a browser use on multiple devices. If I lose my phone, I can't get into my email to do anything else.
  • esperent 3y ago
    I have the same problem with Google 2FA. "We sent a notification to your S21". No, I'm holding my S21 in my hand, unlocked. About 1/3 of the time, there's no notification. Or it takes five minutes to arrive. This is only one of many problems I've had with Google recently. I went from haphazardly trying to avoid their products for privacy reasons to now putting max effort into minimizing my Google usage because everything they do is badly broken. I've just spent two weeks getting my business re-listed on Maps after it was flagged for no reason. Impossible to talk to a human. They give you a number to call on every support email, but it's for advertising support who can't do anything about a suspended business account and are very surprised (refuse to believe in fact) that the Google business team gives out their number for support. It took me half an hour of repeating the question in different ways for the Google Ads support woman to admit that there is no way to talk to a human about Google Business. Bitter? Hell, I'm an anti-Google evangelist now.
• NoZebra120vClip 3y ago
  I will not be silent until authentication works like this: https://youtu.be/-zVgWpVXb64 https://youtu.be/-zVgWpVXb64 Or until it works like this: https://youtu.be/rERApU26PcA https://youtu.be/rERApU26PcA And then logging in will look exactly like this: https://youtu.be/AJ6gdRfBW6c https://youtu.be/AJ6gdRfBW6c
• wildpeaks 3y ago
  I worry passkeys might be the death of Firefox given the current lack of support.
• nonlogical 3y ago
  This is finally a great article demystifying non-resident keys! I got a FIDO yubikey a few months back, it came with no PIN set up, I was surprised that I could just use it like that, websites were not asking me to set it up explicitly. I set it up via CLI. Then all websites started asking for the pin and storing the keys inside (resident keys). Knowing that you only have limited slots, I tried deleting the pin by resetting yubikey to revert back to old behavior as there was no way of zeroizing the pin any other way (for the sake experimenting with the tech and understanding key management better, ofc pin or BIO auth is better). And then suddenly found that I was unable to use the key to auth into my accounts I set up before. In hindsight now I know by resetting the hardware key I have reset the master key inside. There really isn’t much well written introductions into how all of this works. Thank you for doing a great job demystifying the flow here!
• 71a54xd 3y ago
  Until it's possible to physically link a passkey to a device like a yubikey I see no security "benefit" to giving single permissioned access to credentials to large tech companies. It's a single point of failure even worse than trusting a password management company like OnePassword etc. I'm still holding out for a self hosted or federated version of passkeys, potentially similar to how more complex forms of crypto custody exist - similar to multi party computing (MPC).
• smaudet 3y ago
  Consider also the option, that you dont need any security... This over-the-top nonsense for garbage accounts really needs to stop. I agree with some of the "opt-in" stuff but really, the default should be no passwords, no passkeys, nothing. IFF you need to secure something, your password manager can offer a password of "good enough" quality. This is a very simple problem with an overengineered mess around it - but the sec folks like it overcomplex, so they can charge more...
• Cakeboss16 3y ago
  [dead]
• deleted 3y ago
  [deleted]
• tedk-42 3y ago
  Yeah there's a cost. The cost is on the consumer who's being sold bullet proof vests to goto the supermarket because there's fear being created about random shootings that could happen and than you need these high tech security things to keep you safe. This type of security e-wang crap is only suitable for highly sensitive confidential data (secret / top secret level stuff) and most consumers get little benefit from it. Why? Because you've already handed over your data to a lot of places knowingly and unknowingly who are more likely to leak it than you ever will.
• forty 3y ago
  I understand that this person is not happy that a feature that is designed to make billions of users safer, might make life annoying for the handful of people who are using a hardware security key when they use that feature :)
• forty 3y ago
  Possible solution: use your hardware security key to login to your password manager and use the password manager for Passkey login. (Disclosure: I work for a PM which implements Passkeys)
  • slau 3y ago
    I don't want to store passkeys in my password manager, the same way that I don't want my TOTPs to be stored in my password manager. If my 1P/LastPass/BitWarden gets hacked/compromised/pwned by someone across the globe, they still can't compromise my critical services because they don't have my hardware token. I just have to rotate all of my passwords. If you store everything in your password manager, you've just turned your 2FA/MFA into 1FA. This is also why you shouldn't copy SSH private keys around, just because "it's easier to only have one fingerprint". Generate one private key per device. This is somewhat mitigated by `-sk` type keys, though. (SK SSH keys are still basically unusable because they are not recognised by a significant amount of versions of SSH, including the default MacOS SSH client).
    • forty 3y ago
      Passkeys are not MFA, Passkeys are expected to be used as a single authentication factor.
      • forty 3y ago
        Oh and for SSH, SSH CA and short lived SSH certificate is the only right way ^^ (I recommend Hashicorp Vault for this purpose. It also works for the host key)
      • ericjmorey 3y ago
        The passkey security model is designed with the assumption of the passkey ties to a device. Using a password manager that's tied to a centralized service that's accessible from any web browser with an internet connection makes the security model different. It seems to me like a passkey on a password manager is no different than a username and password with NO 2FA security model.
• aktuel 3y ago
  Why not simply allow users to specify any public ssh key as an authentication factor? And create a UI around that? Why do we need to create more and more new security crap that no sane person understands?
  • FrozenSynapse 3y ago
    And how many sane persons will understand what a public ssh key is?
    • aktuel 3y ago
      That's what the UI is for.
    • aktuel 3y ago
      I admit sane is a relative term. All I care about is that the keys are ssh keys and the protocol is ssh auth. Then do with that what you will. Store the keys in the cloud if you must. When a user creates an account on a site the browser gives the user a choice to either select an existing identity or create a new one. All very straight forward. You don't have to mention anything about ssh, RSA or ssh. Nobody is forced to learn what ssh means or how it works.
• leokennis 3y ago
  Dumb question, but how much more would a YubiKey or something cost if they added a marginal amount of storage so it could hold an almost infinite amount of these keys? I’d imagine something like 32 Mb would allow you to already store 1000’s of keys.
• fuzztester 3y ago
  Are passkeys going to make passwords obsolete and cancelled as an auth method, or will both exist?
  • runiq 3y ago
    In the spirit of the article: Yes
• garganzol 3y ago
  Passkeys are a fifth wheel in a car, so they won't come.
• Pesthuf 3y ago
  Yubikey and co will have to adapt and ship enough storage.
• ubermonkey 3y ago
  I'm honestly still looking or a one-sheet on why I should care about passkeys, and under what circumstances I should adopt them. I get it. It's a complex topic. When I was younger I would've jumped in and read about it obsessively, but I no longer have the time or motivation to do so. Is there a good resource that answers this mail?
• pm2222 3y ago
  CRUD question: is it easy to replace pub/pri key pairs, add a pair, and delete a pair?
• ngrilly 3y ago
  > Now, the primary difference here is that resident/discoverable keys consume space on the security key to store them since they need to persist - there is no credential id to rely on to decrypt with our master key! The article is glossing over the biggest drawback of non-resident keys: If you lose your security key, you lose your master key, and you can't decrypt anymore the credentials sent by the relying parties. To mitigate this, you need to register at least two security keys, and stored them in different locations. But wait, how can you register both keys in a new service, while keeping them in different locations?... I don't have much experience with those keys: am I missing or misunderstanding something here?
  • JohnFen 3y ago
    I think you understand it right. Or, if you are misunderstanding something, I am misunderstanding as well.
• LinuxBender 3y ago
  Given that passkeys are tied to a hardware ID does that mean people will eventually stop using VPN's, given they can potentially be de-cloaked by anything that can talk to their TPM?
  • gerwim 3y ago
    Passkeys are not tied to hardware. You can save them in iCloud, Bitwarden and lots of other tools. You can also share them to another device [1] [1] https://developer.apple.com/passkeys/ https://developer.apple.com/passkeys/
    • LinuxBender 3y ago
      I am factoring friction and laziness into this. Just about everyone excluding apple hardware has a TPM and it's already paid for. Not everyone has iCloud, Bitwarden or other tools. So there is what people can do vs what people will do and I think they will be guided if not now, then eventually into using the TPM since it is already present. People tend to follow the least path of clicks. Windows for example automatically takes ownership of the TPM by default. People on Apple hardware will probably use iCloud which may be tied to their real identity. This creates a lot more questions for me but that is probably best saved for it's own thread.
• t-3 3y ago
  I've never used one so have no idea, but do these security keys really have so little available storage space that they can only hold a few hundred passkeys, and if so, why?
• xoxogossip1 3y ago
  [dead]
• lusttforlife1 3y ago
  [dead]
• guyracer5 3y ago
  [dead]
• gamersimmer1 3y ago
  [dead]
• gamersimmer1 3y ago
  [dead]
• guyracer5 3y ago
  [dead]
• workofgod43 3y ago
  [dead]
• workofgod43 3y ago
  [dead]
• lucky43 3y ago
  [dead]
• lucky43 3y ago
  [dead]
• gypsy5645 3y ago
  [dead]
• bachelor6 3y ago
  [dead]
• bachelor6 3y ago
  [dead]
• boomn1x1 3y ago
  [dead]
• boomn1x1 3y ago
  [dead]
• isonfire36 3y ago
  [dead]
• isonfire36 3y ago
  [dead]
• missmischief4 3y ago
  [dead]
• missmischief4 3y ago
  [dead]
• gypsy5645 3y ago
  [dead]
• vogue567 3y ago
  [dead]
• vogue567 3y ago
  [dead]
• trueliving1 3y ago
  [dead]
• trueliving1 3y ago
  [dead]
• chillhouse54 3y ago
  [dead]
• chillhouse54 3y ago
  [dead]
• iamwell45 3y ago
  [dead]
• iamwell45 3y ago
  [dead]
• nitch7554 3y ago
  [dead]
• nitch7554 3y ago
  [dead]
• fabulous345 3y ago
  [dead]
• fabulous345 3y ago
  [dead]
• fierce443 3y ago
  [dead]
• fierce443 3y ago
  [dead]
• fashionista45 3y ago
  [dead]
• fashionista45 3y ago
  [dead]
• babynative54 3y ago
  [dead]
• babynative54 3y ago
  [dead]
• thedad46 3y ago
  [dead]
• thedad46 3y ago
  [dead]
• thedad4536 3y ago
  [dead]
• thedad4536 3y ago
  [dead]
• lyjules534 3y ago
  [dead]
• lyjules534 3y ago
  [dead]
• nitch654 3y ago
  [dead]
• nitch654 3y ago
  [dead]
• prada543 3y ago
  [dead]
• prada543 3y ago
  [dead]
• promax64 3y ago
  [dead]
• promax64 3y ago
  [dead]
• drunkbetch54 3y ago
  [dead]
• drunkbetch54 3y ago
  [dead]
• poemsporn1 3y ago
  [dead]
• poemsporn1 3y ago
  [dead]
• travelmore54 3y ago
  [dead]
• travelmore54 3y ago
  [dead]
• haveless54 3y ago
  [dead]
• haveless54 3y ago
  [dead]
• betches98 3y ago
  [dead]
• betches98 3y ago
  [dead]
• isonfire54 3y ago
  [dead]
• isonfire54 3y ago
  [dead]
• ofgod54 3y ago
  [dead]
• ofgod54 3y ago
  [dead]
• missmischief21 3y ago
  [dead]
• missmischief21 3y ago
  [dead]
• kong4523 3y ago
  [dead]
• kong4523 3y ago
  [dead]
• petter13123 3y ago
  [dead]
• petter13123 3y ago
  [dead]
• petter13 3y ago
  [dead]
• petter13 3y ago
  [dead]
• xoxogossip1 3y ago
  [dead]
• gypsyperson 3y ago
  [dead]
• gypsyperson 3y ago
  [dead]
• fabulous657 3y ago
  [dead]
• fabulous657 3y ago
  [dead]
• canyon12342 3y ago
  [dead]
• canyon12342 3y ago
  [dead]
• velvet564 3y ago
  [dead]
• velvet564 3y ago
  [dead]
• collective13 3y ago
  [dead]
• collective13 3y ago
  [dead]
• drunk2412 3y ago
  [dead]
• drunk2412 3y ago
  [dead]
• babycat 3y ago
  [dead]
• babycat 3y ago
  [dead]
• lyjules89 3y ago
  [dead]
• lyjules89 3y ago
  [dead]
• chillhouse7 3y ago
  [dead]
• chillhouse7 3y ago
  [dead]
• vogue134 3y ago
  [dead]
• vogue134 3y ago
  [dead]
• inkandfable1 3y ago
  [dead]
• inkandfable1 3y ago
  [dead]
• Cuteaesthetic 3y ago
  [dead]
• Cuteaesthetic 3y ago
  [dead]
• Kawaiiaesthetic 3y ago
  [dead]
• Kawaiiaesthetic 3y ago
  [dead]
• Jinxcosplay 3y ago
  [dead]
• Jinxcosplay 3y ago
  [dead]
• MeshFresh456 3y ago
  [dead]
• MeshFresh456 3y ago
  [dead]
• Veranorooz67 3y ago
  [dead]
• Veranorooz67 3y ago
  [dead]
• DorkyDweeb2 3y ago
  [dead]
• DorkyDweeb2 3y ago
  [dead]
• inkandfable1 3y ago
  [dead]
• inkandfable1 3y ago
  [dead]
• weworewhat1 3y ago
  [dead]
• weworewhat1 3y ago
  [dead]
• mystique54 3y ago
  [dead]
• mystique54 3y ago
  [dead]
• justonemore1 3y ago
  [dead]
• justonemore1 3y ago
  [dead]
• spicysugar1 3y ago
  [dead]
• spicysugar1 3y ago
  [dead]
• weworewhat9 3y ago
  [dead]
• galaxy12 3y ago
  [dead]
• galaxy12 3y ago
  [dead]
• gypsysoul1 3y ago
  [dead]
• gypsysoul1 3y ago
  [dead]
• julesontour45 3y ago
  [dead]
• julesontour45 3y ago
  [dead]
• pinchofsalt2 3y ago
  [dead]
• pinchofsalt2 3y ago
  [dead]
• lustforlife1 3y ago
  [dead]
• lustforlife1 3y ago
  [dead]
• weworewhat9 3y ago
  [dead]
• angelhearts1 3y ago
  [dead]
• angelhearts1 3y ago
  [dead]
• smashfizzle1 3y ago
  [dead]
• smashfizzle1 3y ago
  [dead]
• livincool11 3y ago
  [dead]
• livincool11 3y ago
  [dead]
• selfcare4yu1 3y ago
  [dead]
• selfcare4yu1 3y ago
  [dead]
• genes123 3y ago
  [dead]
• genes123 3y ago
  [dead]
• floufrouu121 3y ago
  [dead]
• floufrouu121 3y ago
  [dead]
• reading1234 3y ago
  [dead]
• reading1234 3y ago
  [dead]
• livincool134 3y ago
  [dead]
• livincool134 3y ago
  [dead]
• pistache12 3y ago
  [dead]
• pistache12 3y ago
  [dead]
• smashfizzle12 3y ago
  [dead]
• smashfizzle12 3y ago
  [dead]
• terthanthesun1 3y ago
  [dead]
• terthanthesun1 3y ago
  [dead]