12 ms·

If this gets implemented it will be the first step in showing that passkeys are a viable alternative to passwords in a meaningful way. That is, there is no ven

• wkat4242 3y ago
  Absolutely, this is the one reason I'm not interested in passkeys yet. I want to fully own my authentication keys myself. Not trusting Google or Microsoft for that. I hope it comes to zx2c4 pass too <3
  • eptcyka 3y ago
    With the sad state of PGP on Android, I hope someone picks up development on a viable alternative or ressurrects OpenKeychain. Currently, I cannot use my PGP keys because they're too new on Android.
    • wkat4242 3y ago
      I think OpenKeyChain is pretty great, I still use it. Unfortunately the authors went commercial (heylogin) and this is why they abandoned it. Their new products are very corporate and not interesting to me as an end user. But OKC is really necessary for my entire flow. I use it with password store, with termux (through OKCAgent) and some other things. I hope someone else picks it up too, but as long as they incorporate security fixes it's fine. I use yubikeys for the actual encryption anyway so the only risk is in the symmetric part. But what's the problem with your keys being too new?
      • eptcyka 3y ago
        My ed25519 keys can't decrypt my secrets due to a parsing error somewhere. I can still use okc-ssh-agent to SSH into places, but I cannot decrypt my passwords, which is kind of a big deal. It's because of this I'll probably migrate to a self-hosted bitwarden and use FIDO auth with my yubikey. I'll still use the GPG key for SSH authentication, but boy is this a mess I don't have any time for. And when I say I don't have the time for, I tried to get OpenKeychain to use a newer version of BouncyCastle, which should support my encrypted files just fine, but boy do I not have the knowledge to deal with changes in a project's gradle structure. I think the root of the issue is that newer versions of GPG have changed the format of the ciphertext in a way that the bouncy castle version OpenKeychain is using doesn't parse. Anyway, I do not feel confident in mucking about in crypto code. Maybe there's hope in just porting a front-end of pass that uses a plain ported GPG implementation instead.
        • snapplebobapple 3y ago
          check out psono too for self hosting (https://psono.com/ https://psono.com/) It's on my todo to do this myself but I haven't had time yet. It looks a lot more interesting to me than self hosted bitwarden/vaultwarden though, especially if you have needs to fill like encrypted file storage that are slightly above and beyond bitwarden's design.
        • fn-mote 3y ago
          > I think the root of the issue is that newer versions of GPG have changed the format of the ciphertext in a way that the bouncy castle version OpenKeychain is using doesn't parse. It might be worth your effort to test your hypothesis with an older version of GPG. The LTS version would be especially easy to investigate.
  • cyphar 3y ago
    I don't understand which part of FIDO/WebAuthn requires "trusting Google or Microsoft"?
    • stavros 3y ago
      None, it's just misinformation.
      • TacticalCoder 3y ago
        I don't think it's misinformation. You may decide, on your own website, for your own users, to accept passkeys from everybody but others won't. Sadly enough it's a near guarantee that the less secure implementations of passkeys (the software ones, allowing cloning and backups in the cloud) are likely to be the most accepted. While actually secure implementation with the secret hidden deep down behind an HSM and never leaving it, made by smaller companies who do care about security, are likely to be rejected on the ground that it's too much of an "obscure" vendor. I already posted about it today but if you think about it it's literally insane that cloning was meant to be detectable (and detection was enforced and upon detecting a cloned key, one of the two keys would stop working) and that this feature has now been removed with the sole justification being: "Because software backups to the cloud". It is not good.
        • vbezhenar 3y ago
          Are passkeys somehow signed by Google/Apple? I thought passkeys are like ssh keys.
          • stavros 3y ago
            They are, except they have a vendor ID that allows you to tell which vendor made the device you're talking to. You can get Passkeys by any number of vendors, but any authenticating website can decide to only allow a few vendors to log in with it.
            • 3y ago
• krono 3y ago
  Attestation certificates include detailed information about the device that signed them. Nothing is stopping services from limiting accepted devices to only those approved by the passkey gang (MSFT,AAPL,GOOGL). Suddenly things that many so readily dismiss as being FUD such as retail Pixel devices' bootloader requiring an internet connection to unlock[1] become much more more relevant. [1]: https://news.ycombinator.com/item?id=35852192 https://news.ycombinator.com/item?id=35852192
  • pabs3 3y ago
    I hear that the big tech vendors (Apple at least) aren't going to do attestable keys.
    • krono 3y ago
      Must have missed that, thanks. I'm not entirely up to date on this initiative. Just to be clear I'm not opposed to WebAuthn, I've just gotten very weary of these big corporations - especially when they are banding together and are all super excited about the same thing as we're seeing here :)
  • arianvanp 3y ago
    Luckily apple is of the opinion that attestation is a bad idea for adoption and they canned it
  • throwaway2056 3y ago
    > FUD such as retail Pixel devices' At the end of the day pragmatism will survive. Sure, if the OP cant put a simple SIM card to get it resolved then he/she can buy from nitrokey/other installed GrapheneOS. The basic premise of all these authentication/fingerprint/passkeys/whatever is to benefit the COMMON public. Telling a mother of 3 to keep keypassxc backup elsewhere (in a RAID with 3-2-1 offsite is impractical). Also all these experts that write in HN often join some company and implement closed-source. Yes, life sucks if one uses 'linux' phone - Banks don't care - If one is so against passkey gang then they should do something to make sure an average mum can use tech safely - see the state of PGP (very complex) - but signal/whatsapp is awesome. - Whether or not you like Cisco DUO becomes more of less default - Github/gitlab is developers world. Sure codeberg exists: I opened an issue asking them if they can help me configure runners - no help at all. - Also many of the devs say all open/free/etc but finally they do consume NetFlix, Prime etc (Yes, they have Apple TV or chromecast in addition to FrameWork (and RAID + 3-2-1). - Average Joe can't afford Framework. Get an ad-infested smartTV. Live with Google or Apple.
• cyphar 3y ago
  I don't understand your point about vendor lock-in, on the devices side YubiCo, Feitian and NitroKey exist (as well as many others probably) and are none are "multinational corps" in the derogative sense (the replies make reference to Google, Microsoft, Apple -- do those companies even produce U2F tokens?). On the authentication side, WebAuthn isn't tied to SSO and most websites that have their own login system will probably just add WebAuthn rather than switching to SSO (the WebAuthn and FIDO sites both have PoCs you can test and there are plenty of open source libraries and frameworks to use). I also don't get your point about how tokens could be used to sell your data -- it's my understanding that it'd be very difficult to track someone using their U2F key (there are attestation keys but they're done in batches so you cannot track an individual token, and the registration handshake doesn't use a unique ID you can use for tracking). But even ignoring that, if it were possible to track people using their token, then a digital token in KeePassXC would also be just as trackable. Personally I don't see a huge difference between this KeePassXC feature and just having your password (and maybe OTP) stored in KeePassXC and auto-filling everything. I think that's also secure enough for the vast majority of people (it's also what I use for websites that don't support WebAuthn as a second factor or when I don't want to have to have a physical token to do actions) but it's clearly not a second factor of authentication. Requiring a physical token is sometimes a good thing. Yes, if it breaks it's annoying, but requiring a token is what makes it multi factor authentication.
  • hackernewds 3y ago
    > are none are "multinational corps" in the derogative sense YET. Remember when LastPass was the second coming liberating us from the devils of Google passwords?
  • wepple 3y ago
    I don’t necessarily think OP believes this point of view, but even HN folks seem to think passkey is some wild biometric stealing mega Corp conspiracy. See a lot of the comments in this thread as an example: https://news.ycombinator.com/item?id=35801392 https://news.ycombinator.com/item?id=35801392
    • 3y ago
• _cenw 3y ago
  > They aren't tied to a device that can be lost, stolen or broken, or requiring you to have multiple devices just in case; and not tied to biometrics. They optionally can be all of the above, using AAGUIDs and direct attestation.
  • rootusrootus 3y ago
    If even one of the big three refuse to support attestation, then it's dead. And trying to retroactively force attestation at a later date will an even bigger headache than it would be right now.
    • _cenw 3y ago
      It's not really a feature for normal passkey users as much as it is for enterprises / government who need to use vetted hardware (e.g. you can only allow AAGUIDs from FIPS YubiKeys).
• danShumway 3y ago
  It's a huge first step, but only a first step. We still need: - Guaranteess that attestation won't be used to block KeePassXC from being used as an authenticator. (Edit: it's been pointed out below that Apple is getting rid of attestation for its platform authenticators, and as far as I can tell that's true. Extremely big deal because nobody is going to want to cut off Apple keys, which effectively means those services can't require attestation. So assuming it is true (which it looks to be) this shouldn't be an issue.) - Support for platform authenticators on Linux for Firefox and Chrome (Chrome currently has "no plans" to support this). - Compatibility with other platform authenticators. That last point is possibly the biggest problem, and it's part of why I've been pushing that this needs to be part of the spec. Okay, let's say you can export and import from KeePassXC. To where? This is still going to be a situation where a family member tells me they're interested in switching to Android and I have to tell them that they'll have to one-by-one transfer their login information. This is still going to be a situation where if you export your keys from KeePassXC, you won't be able to import them into anywhere. It'll still be a situation where if a family member loses their iPhone and they haven't synced keys to other devices already, their only solution is to buy another iPhone like a good little consumer. That's not to say that an Open implementation of a platform authenticator doesn't matter. It absolutely does, it's just only a first step. We still need buy-in from the FIDO alliance itself that importing/exporting keys is an important part in general of being a passkey provider. And we still need to see how the attestation situation is going to play out (see note above) and whether there are going to be any consequences at all for sites that just try to block anything except mainstream devices (see note above, the consequence would be losing iPhone users).
  • lxgr 3y ago
    Do Passkeys even support attestation? What would they even attest to, given that the credential is effectively not bound to any secure hardware? To my knowledge, Apple has ripped out their "anonymous attestation" service together with introducing Passkeys in iOS 16; before that, requesting attestation was an option to opt out of Passkey syncing (and create a device-bound credential).
    • danShumway 3y ago
• JeremyNT 3y ago
  This doesn't solve anything, sadly. You are entirely at the behest of Bigco as to whether they will require keys signed by any particular device's certificates, and they have no incentive to allow interoperability here.