Website creators seem to not understand that when we register, we are giving them something of serious value - we are giving up our privacy. And I do not give that to strangers in exchange for nothing.
You don't necessarily lose privacy by making up a username and password for a site. You do lose some privacy if you use social sign-on or the site requires you to provide an email address that's verified.
My pet peeve is the arbitrary rules that sites now have for passwords. When I am registering for something I don't care much about just because I have to, my inclination is to use the same easy-to-remember password I always use. But the rules thwart this, and no two sites can agree on the same rules, thus forcing me to alter the password, and guaranteeing that I will not remember it.
Double that pet peeve with Yahoo Groups. No way to make an account without giving them your mobile number (fake number services/landline/Google Voice won't work.) Funny, do you really think Yahoo needs that info?
They could be trying to be helpful by using it for two-factor authentication or as a secure means of sending potentially sensitive information. The problem can happen when well-intentioned security advocates talk about how to increase security and Yahoo takes their advice at face value, without taking into account the needs of people who don't need or want increased security, but would benefit instead from decreased security.
"Could" but I don't think so. No land lines will work, which other 2FA providers support. Only mobile, which is almost as good as an SSN because of portable mobile numbers. 2FA is a crutch to get my mobile number. That, or the fact that every advertised workaround has been "broken" for several years straight in the Yahoo registration process is explained by Yahoo simply being inept.
It depends on the site; especially if I never wanted to register for it at all. It's their security I'm compromising. I don't particularly care if the account I made for some random product information website gets hijacked, that won't affect the important accounts which have different passwords.
I am amazed that you're downvoted, and so many replies are from people who don't think 2 steps ahead and who understand the consequences of their actions in aggregate! The compsci comprehension level around here appears to have gone down from competent programmer/tech savvy to...I don't want to say...
Let me explain to this viewpoint in more detail - I have a rather clear picture for the scenario where "one easy-to-remember password for large number of sites" is the proper action to take.
Thre are a lot of sites that want me to have "an account" so that I can do action X. That includes nearly all my passwords in my password manager. For every account that I want to be secure (say, my email) there are ten accounts that I don't want to have. If I want to do X, I don't want to have an account. "Having an account" is a cost - I have to remember the account's data (even the bit 'do I have an account on fancysite.com?' is a cost). If I have to have an account, I have no need for the account to be mine and mine only. If I have to have an account for me specifically, I have no need for it to be protected from others; but I do need to remember it easily - to avoid the inconvenience of creating a new account.
The site owners often make very different policies, for reasons that benefit them - but they are often opposite to the user needs. All the security problems related to the accounts are the fault of those people who required "an account" in the first place - the Adobe breach is a good example, none of those accounts shouldn't have existed in the first place; none of those people should have been asked their emails; none of those people should have been asked to choose a password. The stricter password requirements Adobe would have made - the worse that would harm the actually important accounts. The sole fact of Adobe asking large number of people for their email address and asking to 'choose a password' - that's a hostile attack that harms mass security on the internet (as the consequences of that breach); we should actively subvert such policies. If a site asks you for an identity more than actually needed (i.e., if they need to ship stuff then they need an address) or asks you for more authentification stuff (choosing passwords, security questions, etc) than you need, then that's [security-wise] hostile to you; if you like that site you can suffer through that but you should do the absolute minimum that fits their policies.
Ignoring client-side tools that hide the complexity, let's list some reasonable possibilities for user authentification for the actual accounts (where I explicitly don't care about others getting access to that account but I care about protecting other accounts) sorting them by ease of use (i.e., how I would like to 'log in' to the site), more preferred options first.
1. No identification or authentification at all. For many scenarios that's the optimum that we'd like to have, but it's prohibited by the site operators, so we're forced to go 'downwards'. #1 on ease of use; #1 on security (no risk to be a proxy for attacks on important accounts), #1 on privacy.
2. Arbitrary identification with no authentification - i.e., I pick a name/tag, and that gets used as a semi-unique handle. This allows semi-personalized communication (i.e., distinguish multiple commenters) or some persistence of data. For some scenarios, e.g., most of online commenting this is the optimal point. On some sites I'd want to 'build a reputation' by having a handle that's unique to me; but on most of them the hassle of remembering an account name is larger than this benefit, so I'd prefer to post with an unauthentificated pseudonym. This again is often prohibited, so we're forced to go 'downwards' or to not use such sites - all the next options are just drawbacks that users choose to take in order to gain access.
3. Authentification without identification - publicly available login data, such as the BugMeNot system. This attempts to go to the goal (#1) by sharing data, but again, those accounts often get prohibited by the operators, forcing us to worse measures further down the list.
4. Username/password - optimizing for ease of remembering. That would ideally be a single username and a single password for everything - i.e., the best password was no password (#3), the next best password is a single, simple, short password such as "password". Again, that doesn't work because [some] site owners have expressly prohibited it, so the next best option is a single, simple, semi-short password with a number of special characters such as "Tr0ub4dor&3" - so that it could actually be single and fit policies of a majority of sites. This approach sucks security-wise, as you note - however, the major security flaw for this is actually not the weakness of passwords, but the weakness of usernames - since the authentification doesn't matter for those sites, but this approach leaks and connects identities, which is bad on principle. However, without moving to things such as password managers which wouldn't work when you sit down on a random untrusted computer, I'm not aware of any better options that don't have this flaw; if there are multiple usernames/passwords, then something needs to remember them; and that something itself needs to be accessible with very easy-to-remember (and most likely completely insecure) settings.
5. "Classic" system of not-the-same IDs (to prevent linking them) and secure, periodically changed passwords that are unique for every site - that's not an option. For the large class of unimportant accounts, the total value of the account is less than the cost of that effort. The only way around this is by client-side systems such as password managers that can automate account creation and maintenance - so that while the "hidden" account is secure, the whole process from the user point of view behaves as one of the previous options. That is also a threat, since then (due to natural habits) people use those tools also for the important accounts, and that opens another source of vulnerabilities for them; in an ideal world I'd choose to have no authentification for the vast majority of places, and I'd be able to remember proper passwords (+2FA) for the couple things that actually matter.
"Too much trouble" is the whole point. The value of security for such accounts is approximately zero - if some solution doubles (or creates?) security but requires an extra click or two, then it's a bad tradeoff that simply shouldn't be done.
Why should people spend any effort at all to secure things that shouldn't be secured in the first place? Why should anyone remember a single bit of info or download an app or spend an extra keypress to protect an account that's already public in intent; but "private" because someone else wanted it to be private?
There are security problems if you use your 'throwaway' password for your primary email (as some of the people on Adobe list have done), but that's not the fault of the throwaway password, but in throwing away the keys to something valuable. That throwaway password should be something that's not a secret, as an equivalent to no password.
It should not even attempt to be protected - it's something that you tell your friends/colleagues openly (so that they'd not have to create their own accounts there, it's quicker to login with yours), post it publicly on the internet (again, bugmenot.com as an example), don't bother to change it years after some site has leaked it, etc. The password as such exists only because someone forces you to some tradeoff of "more security/less usability" - the only reason that the password is not, say, a 0-length string is that you're forced to do so, but there's no reason at all to go any further than the minimum.
For the majority of accounts that I have, the most appropriate level of authentification is not "a reasonable level", not "a minimum", but exactly zero.
I think new models and progress will have to be based on looking at the technologies available, such as cryptography and web protocols, and figuring out what are the best and most convenient systems you can assemble for various levels of security. For instance, a site can track your visits with a cookie, without your creating an account, as long as you use the same browser and the cookie doesn't expire. Cookies seem like almost enough for a lot of scenarios, except that you can't (currently) transfer them to a different browser and there's no standard way to distinguish the person that owns a cookie if multiple people use the same browser.
The value of security for such accounts is approximately zero
If I'm following your logic correctly, you might as well not go to the extra expense of vaccinating your kids, because the anti-vaxxers have already broken down herd immunity.
Even more valuable is that you are giving them access to you. They can now contact you whenever they want. I really detest sites that insist on registration in order for you to even work out what the heck it is they offer (eg access to SDKs, whitepapers etc behind registration).
You're not giving up your privacy by making an account and even if you did, it doesn't have a serious value. A few bucks tops, more likely a few cents.
