tennysont
Joined 1 year ago
Joined 1 year ago
Largely false. The Pixel verifies the OS and will reveal `verifiedBootState != Verified` on GrapheneOS in the attested passkey at registration, which websites may choose to reject. Apple Silicon has an undocumented SEP which prevents Asahi Linux from accessing it. There may be other examples now or in the future.
Also, I think you can deduce the device color from [1] on Android.
So, in conclusion: https://storage.ghost.io/c/ee/88/ee889f88-37ef-43e5-9180-f9b...
[1] https://source.android.com/docs/security/features/keystore/a...
A defining feature of traps is that they start out good.
There are a lot of good points in this article, but it fundamentally missed the point of the word trap. The most it said on that topic is:
> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.
Which is a statement about the near future. There is room for a conversation about the long term, but this article is not a part of that conversation.https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
> Explicitly state that the orchestrating party only transmits the credential exchange data between the exporting provider and importing provider.
And, in accordance with the spec, 1Password (who is the _editor_ of that spec) refuses to export passkeys to the user in any file format.No, they would need to be able to log onto the device and have the password manager unlocked.
If your passkey is stored in a Yubikey and someone steals it, then how does this feature help you? When the thief plugs the stolen Yubikey into their own Windows account, what is Windows going to do? Ask the thief for the thief's own password? How does that help?
No, there is a working draft of a protocol. The "format" is only for use in the protocol, not a separate thing. Thus, giving the user a file is disallowed under the spec as per §5.1.1.1 which reads
> Explicitly state that the orchestrating party only transmits the credential exchange data between the exporting provider and importing provider.
And, in accordance with the spec, 1Password refuses to export passkeys directly to users for manual import on another platform or app. FIDO developers have complained about Keepassxc violating the spec and threatened to blacklist them as a result[1].Furthermore, 1Password (who is apparently leading the way on the FIDO exchange protocol design) has not implemented _any_ passkey export on _any_ desktop platform.
It is interesting that you listed Bitwarden, since I believe that FIDO developers have specifically disavowed Bitwarden's behavior of allowing users to access their passkeys.
[1] https://github.com/keepassxreboot/keepassxc/issues/10407
[2] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
> keepassxc: no
> FIDO devs: but the spec
> keepassxc: that part of the spec is anti-user
> FIDO devs: do it or we might blacklist your app
> keepassxc: can't we just impersonate another password manager? also isn't bitwarden already doing this?
> FIDO devs: "Someone else is doing bad things too" isn't the greatest argument...
> FIDO devs: maybe we could hop on a phone call?
[1] https://github.com/keepassxreboot/keepassxc/issues/10407[2] https://github.com/keepassxreboot/keepassxc/issues/10406
Though, I do find it amusing that I commented about 1password's inability to communicate their security model, and your reply links a reddit post[1] in which everyone is disagreeing over whether or not iCloud secret key syncing actually occurs.
[1] https://www.reddit.com/r/1Password/comments/10iqhdp/comment/...
You can only export passkeys in 1Password for iOS and Android at this time.
So that's not great. Let's look at their page on the 1pux export[2]: Your data is yours. If you want to export your data from 1Password for any reason, you can.
And the word "passkey" does not appear on that page. Why are these docs still written like this after 4 years?And for the record, this is not impossible. Bitwarden does it[3] via the magic of "ignoring the part of the specification that says not to give users their data." Any open source software would do the same. This is why 1Password is no longer the "good guys" despite having rationalizations for their actions.
[1] https://support.1password.com/export/
> Use universal sign in for logins
> Our next-generation autofill combines all login types into a single sign in prompt.
What the f does 'next-generation' mean? No link for more information. Obviously I have to turn it off, else for all I know it will start setting up passkeys (now or in a future update) or do something else anti-user. And it also means that I need to be careful about updates to 1password. Sad to watch my relationship with my password manager go downhill.It immediately creates a huge lock-in in a hard-to-notice way. Luckily, I did noticed early on and manually removed the 20 or so passkeys I had created.
Earlier this year, I lost my iPhone and restored from backup. I was shocked to see that I could log into my 1Password account using only the master-key, and that the secret-key was not required. 1Password clearly stated that the secret-key was required to setup a new device, but it turns out that they also (perhaps recently) configure it to upload to all devices in your iCloud account[1]. Ever since then, I've lost faith in 1Password's ability to communicate their security model to me and started looking for an off-ramp.
But also, right now giving a website a passkey basically means being technically savvy or using a sensible system like the browser/OS. TOTP used to be this way, but then people got annoyed at the process and put everything into 3rd party apps that synced across devices. The same will happen with passkeys, at which point "passkeys are a website..." will morph into "attested passkeys are a website..." and the rest will remain true.
Cheap (~1k USD) drones are easy to intercept, vulnerable to EM/GPS jamming, require nearby operators, break easily, and can't carry enough payload to make a difference. Try to fix any one or two of these and the price will go up. As the price goes, reliability becomes more important. Try to fix them all and you're going to reinvent the missile.
One comment in this thread argued that drone factors can be protected from F-35s by burring them underground, misunderstand that such logistical hurdles are what causes military hardware to be more expensive than civilian equivalents in the first place.
At least in NATO lingo https://en.wikipedia.org/wiki/Air_supremacy
I can't tell if this comment chain is a factual disagreement (ability to interference) or a linguistic one (supremacy vs superiority).