This guidance isn't unique, though it is certainly accurate. Case in point sourced from 1999 when the differences between identification v. authentication in a biometric context were being hammered out: https://web.archive.org/web/19990508102505/http://biometrics...
His name was Lawrence David, but I can't quickly find the writeup that illustrates the point I'm making.
I have accounts I haven't logged into for years, but still need access to. Losing access over time is not a good feature. And a 'reset' with antibiotics doesn't make sense for a bunch of reasons.
Also, password diversity is a good thing. I don't want $COMPANY_A's data breach to expose my password to $COMPANY_B
Yes
Example: iPhone (and Andorid) both have "secure enclaves" where cryptographic keys are stored. However when you step into the basic PC/Linux realm the concept of a secure-device for key storage (TPM) is pretty non-existent outside of corporate players. We can do better, without totally going pie in the sky.
This is why major organisations don't allow usernames to be name_surname or nsurname. They pick random usernames. I remember when I was a student my username was a random string with characters and numbers.
This makes it more difficult to hack my account (without prior knowledge, shoulder surfing, etc.) since it was highly unlikely you could guess my username and my password.
sounds more like an artifact of early garbagey email systems than any sound security policy. certainly i've seen nothing of the sort from any organization since a VM/CMS system in the early 90's.
> This makes it more difficult to hack my account (without prior knowledge, shoulder surfing, etc.) since it was highly unlikely you could guess my username and my password.
this doesn't make any sense.
if i generate my passwords by a perfectly reasonable, robust procedure, and then prepend them with the string "password", and disclose this fact publicly, they become no less secure.
the username is just like a publicly announced string prepended onto your (hopefully) securely generated password.
Does that make sense? I do not imply that password should not be complex etc. I am merely pointing out the benefits of having a difficult to guess username.
no, it does not. just add more bits of entropy to your password if you want more "unguessability". there's no benefit to putting it into the username.
the username and password fields can be imagined as a single field; whether the entropy is at the start or end of the field makes no difference. we just split them up for database efficiency reasons. (and because the username ends up displayed some places.)
> I do not imply that password should not be complex etc.
I do understand that's not your implication
> I am merely pointing out the benefits of having a difficult to guess username.
i'm saying that if your password is good enough, it doesn't matter what your username is.
the same way that if the last 50% of your password is "good enough", it doesn't matter if you plaster the first 50% of it onto billboards.