Hanko is currently not protected against account enumeration attacks. The login UI / endpoint can be tried with any username and the response exposes whether an account exists or not.
To have at least certain configurations that prevent account enum, a first idea would be to change the behavior so that when entering an email address, there will always be a passcode request pending.
That means we would not show the "This account does not exist, do you want to create an account for email@mail.com" UI ever. Also, do not trigger WebAuthn based on username / email input anymore.
Account enumeration would still be possible when email verification is disabled, but there is nothing we can do about it.
change getUserIdByEmail handler to not hand out verified info and hasWebAuthnCredential anymore
remove "This account does not exist, do you want to create it" view
for passwords we need dedicated sign in / sign up "pages" because we need a sign in that always prompts for a password, regardless of whether the account exists or not
Hanko is currently not protected against account enumeration attacks. The login UI / endpoint can be tried with any username and the response exposes whether an account exists or not.
To have at least certain configurations that prevent account enum, a first idea would be to change the behavior so that when entering an email address, there will always be a passcode request pending.
That means we would not show the "This account does not exist, do you want to create an account for email@mail.com" UI ever. Also, do not trigger WebAuthn based on username / email input anymore.
Account enumeration would still be possible when email verification is disabled, but there is nothing we can do about it.