5 ms·

As I'm currently in the middle of a research project on password security, I downloaded the passwords and had a look. I'm beginning to believe that you should j

by tansey 15y ago

As I'm currently in the middle of a research project on password security, I downloaded the passwords and had a look. I'm beginning to believe that you should just assume that if your site does not have any password creation rules, it will be hacked soon. The specialforces password dataset contains passwords like "post"-- four lowercase letters found in any English dictionary, and even matches part of the email (@post.ca.gov) for the user. If a site lets you choose this as your password do not give your credit card info to that site, simple as that. A site that is built by someone who is so unaware of the basics of password security is likely following other insecure practices as well, like storing your data in plaintext and not properly sanitizing user input. All the major recent attacks (phpbb, singles.org, rockyou, battlefield heroes beta, faithwriters, and now specialforces) have had this same glaring issue in common. In reality, if these sites are letting users choose any password then for the majority of users you might as well just store them in plaintext. Most users (70-90%), if left to their own discretion will choose a 6 or 7 character password with all lowercase letters, meaning it will be trivial to crack even if it's hashed and salted.

gommm 15y ago
While I agree with you, adding special restrictions on passwords is a way to lose some customers (who can't be bothered or never remember their passwords). So while I know about basic security practices and will always store passwords with bcrypt, sanitize user input and not store any purely private data in plaintext, I'm not going to make a decision about password security that might mean losing customers. EDIT: To answer the questions below. Of course, I would not allow people with administrative access to use weak passwords. But if a user uses a weak password and someone gets access to his account, he can't do all that much (save for changing the plan the user pays, which can be easily reversed)... I'm not responsible for users choosing weak password, however I'm responsible for making sure that no user data/passwords and so on is leaked due to security breach. And that's why I use bcrypt to encrypt password, that's also why I outsource the storing of credit card numbers to authorize.net or other companies that are more competent than me, why I secure as much as possible the website. All of this is a matter of trade offs. Currently, the only websites that I manage that have credit card numbers on files for some users sell virtual/digital goods. So, it would be very easy for me to refund a transaction if it was fraudulent (and in my interest to do so to avoid chargebacks anyway). I might have a different view point in different circumstances.
- iamdave 15y ago
  NO company that puts sales/profits before security of my billing information is a company I'd ever do business with.
  - hackinthebochs 15y ago
    How is standard, restricted user password security in any way related to site security (assuming the site is consciously making the tradeoff)?
    - iamdave 15y ago
      That's an exercise with a huge multitude of variables, but at the core, a website that cares more about selling widgets / booking accounts to the point of reducing its depth of defense with user passwords leaves a very sour taste in my mouth.
      - sbov 15y ago
        Most sites out there must leave a sour taste in your mouth then, including Amazon, Netflix, and Newegg.
- tansey 15y ago
  > will always store passwords with bcrypt, sanitize user input and not store any purely private data in plaintext, I'm not going to make a decision about password security that might mean losing customers. This seems incredibly short-sighted, highly unethical, and a breach of the perceived (or possibly legal, IANAL) fiduciary responsibility of an e-commerce site. You are knowingly and willingly risking your customers' sensitive data and, by extension, their financial well-being in order to benefit in the short term. Edit: In response to the above edit, my whole point is simply that if you are trusting your credit card details to a site, then you should be confident in the security of that site. I meant that it appears from all evidence I've seen that a good heuristic is to say that no creation rules implies an insecure site overall. This won't be true for all sites of course, since it's abductive reasoning, but I think in practice it's useful. Another important point I made is that there is no point in saying "I use bcrypt" as a defense here. If you let users choose any password without any checks, they will choose passwords that are short, common, and consequently easy to crack, even if hashed and salted via bcrypt. It may take 1000x longer than if they were encrypted with just a salted MD5, but we're still talking about effectively instantaneous cracking in either case. I'm not sure why everyone thinks I'm overreacting here. If your users cannot see/access their cc info because it's stored securely via some other service then I suppose that is a lot better, since an attacker cannot actually gain access to the credit card data. Still, it just seems wrong to me to be so insecure about user information simply because they don't understand/care about the potential consequences right now.
danneu 15y ago
Passwords of users with power should be secure, but I don't see how that has anything to do wtih the password creation rules of a website. My HN password being "post" for my own convenience doesn't affect anyone else on HN, and it certainly doesn't allow anyone to root HN's server. How do password restrictions save the say except dictate the amount of risk of my own personal data that I'm willing to take?
- tansey 15y ago
  HN is very different from an e-commerce site. If you are giving your credit card information over to a site, and especially if that site saves cc info, then you should be pretty sure that the site is securely storing your data, because now it's more than just an HN user account you're potentially losing-- it's real money, identity theft, etc. Not having a password creation rule is just one heuristic that I have started to use to indicate poor security.
  - cookiecaper 15y ago
    I still don't really get it. If a user keeps their CC hooked into an e-commerce site behind an account with a four-character password, how does that compromise the security of the actual system and not just that user's own data (including the credit card they willingly put into an account with a simple password)? Users should be responsible for their own passwords in my opinion, I don't see what value we get out of making normal, non-admin accounts use long passwords. Is a six or eight character minimum really going to matter to anyone? If they can crack your four character alphabetic lowercase password, they can crack your eight character alphabetic lowercase password. I just see no reason from an application security perspective to enforce password minimums.
    - tansey 15y ago
      Sure, outside of some small information gain about which hashing/salting algorithm you're using-- which is usually known to the attacker anyway-- there is no real risk to the rest of the users. I just disagree that each user should be responsible for their own security on sites that store critical information but are used by technologically naive customers. There are better rules that can be enforced than just password minimums, and they will make it harder to crack the password. Even if they continue to choose a relatively weak password, given a decent creation rule set (e.g., 8 characters, an uppercase, a digit, and a special character) it will at least make the attacker go from milliseconds to hours. If you have a large enough userbase, and each account is salted, then you may actually have herd immunity for those weaker passwords, since the attacker now has to spend hours per account.

by tansey 15y ago

gommm 15y ago

While I agree with you, adding special restrictions on passwords is a way to lose some customers (who can't be bothered or never remember their passwords). So while I know about basic security practices and will always store passwords with bcrypt, sanitize user input and not store any purely private data in plaintext, I'm not going to make a decision about password security that might mean losing customers. EDIT: To answer the questions below. Of course, I would not allow people with administrative access to use weak passwords. But if a user uses a weak password and someone gets access to his account, he can't do all that much (save for changing the plan the user pays, which can be easily reversed)... I'm not responsible for users choosing weak password, however I'm responsible for making sure that no user data/passwords and so on is leaked due to security breach. And that's why I use bcrypt to encrypt password, that's also why I outsource the storing of credit card numbers to authorize.net or other companies that are more competent than me, why I secure as much as possible the website. All of this is a matter of trade offs. Currently, the only websites that I manage that have credit card numbers on files for some users sell virtual/digital goods. So, it would be very easy for me to refund a transaction if it was fraudulent (and in my interest to do so to avoid chargebacks anyway). I might have a different view point in different circumstances.

iamdave 15y ago
NO company that puts sales/profits before security of my billing information is a company I'd ever do business with.
- hackinthebochs 15y ago
  How is standard, restricted user password security in any way related to site security (assuming the site is consciously making the tradeoff)?
  - iamdave 15y ago
    That's an exercise with a huge multitude of variables, but at the core, a website that cares more about selling widgets / booking accounts to the point of reducing its depth of defense with user passwords leaves a very sour taste in my mouth.
    - sbov 15y ago
      Most sites out there must leave a sour taste in your mouth then, including Amazon, Netflix, and Newegg.
tansey 15y ago
> will always store passwords with bcrypt, sanitize user input and not store any purely private data in plaintext, I'm not going to make a decision about password security that might mean losing customers. This seems incredibly short-sighted, highly unethical, and a breach of the perceived (or possibly legal, IANAL) fiduciary responsibility of an e-commerce site. You are knowingly and willingly risking your customers' sensitive data and, by extension, their financial well-being in order to benefit in the short term. Edit: In response to the above edit, my whole point is simply that if you are trusting your credit card details to a site, then you should be confident in the security of that site. I meant that it appears from all evidence I've seen that a good heuristic is to say that no creation rules implies an insecure site overall. This won't be true for all sites of course, since it's abductive reasoning, but I think in practice it's useful. Another important point I made is that there is no point in saying "I use bcrypt" as a defense here. If you let users choose any password without any checks, they will choose passwords that are short, common, and consequently easy to crack, even if hashed and salted via bcrypt. It may take 1000x longer than if they were encrypted with just a salted MD5, but we're still talking about effectively instantaneous cracking in either case. I'm not sure why everyone thinks I'm overreacting here. If your users cannot see/access their cc info because it's stored securely via some other service then I suppose that is a lot better, since an attacker cannot actually gain access to the credit card data. Still, it just seems wrong to me to be so insecure about user information simply because they don't understand/care about the potential consequences right now.

danneu 15y ago

Passwords of users with power should be secure, but I don't see how that has anything to do wtih the password creation rules of a website. My HN password being "post" for my own convenience doesn't affect anyone else on HN, and it certainly doesn't allow anyone to root HN's server. How do password restrictions save the say except dictate the amount of risk of my own personal data that I'm willing to take?

tansey 15y ago
HN is very different from an e-commerce site. If you are giving your credit card information over to a site, and especially if that site saves cc info, then you should be pretty sure that the site is securely storing your data, because now it's more than just an HN user account you're potentially losing-- it's real money, identity theft, etc. Not having a password creation rule is just one heuristic that I have started to use to indicate poor security.
- cookiecaper 15y ago
  I still don't really get it. If a user keeps their CC hooked into an e-commerce site behind an account with a four-character password, how does that compromise the security of the actual system and not just that user's own data (including the credit card they willingly put into an account with a simple password)? Users should be responsible for their own passwords in my opinion, I don't see what value we get out of making normal, non-admin accounts use long passwords. Is a six or eight character minimum really going to matter to anyone? If they can crack your four character alphabetic lowercase password, they can crack your eight character alphabetic lowercase password. I just see no reason from an application security perspective to enforce password minimums.
  - tansey 15y ago
    Sure, outside of some small information gain about which hashing/salting algorithm you're using-- which is usually known to the attacker anyway-- there is no real risk to the rest of the users. I just disagree that each user should be responsible for their own security on sites that store critical information but are used by technologically naive customers. There are better rules that can be enforced than just password minimums, and they will make it harder to crack the password. Even if they continue to choose a relatively weak password, given a decent creation rule set (e.g., 8 characters, an uppercase, a digit, and a special character) it will at least make the attacker go from milliseconds to hours. If you have a large enough userbase, and each account is salted, then you may actually have herd immunity for those weaker passwords, since the attacker now has to spend hours per account.