[skbdpup]

> Unless there’s a security breach where it’s stored

These can go undetected. Imagine

1. Hacker dumps database with your username & password in it 2. Brute-forces the database offline 3. Logs in as you / Sells it to 3rd party that logs in as you

A lot of time can pass between these steps. Changing your password is a mitigation against this scenario.

[tialaramex]

The correct mitigation for these scenarios, which I agree are a problem, is to not use shared secrets. Key rotation/ changing your password is a poor workaround.

If you steal the WebAuthn database from my toy implementation, now, or tomorrow or ten years in the past, it makes no difference because it doesn't have any secrets in it, so, you don't learn anything useful. "Man, if I was this web site, which I'm not, now I could validate that the authentication was successful".

In such schemes the only thing similar to a "secret" is the Private Key, which exists only briefly temporarily inside my Security Key or other authenticator when it is doing its thing.

[sascha_sl]

Also, bad practices like logging passwords can be unearthed and fixed without any indication in between the times you change your password.