FWIW, the reports are saying these accounts were compromised due to credential stuffing attacks. While, Intuit can do something about credential stuffing by being proactive and hooking into haveibeenpwned etc. but they were not "breached" in an intrusion sense.
I'm surprised they don't do multifactor setup as part of the onboarding process. They offer full blown TOTP[1] but even if it's just SMS based it'd do a lot to mitigate these credential stuffing attacks.
I think you are letting TurboTax off too lightly. Many banks and the UK tax office make their login credentials unique by having a username with random characters, or requiring an account number on login.
That is not the solution. Usernames are not passwords. If they were, why have them at all? Generate a random unique password for your user and don’t have a username at all. As the parent mentioned using haveibeenpwnd or similar service is a much more user friendly and secure approach.
> That is not the solution. Usernames are not passwords. If they were, why have them at all?
Claiming that usernames cannot be a source of entropy/security needs foundation.
Back when the whole concept of authentication was new (UNIX) that was true because usernames were quite literally public information, you could see them via a directory listing. With early email (SMTP) that remained true but worse via public directories listings across-computer.
However in this context there's nothing inherent about a username that allows us to ignore its security characteristics. Unless the argument is "over the shoulder" leakage? Which I'd argue itself doesn't have a strong foundation.
Both obscure usernames and obscure passwords can contribute to the overall strength of a system. A system that allows the user to set their own password may gain particularly from pre-selected randomized usernames, as users have proved untrustworthy in the past when picking passwords (e.g. reuse, patterns, common words, etc).
As an aside, scrapping usernames and only having a password isn't inherently problematic, except two users with the same password may clash, and a password recovery scheme may be more difficult to develop. That's essentially what authentication tokens are.
> Generate a random unique password for your user and don’t have a username at all.
Because having an unknown username with an unknown password increases the difficulty of compromise via improved entropy.
I agree there is nothing technically bad about using usernames as more entropy (it is bad from a user experience standpoint), but why have two strings at all? Just have one longer, truely random string.
> Because having an unknown username with an unknown password increases the difficulty of compromise via improved entropy.
Not necessary. It depends on the characteristics of each. If the username is truely random, sure, but then you are back in the same boat as using one random string.
Right; why have them at all? Why not log in with a UUID or something randomly generated. Use a 'password store' tool, and forget about the pointless username.
Further, do some automatic challenge-response thing between the server and yourself so you are authenticated to the server, and the server is authenticated to you. Which the current username/password scheme doesn't do at all.
Our current default state (username/password where both are human-rememberable) is failing us massively. Its arbitrary, historical and currently pointless.
With a single random password most people will write down their password, so anyone who can read what was written down gains full access. With a random username and a user-chosen password most people will write down their username but not their password. Clearly this approach is more secure.
I don't see how relying on haveibeenpwnd can be considered secure. Many people use the same password for different sites. If your site's login credentials are just email+password you are relying on the security and honesty of all other sites that use the email+password combination.
> With a single random password most people will write down their password, so anyone who can read what was written down gains full access. With a random username and a user-chosen password most people will write down their username but not their password. Clearly this approach is more secure.
I don't believe this is grounded in evidence. You are basically saying that given two hard to remember strings, most people will write down one hard to remember string and not the other hard to remember string. Why?
> I don't see how relying on haveibeenpwnd can be considered secure. Many people use the same password for different sites. If your site's login credentials are just email+password you are relying on the security and honesty of all other sites that use the email+password combination.
I think you are missing the point of the haveibeenpwnd service. The point is to block people from using ANY password that is listed in the haveibeenpwnd database, thus denying attackers from using that dictionary of known passwords.
A string is not that hard to remember when it is a password you thought up and have been using for 10 years. OK I cannot offer proof that most people would not write down their password, but surely some would not - and for those people having a separate User ID/password combination represents improved security. But anyway this is beside the point, which is that adding random characters to user credentials improves security - whether those credentials are 1 or 2 strings - and would have prevented this TurboTax attack.
Yes, using the haveibeenpwnd service offers some level of protection. But it still allows an attacker to breach a random website like funnycatpictures.com and find the email/password combinations that are not on haveibeenpwnd. Boom, that attacker has access to all those users' tax information.
[edit]: Here is a source with more info - https://www.scmagazine.com/home/security-news/intuit-the-com...