Hacker News Reader

Comment by laputan_machine | Hacker News Reader

There is an overwhelming amount of superfluous text in this article.

The author's solution:

> Rather than allowing a user to set their own password, passwords can be issued in exactly the same way as API keys are now: a high-entropy password is randomly generated by the issuing website, and the user is shown the password once only and asked to record it. If the password is lost, a new password must be generated using the same process. The user cannot choose their password, but can get a new randomly generated one in the event of compromise. The password essentially becomes indistinguishable from an API key.

View on HN

This is basically what passkeys are, right? Except the autogenerated password isn't even shown to the user, just stored immediately in the user’s password manager.

(I recognize that it’s a bit more involved, eg if i get it right, passkeys add some public key encryption to the mix to avoid sending the “password” over the wire needlessly often etc, but those are just icing on the cake as far as I’m concerned)

There isn’t encryption nor a generated password involved with passkeys. Rather, your device generates a private key and stores it in your password manager - and only the public key is sent to the server.

When you log in later, the server uses an API to give your client a random unique challenge (just some bytes), you unlock and approve and the pwm signs some stuff including the challenge and sends the signature back. The server verifies with the public key, and is satisfied because only your private key could’ve generated that signature.

But you are exactly right - this is detail and the UX is essentially the same as having the pwm generate random passwords that you never get to see or copy.

There isn't encryption involved? I mean how can you use public and private keys without encryption?

Anyways yes, I agree otherwise. That said for all intents and purposes, the private key is a password. It’s the thing you store that gives you access to the service. That it’s not transmitted, but instead the whole public key / challenge response dance is done, is IMO sufficiently well summarized as “well, it’s a special kind of autogenerated password, which can’t be insecurely transmitted or badly stored by the service”.

If we really want people to adopt passkeys we gotta begin talking about them in terms people understand. I consider myself pretty tech savvy and it took me like 6 articles until I finally grokked that a passkey is just an autogenerated password (plus some free automatic bonus security that doesn’t affect my UX)

> how can you use public and private keys without encryption

Signing is different from encrypting.

https://en.wikipedia.org/wiki/Digital_Signature_Algorithm

And yes, 100% agree we can do better in terms of explaining passkeys. The hardest part is that different audiences require such different approaches.

Important to emphasize that passkeys are phishing resistant. Unlike passwords that allow you to copy and paste them to a website (hmm, auto complete isn’t working on this broken website, I can just go find it and paste it in — boom phished).

A password can be stored offline without any electronic device or even be memorized only.

Passkey depends on your device.

While you can't memorize it (memorizing a fair amount of entropy would take an intelligent human quite some time), you can of course store them offline (it's just a key). Today's initial implementation on macOS restricts exporting, but that is supposed to be added according to reliable Apple devs: https://hachyderm.io/@rmondello/110329118270492669

>you can of course store them offline

>Today's initial implementation on macOS restricts exporting,

So you can't. Will be able. How long can Tesla owner earn money with their self driving Tesla?

If you can export and import them, isn't that a security risk?

> memorizing a fair amount of entropy would take an intelligent human quite some time

Everyone who has seen it remembers correct horse battery staple and intelligent humans find it relative straightforward to reroll diceware until they can imagine a story for the words they see.

Permute case, use symbols and digits as word dividers, and most HN readers can remember 'uncrackable' amounts of entropy.

He also claims that TOTP storage in the password manager is useless. It's only useless if the entire password manager is compromised. If your attack vector is a keystroke logger, or compromise of a single password via a dump, or even someone having written down the password... storing the TOTP is still effective.

Keylogger would still get the TOTP code. Dump would include the TOTP secret. Why write only the password down if you still need password manager for the TOTP code?

I think I mostly agree TOTP in password manager is useless, but it's not worse than not having TOTP at all so it's whatever.

A TOTP code must be marked as “used” immediately after processing it, so an attacker using a keylogger would have only a few seconds at most to use the code, assuming the user typed the code from the password manager instead of copy/paste.

The protection offered for TOTP in a password manager is from people who reuse the same password on multiple sites and some other site gets hacked. In that case, the attacker would not be able to login, regardless of having the password.

Also, once a system is so thoroughly compromised that the attacker can install a key logger or dump a password database, that system and all the user accounts are already completely compromised.

TOTP at this point is essentially a forced password that changes every 30 seconds instead of an actual additional factor, however in many cases that’s good enough.

you missed the attack. a keylogger doesn’t capture the TOTP (and fully synchronous 0-reuse TOTP isn’t possible on global scale, instead you catch it in audit) a keylogger captures the master password to the pwm that stores the TOTP secret.

But then they have to have physical access to your pwm or an export of it. If it's cloud-based, I'd have to assume there's some additional auth done for non-approved devices, or it's a bad cloud pwm.

In the keylogger case, it still makes the attack more complicated -- they need to steal your login before that code expires, so rather than passive password-harvesting it has to be an immediate attack.

2FA protects two different attacks: 1) Hacker obtaining your password (through phishing, compromise of third party, etc.) 2) _You_ actually being compromised yourself somehow.

It is still effective for the first protection if you store your codes in your password manager, but less for the second. I say less, and not completely, because if your machine is compromised, gaining access to your phone too is only a matter of time. Of course this can be mitigated why proper hardware tokens, but most people aren't using those.

Keylogging + dump of password manager requires 2 different but related compromises, no?

Ultimately if someone can log keystrokes and has access to your device, it's game over.

I don’t understand that logic. Normally, systems generate API keys and show them to a person _knowing_who_that_person_is_.

I, when I lose my password, the system can generate a new one for me even when I’m not logged in, how can it know it’s doing that for me and not for someone claiming to be me?

I don't understand your confusion. The generated high entropy password would be shown to you with the system knowing who you are too - because you just registered or reset your password.

> how can it know it’s doing that for me and not for someone claiming to be me?

By emailing you a OTP :)

It sounds almost exactly like the mechanics of a session cookie as implemented on nearly every website on earth. Exchange a password for a bearer credential that is randomly chosen and revocable. There are only so many basic ideas in security.

Reply on news.ycombinator.com