4 ms·

And I thought we were getting away from arcane rules for passwords. Now you have to avoid every compromised password from any unrelated account? I may use rando

by cpburns2009 8y ago

And I thought we were getting away from arcane rules for passwords. Now you have to avoid every compromised password from any unrelated account? I may use random passwords, but I don't expect the typical consumer to do the same. Sometimes I simply don't care about security for a one off account on a free service where I'll happily use the simplest permutation of "password" for the password.

rmtech 8y ago
If the service doesn't care about security at all then you could just not have a password, log on using your email. If it cares a little bit then you have to characterize exactly how bad it would be if the account was compromised. The right solution might be to just accept any non-blank password that's less than 32 chars or something.
- pbhjpbhj 8y ago
  In theory blank passwords aren't a problem for some sites, because usernames shouldn't be the same as display names, and usernames can carry enough entropy to deter simple attacks from outside the organisation?
geofft 8y ago
The existence of password breach databases means that attackers are already attempting other people's passwords against your accounts. We should honestly move to the world where typical consumers are using password managers that generate passwords randomly. I think it is pretty reasonable to expect the typical consumer to install and use a password manager; I think it's pretty unreasonable to expect the typical consumer to generate memorable, strong, and unique passwords for each website and store them in their head.
- AmericanChopper 8y ago
  Even putting online attacks aside, breached password lists make fantastic dictionaries for cracking hashes.
- blackflame7000 8y ago
  Realistically even a dictionary attack for a login service should have some sort of flag after repeated incorrect passwords or at least be rate limited to some degree. It would really only be bad if they gained access to your hashed passwords database table because then the dictionary attack would immediately hit for some weak passwords. I argue that access to the hashes shouldn’t be allowed in the first place.
Dylan16807 8y ago
Most people don't know how to make a good password. So don't let them make a bad password, and make that easy by providing a button that generates good ones. "It has to be new" is about as elegant as you can get for password rules. You can use any secure method you want. Whatever characters you want, just don't do it wrong. If you want it to be easier, press the button. Even with a one-off account, a complex password you don't bother to remember is better than a weak password, because the service won't have to deal with tons of misused accounts.
- tomjen3 8y ago
  Better for the service, theoritically, but not better for me. I say better for the service theoritically because I probably won't sign up (less of an issue since I moved to LastPass, but still annoying because so many sites don't work with autofill.)
  - lexicality 8y ago
    (FYI lastpass is a bit of a shitshow, I'd recommend using a different service)
    - tomjen3 8y ago
      Can you expand on it, and which choices are better?
      - lexicality 8y ago
        Starting point would be https://en.wikipedia.org/wiki/LastPass#Security_issues https://en.wikipedia.org/wiki/LastPass#Security_issues, but there's a variety of other things like automatically filling passwords making you vulnerable to XSS based password stealing, the general disrepair of the extension, it being owned by logmein, the "two factor auth" being entirely clientside (the extension will actually fully start up and autofill whatever page you're on before prompting you for a code) and the fact that they're still trying to charge me for a premium subscription I cancelled ages ago. Personally I use 1password, but there are loads of other ones that don't have a list of security breaches on their wikipedia page.
pjbster 8y ago
I think every entity which holds a password should adopt the same policy: from the moment the password is created, the entity will undertake to do everything it can to try and break it. Whatever it takes - bot farms, 3rd-party white hat outfits, social engineering in the canteen, whatever. Anything (legal) goes. Once the password is broken, the account will immediately be placed in suspense until the owner creates a new password. Which, of course, immediately gets fed back into the machine and life goes on. This would eliminate password rules. If you want to create a password which consists of, say, 100 consecutive zeros, go for it. But you might only get to use it for a fraction of a second if the network can break it quickly.
- nsgi 8y ago
  I can see a few problems with that approach: - It's already fairly straightforward to predict how easy a password will be to crack e.g. if you're going to bruteforce dictionary passwords or those with predictable combinations of characters, why not just include those in your password blacklist? - Randomly suspending users' accounts and telling them to change their passwords is going to annoy them (especially if it happens repeatedly) and consume support resources - It's overkill unless the service is security critical - How easy a password is to crack is partly a function of the hash algorithm and salting the entity uses so it may not be the user's fault their password gets broken

rmtech 8y ago

If the service doesn't care about security at all then you could just not have a password, log on using your email. If it cares a little bit then you have to characterize exactly how bad it would be if the account was compromised. The right solution might be to just accept any non-blank password that's less than 32 chars or something.

pbhjpbhj 8y ago
In theory blank passwords aren't a problem for some sites, because usernames shouldn't be the same as display names, and usernames can carry enough entropy to deter simple attacks from outside the organisation?

geofft 8y ago

The existence of password breach databases means that attackers are already attempting other people's passwords against your accounts. We should honestly move to the world where typical consumers are using password managers that generate passwords randomly. I think it is pretty reasonable to expect the typical consumer to install and use a password manager; I think it's pretty unreasonable to expect the typical consumer to generate memorable, strong, and unique passwords for each website and store them in their head.

AmericanChopper 8y ago
Even putting online attacks aside, breached password lists make fantastic dictionaries for cracking hashes.
blackflame7000 8y ago
Realistically even a dictionary attack for a login service should have some sort of flag after repeated incorrect passwords or at least be rate limited to some degree. It would really only be bad if they gained access to your hashed passwords database table because then the dictionary attack would immediately hit for some weak passwords. I argue that access to the hashes shouldn’t be allowed in the first place.

Dylan16807 8y ago

Most people don't know how to make a good password. So don't let them make a bad password, and make that easy by providing a button that generates good ones. "It has to be new" is about as elegant as you can get for password rules. You can use any secure method you want. Whatever characters you want, just don't do it wrong. If you want it to be easier, press the button. Even with a one-off account, a complex password you don't bother to remember is better than a weak password, because the service won't have to deal with tons of misused accounts.

tomjen3 8y ago
Better for the service, theoritically, but not better for me. I say better for the service theoritically because I probably won't sign up (less of an issue since I moved to LastPass, but still annoying because so many sites don't work with autofill.)
- lexicality 8y ago
  (FYI lastpass is a bit of a shitshow, I'd recommend using a different service)
  - tomjen3 8y ago
    Can you expand on it, and which choices are better?
    - lexicality 8y ago
      Starting point would be https://en.wikipedia.org/wiki/LastPass#Security_issues https://en.wikipedia.org/wiki/LastPass#Security_issues, but there's a variety of other things like automatically filling passwords making you vulnerable to XSS based password stealing, the general disrepair of the extension, it being owned by logmein, the "two factor auth" being entirely clientside (the extension will actually fully start up and autofill whatever page you're on before prompting you for a code) and the fact that they're still trying to charge me for a premium subscription I cancelled ages ago. Personally I use 1password, but there are loads of other ones that don't have a list of security breaches on their wikipedia page.

pjbster 8y ago

I think every entity which holds a password should adopt the same policy: from the moment the password is created, the entity will undertake to do everything it can to try and break it. Whatever it takes - bot farms, 3rd-party white hat outfits, social engineering in the canteen, whatever. Anything (legal) goes. Once the password is broken, the account will immediately be placed in suspense until the owner creates a new password. Which, of course, immediately gets fed back into the machine and life goes on. This would eliminate password rules. If you want to create a password which consists of, say, 100 consecutive zeros, go for it. But you might only get to use it for a fraction of a second if the network can break it quickly.

nsgi 8y ago
I can see a few problems with that approach: - It's already fairly straightforward to predict how easy a password will be to crack e.g. if you're going to bruteforce dictionary passwords or those with predictable combinations of characters, why not just include those in your password blacklist? - Randomly suspending users' accounts and telling them to change their passwords is going to annoy them (especially if it happens repeatedly) and consume support resources - It's overkill unless the service is security critical - How easy a password is to crack is partly a function of the hash algorithm and salting the entity uses so it may not be the user's fault their password gets broken