4 ms·
> 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-fo
by skbdpup 5y ago
> 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.
- sascha_sl 5y agoAlso, bad practices like logging passwords can be unearthed and fixed without any indication in between the times you change your password.
- tialaramex 5y agoThe 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.