top 67 comments

sorted by: hot top controversial new old
[–] 97 points 4 weeks ago (1 child)

Pepperidge Farm Remembers when the FIDO Alliance threatened to recommend the blocking of FOSS implemententions because they gave the users control. Control over backing up. Control over not using biometrics.

When something wants too much power, you must avoid.

  • source
  • hideshow 1 child comment
  • [–] 45 points 4 weeks ago (12 children)

    This is why I only use passkeys that are stored in my self hosted vault warden. As long as you don't create passkeys locked to a vendor's manager, I don't see any reason to avoid them.

  • source
  • hideshow 12 child comments
  • [–] 2 points 4 weeks ago

    I have been doing the same thing. If the passkey tries to lock itself to a particular device, I'm not using it. I don't feel like having Google, Microsoft or any other software company control my logins. If it can be stored in my KeepassXC vault, I will use it.

  • source
  • parent
  • [–] -1 points 4 weeks ago (10 children)

    The Bitwarden client is so bad though. I seem to only be able to use the passkey on the specific device I saved it in.

  • source
  • parent
  • hideshow 10 child comments
  • [–] 13 points 4 weeks ago (2 children)

    I've experimented with this and haven't had a problem. However, I was using the open source fork Vaultwarden and only the browser extension(s).

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 4 weeks ago* (1 child)

    I am using the same combination, but the passkeys do not persist between different browsers

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 4 weeks ago

    In the bitwarden browser extension, settings -> autofill -> "make bitwarden your default password manager"

    Is this checked?

    I also set a "pin" in settings -> account security -> "unlock with pin".

    (After reading the article: maybe passkey requires bitwarden to be "more secure" - I dunno)

  • source
  • parent
  • [–] 4 points 4 weeks ago* (3 children)

    Hmm I haven't had that issue, I have a lot of passkeys saved and they sync fine and are usable in Firefox on my laptop as well as with apps on my pixel 5 running lineage. I have noticed that occasionally an app will refuse to give me the option to create a passkey in bitwarden, but I just skip those and I haven't noticed that issue in a while.

    Have you checked whether the site entry shows the passkey on both devices? On mine it'll say "passkey created ..." on both devices in the vault.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 4 weeks ago (2 children)

    The main problem is that there's no place to view my passkeys like there is for passwords for TOTP (according to my searching and their website, anyway)

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 4 weeks ago

    In vaultwarden, they do appear in the web client. The behavior you're describing hints that your passkeys are not being stored in bitwarden.

    ...and tbh, the UX sucks pretty bad: I was trying to store a passkey in bitwarden, but it was failing (unrelated networking error). I had two options: add it to bitwarden (which failed) or cancel. I hit cancel and was prompted for my fingerprint, which I provided -- this ended up storing it on my device... no input, no description of what it was doing. The website came back with "passkey now enabled" :facepalm:

  • source
  • parent
  • [–] 77 points 4 weeks ago (11 children)

    If your security relies on a password, you will always be anxious that somebody, somewhere, has somehow figured out what it is and already has access to your bank account.

    No I won't. All my passwords are something like I0!2b6KJ!eA04WiJ&&MFToCQ7CN*4mvb and each is used for only one thing because I've been using a password manager for over a decade.

  • source
  • hideshow 11 child comments
  • [+] -16 points 4 weeks ago (8 children)

    I don't think any service allows passwords that long

  • source
  • parent
  • hideshow 8 child comments
  • [–] 17 points 4 weeks ago

    Most do. Source: I usually use passwords that long.

    Maybe 1 in 10 don't, and I find that annoying since 32 characters containing only lowercase real words and spaces has several times as much entropy as 8 characters of random mixed case letters, numbers, and symbols.

  • source
  • parent
  • [–] 10 points 4 weeks ago (3 children)

    I default to using 128 characters because that's the max for the password generator I use. A surprising amount of accounts are OK with that, like more often than not. I have pared accounts down massively since using a password manager though, and use privacy respecting services when possible, so I may be self selecting here.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 4 weeks ago (2 children)

    It’s interesting to say more often websites are ok with that length. I do know that some websites truncate passwords so a long 128 character password may end up being a 16 character password and it all still works despite the password being that long.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 4 weeks ago* (1 child)

    That's why I always click the eye to see it if possible, and log in on another device with the password manager after changing/creating a password. I've only had that happen once or twice though.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 4 weeks ago

    Even if the password box accepts the full string, some sites truncate it in the backend. A good test for this is to try logging in with your full password except for the last character. If that works, keep deleting characters until you can't log in anymore, and then you'll know how many characters it really supports.

    Hopefully nobody still does this, though with the rise of vibecoding, who knows…

  • source
  • parent
  • [–] 43 points 4 weeks ago (3 children)

    Never used. Each time a website asks me if I want to create one I have this uneasy feeling of not actually owning the key.

  • source
  • hideshow 3 child comments
  • [–] 8 points 4 weeks ago* (1 child)

    You're not wrong to have that feeling.

    Where is the passkey saved? Can I take it out and back it up? Can I use it on another device, running a completely different OS? If I lose this device the passkey is on, what happens?

    The answers to most of these is negative.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 4 weeks ago

    I am using Bitwarden client with self-hosted vaultwarden and answers to all of those are: my server, yes, yes, if I lose all my devices and the server at the same time I lose access to my passkeys, and all my passwords for that matter. If I have my server, or at least one of my other devices, they are all on my device.

  • source
  • parent
  • [–] 18 points 4 weeks ago (1 child)

    Passkeys give me anxiety because it's like "Hope you can go the rest of your life without a phone or USB drive getting lost or stolen LMAO"

  • source
  • hideshow 1 child comment
  • [–] 12 points 4 weeks ago

    TIL what passkeys are. Thx for sharing.

  • source
  • [–] 11 points 4 weeks ago

    This is the feature that means you no longer get to make the calls about your passkeys. Fortunately, attested passkeys are not yet required on most websites. But the FIDO Alliance standard makes attestation a part of the passkey ecosystem, whether you want it or not. And even if the website doesn’t require attestation now, simply by using passkeys you indicate to the website that your setup supports the FIDO Alliance’s passkey standard and that you as a user are capable of using passkeys.9 This means that once Twitter (formally X) is satisfied that the overwhelming majority of its users would be unaffected, they can flip the switch – perhaps not all at once, perhaps just for ten thousand users at a time so as not to cause a fuss – and start rejecting non-attested passkeys.

    Critically, remote attestation requires the co-operation of your cryptoprocessor, your passkey manager software, your device’s operating system, and your device’s firmware to all pass the remote attestation check. After all, your phone’s operating system has total access to all the 0s and 1s in every app that’s ever run, so it’s not enough for Twitter (formally X) to trust your passkey manager if it can’t even trust your phone’s underlying operating system. If any single one of those things were to fail – say, because your phone stopped receiving security updates so you installed a custom operating system like LineageOS to keep yourself safe without having to buy a new device – then Twitter (formally X) will be able to notice and prevent you from logging in.

    Remote attestation can allow them to verify that your device is not capable of, say, sending and receiving encrypted messages, or running a competitor’s app, or using social media without verifying your ID. They don’t want you to be able to turn off the mandatory built-in AI image scanner on your phone that scans everything your phone sees for nudity. (Yes, I’m serious.)

    The convenience of using passkeys is a double-edged sword.

    This is also one of the ways Playstation stops you from installing Linux and other unauthorised software on the PS5.

  • source
  • [–] 29 points 4 weeks ago* (4 children)

    Despite the attention-grabbing headline, the only negative thing I can find in the article about passkeys are this section:

    Attested passkeys7 are the last but most important type of passkeys you need to know about. These types of keys use what’s known as remote attestation to cryptographically verify – using the aforementioned tamper-proof cryptoprocessor that lives in all your modern devices – that you are using one of the several approved passkey managers, and not using a custom one that you vibecoded yourself and which can lie.

    This is the feature that means you no longer get to make the calls about your passkeys. Fortunately, attested passkeys are not yet required on most websites.

    I don't see why we should assume this hypothetical is going to happen. There is a lot of different software that supports passkeys (I use keepass for example), and going against the open standard and forcing all their users to use a specific software would basically make them unusable.

    Overall every password / login style has its dangers and bad ways to use it, including passkeys. That doesn't make them "traps".

  • source
  • hideshow 4 child comments
  • [–] 8 points 4 weeks ago* (1 child)

    Also, like, if it doesn't allow me to set up a passkey because my manager or OS is not supported...I guess I'm not setting up a passkey then, which is OK by me, so there is no problem.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 7 points 4 weeks ago

    Ooohh, don’t think corpos and banks won’t go for that hypothetical. A lot of apps already turn haywire if you have developer options enabled, accessibility options enabled, have a specific installed or using a custom ROM. If the optional attestation is enforced by your bank that they only accept passkeys from google’s password manager or apple passwords, then using something like Keepass or Bitwarden isn’t an option.

    Look… I love passkeys. They are convenient and more secure. But if a service cares about on what device and software it was created then it is pointless and just an ecosystem lockdown mechanism.

  • source
  • parent
  • [–] 2 points 4 weeks ago

    The only area I could really see this taking off is with internal company stuff. Like forcing employees to use a very specific and weird way to do 2FA is already a thing in a lot of companies. They won't let you just use any old authenticator app. You need the "special" one that sucks ass. So maybe they'll do the same to passkeys, but for normal users I don't think they'd do that. Users are way too bad at doing things. It would cause too much of a tech support burden or just user bleed.

  • source
  • parent
  • [–] 10 points 4 weeks ago* (last edited 4 weeks ago) (4 children)

    An attempt to make an image describing where passkeys live:

  • source
  • hideshow 4 child comments
  • [–] 1 point 4 weeks ago (3 children)

    It’s funny because I can’t see it and when I view the code of your post and copy/paste it into the location bar I get the broken jpeg picture.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 4 weeks ago* (last edited 4 weeks ago) (2 children)

    Edit: At the time of upload it was a png. I guess lemmy.zip made the choice to convert it.

  • source
  • parent
  • hideshow 2 child comments
  • So it’s HDMI for login? Thanks, I hate it.

  • source
  • [–] 22 points 4 weeks ago (3 children)

    Ah there's that phrase again, remote attestation. That has very quickly become my least favourite phrase, and I've yet to see an example of it that benefits the end user. I didn't know passkeys supported it but I'll be avoiding them even harder now that I know they do.

    I've already been avoiding them because I don't see how there's any security advantage over TOTP unless the passkey is the only way to access the account (which would be awful for account recovery). And the concept of tying my login to a specific device is stupid. I also don't appreciate how many websites keep trying to stealthily create passkeys automatically on login without explaining what they are or letting the user make an informed decision.

  • source
  • hideshow 3 child comments
  • [–] 13 points 4 weeks ago (2 children)

    I've already been avoiding them because I don't see how there's any security advantage over TOTP...

    I'm not going to challenge your choice in using passkey or not. However, I do want to set the "technical record straight": passkey is the successor to TOTP in every technical way*.

    TOTP works by having a "shared secret" saved by both you and the place that your authenticating against. This shared secret is then mixed with current time to generate a rotating number that the client shares with the remote server. The remote server does the same calculation, if the rotating numbers match, the user is successfully authenticated.

    With TOTP, this means that there are two attack vectors: your device and the remote server. If an attacker is successful in getting the "shared secret" from either, your TOTP is effectively broken.

    Passkey works more like ssh-keys. The client generates a public and private keypair. The client only shares the public portion with the remote server and stores the private key locally (or in your password manager).

    So the only attack vector (with passkey) is your device (this is often why it's bundled with attestation). Also passkey is not dependant on both the client and server having their time kept in sync. With TOTP, if you have more than ~30 seconds drift between the client and server, they will be generating different rotating codes and never match (which is confusing when you need to explain this to your Grandma).

    • there is one thing TOTP can do, that passkey cannot: TOTP is 2FA, your TOTP can reside on a separate device (ie your phone when logging in using your PC). With passkey, you'd need to enable 2FA on the passkey manager (which varies from manager to manager).

    ...unless the passkey is the only way to access the account (which would be awful for account recovery).

    Recovery options are never going to go away. With TOTP, you often have one-time use backup codes. Email, SMS recovery etc.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 20 points 4 weeks ago

    Zero trust is the end station, if you allow organizations to treat your personal devices as being theirs. Organizations that could actually benefit from the increased security (which isn't Twitter, except for some high-profile individuals, maybe), should provide the user with resources to do so, at their expense (issuing a dedicated TOTP device for example).

    But what tends to happen instead, is enshittification of service, while offloading it onto the client. A similar trend can be observed with car parking: where operators remove parking meters, and require the customer to use their device and data plan, to make a payment to the operator...

    We've been on this trajectory for quite a while now: from Outlook enforcing IT-policies of email administrators (dictating screen locking requirements as device administration app), to SMS-based 2FA requiring one to have a mobile phone number and tying all to this tamper-resistant identifier. So why not a black box snitch, paid for by the client, further restrict their freedom for "security"?

    It seems perfectly in line, and I think this article draws all the right parallels.

  • source
  • [–] 7 points 4 weeks ago

    I suspected as much, being shoved on us like AI.

  • source
  • [–] 7 points 4 weeks ago (1 child)

    SQRL, been around before passkeys, it's portable, and it's FOSS.

  • source
  • hideshow 1 child comment
  • [–] 13 points 4 weeks ago (2 children)

    Please just stop using a service when it gets unbearable. There is no online service you -need- except maybe bank and tax stuff.

  • source
  • hideshow 2 child comments
  • [–] 4 points 4 weeks ago

    The problem isn't you or me, the more technically aware... it's when the majority of users switched to passkeys and then subtly get switched to attested passkeys and sites don't offer other choices. Once the majority are under-thumb, sites won't have a reason to offer open solutions to the same number of objectors.

  • source
  • parent
  • [–] 10 points 4 weeks ago (6 children)

    As far as I know using a password manager such as KeePassXC or Bitwarden solves all of these problems?

  • source
  • hideshow 6 child comments
  • [–] 12 points 4 weeks ago* (last edited 4 weeks ago) (2 children)

    The way i understand it is that remote attestation (main point of this article) makes it possible for services to deny unapproved software. They can deny off market devices, operating systems, or certain password managers. So even if you use password managers you mentioned, if you're using off market OS (e.x lineageos) they can deny access. Here's a quote from the article "Remote attestation lets a website demand cryptographic proof that your device, operating system, firmware, and passkey manager are all on an approved list."

  • source
  • parent
  • hideshow 2 child comments
  • [–] 5 points 4 weeks ago (1 child)

    Hm, so similar to websites blocking user agents now.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 3 weeks ago*

    It's more like how my bank has started locking users out of online banking if they don't have the mobile app for authentication, and preventing the mobile app authenticating the user if they're running a non-approved version of Android like GrapheneOS. Try to gain digital independence and all these mechanisms will be used to shut you out of everything you need. Only thoroughly locked-down and surveiled devices will be allowed to access useful services.

  • source
  • parent
  • [–] 2 points 4 weeks ago (1 child)

    and your redundant 3-2-1 backup system of that. Everyone knows that! Surely no one has no backups. Oh well, can't design around that unpredictable problem that no one could guess. Everyone has backups!

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 4 weeks ago

    It's wild seeing people spaz out over passkeys, clearly venting at something that isn't passkeys.

  • source
  • [–] 12 points 4 weeks ago (1 child)

    finally people are waking up to this garbage.

  • source
  • hideshow 1 child comment
  • load more comments
    view more: next ›
    25 comments in c/hackernews@lemmy.bestiver.se view that post
    19 comments in c/cybersecurity@infosec.pub view that post
    17 comments in c/security@lemmy.ml view that post
    9 comments in c/privacy@programming.dev view that post
    3 comments in c/pulse_of_truth@infosec.pub view that post
    1 comment in c/netsec@nodesphere.site view that post