Isn’t a bcrypt with many rounds and a unique salt would render any ‘stolen hashes’ useless?
George Shuklin

Yes, it would but not everyone uses best practices so 1 leaked reused password compromises other sites despite their best intentions.

With respect to removing user control from passwords, this is more/less the same as password-less except for removing the expiration factor. It’s a bit far-fetched but removing expiration/retry lockout opens the door to a brute force attack.

On top of that (to empathize with users), I would hate to not be in control of password length and character set. It makes me feel vulnerable to things that are out of my control (e.g. brute force attack due to password length and character set).

At the end of the day, it probably boils down to surface area (i.e. where things can go wrong) and development/maintenance work. We are removing ourselves as an auth providers and attempting to make general solutions for password-less auth and OAuth integrations. With other solutions, there has to be things like:

  • Verification emails
  • Reset password flow
  • Brute force detection for login

For reference, none of the domain tools I’ve used have a dynamic password (e.g. iwantmyname, namecheap).

Also for reference (and I’m sure you know this), apg seems to use PRNGs so if an attacker were to collect enough of those, then they could guess seed values and predict future values. We should be salting the PRNG values or salting the seed to make them more unpredictable.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.