On top of my hat… What if user is forced to insert a stronger password? (therefore: the user cannot use the compromised one since the complexity is the same)
Do you find this as an anti-UX constraint?
Well, that’s certainly better than nothing and certainly better than e.g. solely requiring that the passwords may not match, but you still have the problem that dumbasses will choose “1234567” as their next password.
Ah, I thought you meant “complex” like the complexity rating that password managers or some sign-up forms give you. Because with that, “1234567” is considered more complex than “123456”.
But I guess, you would rather for example enforce that no substrings from the previous password are allowed to show up in the new password.
I think, that would be fine, UX-wise, if you for example require no more than three consecutive symbols to be the same.
That should only trigger in rare cases and mostly in cases where it is sensible.
Bonus points, if you recommend the use of a password manager when you detect someone doing that. Because in my experience, it’s almost never the case that people don’t know how a good password would look, it’s just that they’re human.
Yes you are right, I mixed up stength with complexity. :)
Since the user cannot assess password complexity on sight, it may be useful to help the user understanding this complexity. Maybe this?
I have mixed feelings towards password managers I cannot explain. I concede it may be just my ignorance. :)
I used to have mixed feelings about password managers, thinking I’m exposing all my passwords behind just a single password.
But without a password manager, it’s pretty much impossible to use a different password for each service. And that’s really the bigger risk, as services leak password hashes so often, if that hash gets bruteforced once, you’re fucked for every service where you reused that password.
I mean, services can add Salt and Pepper to the password hashes to make bruteforcing the hash harder and the result less useful, but you unfortunately can’t rely on that.
I never understood how 123456 can be so popular when most services require you to use 8 characters or more.
deleted by creator
Even after a breach people rarely change their passwords: https://techxplore.com/news/2020-05-breach-users-rarely-passwords-theyre.html
On top of my hat… What if user is forced to insert a stronger password? (therefore: the user cannot use the compromised one since the complexity is the same)
Do you find this as an anti-UX constraint?
Well, that’s certainly better than nothing and certainly better than e.g. solely requiring that the passwords may not match, but you still have the problem that dumbasses will choose “1234567” as their next password.
No if you forbid it by design. That was actually what I was asking for.
Ah, I thought you meant “complex” like the complexity rating that password managers or some sign-up forms give you. Because with that, “1234567” is considered more complex than “123456”.
But I guess, you would rather for example enforce that no substrings from the previous password are allowed to show up in the new password.
I think, that would be fine, UX-wise, if you for example require no more than three consecutive symbols to be the same. That should only trigger in rare cases and mostly in cases where it is sensible.
Bonus points, if you recommend the use of a password manager when you detect someone doing that. Because in my experience, it’s almost never the case that people don’t know how a good password would look, it’s just that they’re human.
Yes you are right, I mixed up stength with complexity. :)
Since the user cannot assess password complexity on sight, it may be useful to help the user understanding this complexity. Maybe this?
I have mixed feelings towards password managers I cannot explain. I concede it may be just my ignorance. :)
I used to have mixed feelings about password managers, thinking I’m exposing all my passwords behind just a single password.
But without a password manager, it’s pretty much impossible to use a different password for each service. And that’s really the bigger risk, as services leak password hashes so often, if that hash gets bruteforced once, you’re fucked for every service where you reused that password.
I mean, services can add Salt and Pepper to the password hashes to make bruteforcing the hash harder and the result less useful, but you unfortunately can’t rely on that.