4 ms·

Ah, yes, one easy-to-remember password for large number of sites is definitely a great way to protect your security. /s Complaining about loss of privacy, but

by vdaniuk 12y ago

Ah, yes, one easy-to-remember password for large number of sites is definitely a great way to protect your security. /s Complaining about loss of privacy, but eagerly weakening your security for convenience. I don't understand this argument at all.

mtdewcmu 12y ago
I wasn't complaining about loss of privacy. I was talking about when I have to create an account that I don't need just because the site requires it.
tim333 12y ago
Works for me with sites I don't give a damn about.
pjc50 12y ago
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.
aestra 12y ago
Yeah, because you need industrial strength security to download Java or protect your precious NCAA brackets.
stcredzero 12y ago
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...
- PeterisP 12y ago
  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.

by vdaniuk 12y ago

mtdewcmu 12y ago

I wasn't complaining about loss of privacy. I was talking about when I have to create an account that I don't need just because the site requires it.

tim333 12y ago

Works for me with sites I don't give a damn about.

pjc50 12y ago

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.

aestra 12y ago

Yeah, because you need industrial strength security to download Java or protect your precious NCAA brackets.

stcredzero 12y ago

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...

PeterisP 12y ago
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.