Earlier quoted context omitted.
Pretty sure there's been talk on the Bitwarden community forums about them adopting support for using it as a provider. I assume once that's available you might start to see it move into Vaultwarden. But, that's sort of the risk you run with using a 3rd party to a 3rd party...
At least with Vaultwarden, it's open source and running locally with data stored on a server in my house, so if they misbehave, I could easily fork or switch projects. If Android doesn't allow or otherwise hobbles 3rd party password managers, there isn't much recourse.
Bringing passkeys to Android and Chrome
61–70 of 264 posts
Re: Bringing passkeys to Android and Chrome
#62Earlier quoted context omitted.
it is your key, it lives on your device (and is synced across devices using your cloud account if you so choose)
It's a nanny-ish third-party in the middle. That increases convenience, but also greatly increases your threat surface.
Re: Bringing passkeys to Android and Chrome
#63Earlier quoted context omitted.
From TFA (the security blog): "The main ingredient of a passkey is a cryptographic private key. In most cases, this private key lives only on the user's own devices, such as laptops or mobile phones."
Final step is key escrow authority that will store your private key and produce it to you if you can proof your identity with government ID. It is not enough to store in cloud storage (which Google, Apple, or someone else could deny you access to), or your own device you could lose or destroy (which is why backup hardware tokens are always recommended for U2F MFA); you need the ability (but not a requirement) to bind…
You are correct that a Passkey ecosystem has an inherent risk of being locked out of cloud storage / sync, and that a third party escrow system is a mitigation against that. But it's not sufficient. You'd end up with keys that could, at best, only be imported into authenticators of the same ecosystem you were denied access from which, as Sync Fabrics are not interoperable. This is presumably not the outcome you're looking for.
I believe some sort of mechanism to assert credential strength at presentation time rather than generation time, and/or some sort of mechanism for TPMs/Secure Elements/Secure Enclaves to establish trust and import trusted credentials from a different authenticator vendor would be needed. This would allow vendors that don't control the hardware (i.e. are not Apple/Google/Microsoft) to build something like a "1Passkey" without having to implement their authenticators in software (i.e. a Virtual Authenticator), and you could keep your wrapped passkey store in escrow with any third party of your choosing.
Re: Bringing passkeys to Android and Chrome
#64Earlier quoted context omitted.
Yes, definitely. USPS + Login.gov could act as trust anchors, with cryptographic keys reprovisioned upon proofing, versus storing them. I am open to whatever is the optimal balance between security and practicality. https://www.uspsoig.gov/document/role-postal-service-identit... > The Postal Service Reform Act of 2022 has recently expanded the Postal Service’s ability to provide identity verification to all levels of…
Except that here in the US a non-trivial number of politicians of a particular persuasion[1] actually believe that government issued ID, of any kind, is the "mark of the beast". There's a reason that Real ID had a lot of push back. Having USPS, already a political bogey-man for that same crowd, become a holder of "identity" is probably going to face a lot of pushback. [1] just one, recent example... https://www.al.co…
Re: Bringing passkeys to Android and Chrome
#65Check out AuthCompanion, a passwordless login implementation for ideas. https://github.com/authcompanion/authcompanion2
The code is pretty simple and a good place to start, as well as AuthCompation, if you wanted to roll your own library in your language of choice or whatever, or something very custom. I found both useful recently.
Re: Bringing passkeys to Android and Chrome
#66Earlier quoted context omitted.
In the United States the US Postal Service would be a great fit for a job like this. They already have good infrastructure for identity verification and physical distribution. I wouldn't want escrow of private keys, however. I'd rather the USPS just act as a certification authority that provides strong guarantees of identity verification.
i don't want this because then more websites will start expecting strong identity verification. the last thing we need are more attacks on anonymity. at least with a private key i can say i'm joe biden or crazy horse or whoever. i may not be eligible for "government escrow" but who cares.
My bank is already regulated and required to have strong identity verification for some operations. They won't let use any sensible multi-factor authentication, however. Requiring they use such a government mandated authentication infrastructure would be a major "win" for my piece-of-mind.
Re: Bringing passkeys to Android and Chrome
#67I don't use my phone to log in to anything. All my stuff is done on a computer with a password manager. At no time am I even likely to rely on Google for anything this important; every other week there's a thread about Google killing off accounts for no reason. No way would any sane person allow Google access to this with their track record. And this isn't even considering my suspicion that Google only wants to "help…
More or less the same, except that I haven't found good TOTP solutions for the desktop, to the tune of KeePass (something that can run on Windows/*nix instead of making me use something like FreeOTP, Google Authenticator or other Android/iOS apps; or in addition to the mobile apps).
That said, even with multiple Google accounts for different things (e.g. personal e-mails, file storage, cloud services etc.) it feels like eventually you might want something like Qubes OS, another way to run multiple separate VMs, or just use separate devices for separate use cases.
Much like how some orgs have separate laptops for accessing prod environments, that are more tightly controlled, even though that's not convenient enough for most people.
Re: Bringing passkeys to Android and Chrome
#68Re: Bringing passkeys to Android and Chrome
#69People are raising really good points here, but I do find it interesting how negatively this news is being received vs. when Apple said the same thing: https://news.ycombinator.com/item?id=31643917
> Unless I can back it up and import it into a new device from a competitor, then there is no way I am going to use this unless forced. I do not trust one company anymore.
Which is the same sentiment as this thread. The first comment was just talking about the open standard of Apple's implementation and weakness of 2FA loss/recovery.
Re: Bringing passkeys to Android and Chrome
#70Passkeys sound like another way for companies like Google and Apple to lock you into their walled garden. Having each walled garden randomly generating a key for every single domain instead of using the actual domain name as part of the key is a great way to lock regular people into their respective ecosystems.
The entire third party auth push has turned into what may be one of the largest incumbent power grabs I have ever seen. Stuff like Google Amp or even App Store walled gardens pale in comparison. What drives me nuts is how little discussion of this I've seen. People don't even seem aware of the implications of it. It's being pushed hard as a boon to security, which it is in some cases, but at a cost that nobody is eve…
If they could just use their fingerprint/faceID to login (after initial registration on the device) they would be super happy.
Rest of us should be happy there will be less exploits where people give up the keys to their kingdom by clicking on a random email.