Hacker News new | ask | show | jobs
by gruez 1647 days ago
>An alternative is account locking after a number of failures, which is much better. However it also brings problems. It means that your 2FA must only be accessible for people who already have passed one level of security, otherwise you have a denial of service vulnerability.

Isn't that how most 2fa flows work? You enter username + password, if it gets accepted you move onto a second page where you enter your 2fa code.

> Plus you need all the account unlocking procedures etc, and need to make sure they are secure, and not actually effectively another attack route.

But realistically speaking don't you need a password reset flow? If so you can just reuse the password reset flow for lockouts as well.

1 comments

One problem with the two-step approach of only prompting for 2FA after successful auth is it leaks a lot of information - an attacker can confirm that they got the right password, or even just that the account exists and has 2FA enabled.

For TOTP-based 2FA, it would ideally prompt for all three (username/password/TOTP code) immediately, not indicating which part of auth failed.

This may not always be desired, for example when TOTP is just one among several 2FA options.

In those cases, at the very least always prompt for 2FA for accounts that require it, regardless of if password auth succeeded or not. Don’t tell the user if it was the password or TOTP code that failed.

> In those cases, at the very least always prompt for 2FA for accounts that require it, regardless of if password auth succeeded or not. Don’t tell the user if it was the password or TOTP code that failed.

This still leaks that the account exists and has TOTP enabled tho.

You have to choose if leaking the correctness of the password, or allowing DoS of a login, unless all the accounts have the same MFA.

> This still leaks that the account exists and has TOTP enabled tho.

You could mitigate that by prompting for an OTP code on a random but stable subset of nonexistent accounts -- for example, by hashing the provided username with a server-side secret and requesting an OTP if the hash starts with a zero.

First time I see this idea - I like it!
Yes, maybe I should have made that compromise more clear. The alternative I see would be to enforce some form of 2FA for all accounts and always prompt for 2FA. Depending on the system it may make sense.

It’s still way better than leaking a successful password auth.