3 ms·

If users log in infrequently, it doesn't change what I said. Say a user hasn't logged in in 5 months. 2 days after his last log in, that particular password mad

If users log in infrequently, it doesn't change what I said. Say a user hasn't logged in in 5 months. 2 days after his last log in, that particular password made it into the database. If either a cred stuffer or the legit user the same thing happens... Someone attempts to log in. At that point we don't know if it's the user or an attacker. The check is done, and we find that the password is in the db, therefore a 2nd factor check is required. If it's an attacker, presumably they don't have the 2nd factor and the attack is stopped. If its the user, they provide the 2nd factor and is asked to change their password, all without storing plaintext or unsalted passwords. What you're suggesting takes more effort than the more secure way (a rarity for security practices!).

bradknowles 3y ago
And you've just baked in a huge external SPOF into your user authentication system. You've also made user logins take a much longer amount of time. Or, you've implemented your own copy of the entire password database system, and you've now made your user login system increase in size by orders of terabytes. And still made it much slower.
- sophacles 3y ago
  That's silly - if the db check times out after a second or two, fire off the 2nd factor and move on. Or do it the way google does and do the whole login flow locally, and fire off a db check in the background - if it comes back as a leaked pw, notify the user or mark a "necessary password change" for the next login. As for slower - I'm sure you believe that it's a big huge difference, but really it's a trade-off like all engineering decisions, and "much longer amount of time" isn't really useful input when discussing trade-offs. What's the actual time add? What is the time without using the check? Whats the overall time taken on the login flow? How sensitive is the data you're protecting? etc.

bradknowles 3y ago

And you've just baked in a huge external SPOF into your user authentication system. You've also made user logins take a much longer amount of time. Or, you've implemented your own copy of the entire password database system, and you've now made your user login system increase in size by orders of terabytes. And still made it much slower.

sophacles 3y ago
That's silly - if the db check times out after a second or two, fire off the 2nd factor and move on. Or do it the way google does and do the whole login flow locally, and fire off a db check in the background - if it comes back as a leaked pw, notify the user or mark a "necessary password change" for the next login. As for slower - I'm sure you believe that it's a big huge difference, but really it's a trade-off like all engineering decisions, and "much longer amount of time" isn't really useful input when discussing trade-offs. What's the actual time add? What is the time without using the check? Whats the overall time taken on the login flow? How sensitive is the data you're protecting? etc.