> security against man-in-the-middle attacks but face the higher probability scenario of losing access to your accounts

The author says "security" against man-in-the-middle attacks. Are they not using the typical cybersecurity-context meaning of "secure" that I just mentioned? (Resistance against exploits, attacks, social engineering, etc.) And note that they say "higher probability scenario of losing access to your accounts" rather than something like "lower security against account loss" which would have been admittedly understandable, but a bit less clear since the more common cybersecurity meaning of "security" was just used.

> deliberately tried to bring up an alternative meaning

I am using the typical understanding of what "secure" means both 1) in the context of the quote from the article you used and 2) generally in the context of authentication methods. Let's not act like I dug up some obscure and irrelevant alternative definition.

> and into your hypothetical context

Is it really so unrealistic and hypothetical to think about how non-technical people (i.e., the vast majority of people) will interpret the at best questionable statement that "passkeys are insecure"? I stand by my claim that most people will get the wrong idea when they hear that.

The UX is obviously a lot smoother if you have an iPhone and use iCloud keychain for everything, but that’s not an uncommon setup.

That is some serious semantic bleaching!

I’m not disputing the fact that “secure” has different meanings in different contexts. My point is that when we talk about the “security” of authentication methods, we almost always are referring to its resistance to attacks, exploits, social engineering, etc.

If you tell the average non-technical person that “passkeys are insecure,” they’ll think that it’s easier for (WLOG) Russian hackers to phish or bypass their way through some website’s passkey requirement.

And to be clear, I don’t think it’s ridiculous to say that right now, the risk of lockouts outweighs the security benefits of passkeys. But this is a fixable problem. If it gets easier to securely recover or back up passkeys, I think we can reach what is more clearly a “best of both worlds” of security and reliability.

If a car breaks down every 50 miles we would call it unreliable. If a car’s doors don’t lock we would call it insecure.

Lockout is a real risk, but there is nothing insecure about passkeys. Private keys stored on the secure enclave + biometrics or passcode before any signature is produced + origin binding mogs a static string and a 6-digit TOTP (often generated with a secret key outside the secure enclave) that can be phished and entered from anywhere. Also, in many (possibly the majority) of scenarios where someone is locked out of their passkeys, they’d also be locked out of TOTPs and passwords.

> The only possible way to consider them more secure is if phishing attacks were more common and more damaging than lockout

You’d be surprised.

No grandma, don’t use the unphishable one-click passkey setup that syncs across all your devices. Instead, install a third-party password manager (no, no, not the one built in to your device or browser), then another TOTP app on your phone. It’s slower and more susceptible to phishing, but uhhh, what if you’re among the one in a million people that has their Google or Apple account wrongly banned?

I was surprised to find only a few solutions for this that were all paid, so I made a free and open source version.

CopyLasso is a native Swift app built with ScreenCaptureKit and Apple Vision. It's MIT-licensed, signed, and notarized.

To use it, just press your keybind and draw a bounding box around the text you want to copy. The text is recognized locally and copied to your clipboard.

Other features include copying QR codes and barcodes, multi-language recognition, and (if you opt-in) encrypted capture history.

Source: https://github.com/bennetthilberg/copylasso

Feedback and ideas for features to add appreciated!

Comments URL: https://news.ycombinator.com/item?id=49365721

Points: 9

# Comments: 0