Hacker News Reader

Comment by ToastyMallows | Hacker News Reader

It depends on how its implemented.

If it's "Whats your mother's maiden name?" and they let you reset it in the browser, it's a bug.

But if they send you an email (in my case to Gmail, that has 2FA turned on), then it is a feature, because then you'd be required to either 1) intercept the recovery email (and get the password reset URL) or 2) know the format of the password reset URL and just happen to guess mine after brute-forcing every possible link (assuming there is no timeout for the URL or anything else like that).

View on HN

I had an interesting thought (literally as I was reading your comment) about improving "forgot password" emails, albeit only likely useful for the technically minded:

Have the customer provide an SSH/GPG public key, and store it with the account.

When a password reset is requested, encrypt a random string using said public key, and email it to the email for the account.

An attacker who may have breached your webmail is then reasonably unlikely to also have your private key to decrypt the string.

Follow the link (which didn't necessarily need to be encrypted) and enter the string you decrypted to reset the password.

On a related note: do any/many sites with 2FA, require the 2FA code to do a password reset?

That's basically what TOTP/HOTP authentication tokens are, which many sites (including Google, AWS, Github) etc use for 2FA - https://en.wikipedia.org/wiki/Google_Authenticator. When you set it up, the service provider creates an 80 bit secret key, which you enter into your local device (or some implementations create a QR code) and then whenever you log in you need to provide a 1-time password from the app.

I'm aware of 2FA using (T|H)OTP, my thought was that a GPG/SSH key can be stored in a secure and yet reasonably easy to use way, effectively offline (i.e. add a passphrase and store it on a USB key or similar).

With a 2FA code, you either a) use the same code they use for regular logins, or b) require them to find a way to securely store the (T|H)OTP secret and then add that information to a 2FA app when they want to do a password reset.

I realise the pubkey concept is more than most people would bother with (or even be able to get through on their own), and I think the first 2FA option is definitely better than no extra security at all on password resets, but my thought was about increased security for those who are particularly paranoid/security conscious.

> Have the customer provide an SSH/GPG public key, and store it with the account.

Doesn't this just move the problem from "I forgot my password" to "I lost my private key"?

Higher security has some potential downsides.

If you enable 2FA on an account with a service, and subsequently lose access to 2FA otp's (e.g. phone lost/wiped/etc) and lose access to (or never kept) the recovery codes, you generally lose access to the account.

This is similar, but with the benefit that you can keep the key secure by default - i.e. put a passphrase on the key and then store it wherever you like.

In reality, if you fail this "recovery" method, my next suggestion would be a billing based one (i.e. talk to a human, get confirmation of previous invoice details, what is being billed for, how it's paid for, etc)

Reply on news.ycombinator.com