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.
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.
> 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.
Don't you think you're overstating it? Assuming privileged accounts require a secure password, what is the risk here except for an individual with a poor password's information? This person is responsible for their own weak password. Putting a weak password warning is about as much responsibility as a site owner has here. Security policies are always a trade-off between securing information and usability. People seem to forget that around here.
And in this case, I am talking specifically about security policies for sites that store credit card information, like specialforces.com did. I do not believe that having no password is an acceptable trade-off in this situation.
Let's be honest, encouraging users to add capital letters, numbers, and symbols does not make their passwords more secure. When you force people to add uncommon characters to passwords they stick to the simplest cognitive model:
Okay, so use a better password creation rule/pattern set like the one in that comic. Just don't throw up your hands and say "oh well, everything will be cracked in 3 days so it's worthless to do anything."
I really don't understand why anyone stores CC's. You don't need the number ever again after the initial transaction. Even for reoccurring transactions. Authorize.net needs only the transaction id for a refund, which can't be more than the original transaction or the API kicks back. You can also send in certain commands to their API to mark a user as reoccurring, thereby negating the need to store the CC for future use, let alone storing the CVC.
If for some reason you don't want to use authorize.net, use paypal, which also has an API, though no one seems to use it. You don't have to see a single paypal logo, and can use paypal as a raw gateway, leaving the user none the wiser that the transaction is even going through paypal.
Paypal is actually a good option to save money if you are a small startup and can't afford the high cost of a merchant account, though those costs are getting lower and simpler as every day passes.
I also find their API a little simpler to use that authorize.net. Though I have a nice library for authorize.net that I have tuned over the years to account for the hundreds of possible error codes they may return and how I will handle those cases.
Paypal is a little steep on the per transaction fee and the percentage that they take, so if micro sized payments is your game, they may not be ideal. Anything over $5.00 and you should be good. And again, with paypal, just like authorize.net, you don't need to store a credit card number ever.
It makes no sense why this is happening. It simply shouldn't be happening. And the certification is a joke. The steps that some of these CC certification companies make you go through weaken security, and are often arbitrary. But what do you do? My HOA charges a $20.00 fee to pay by credit card. This is against the terms of their merchant provider as per VISA's terms and conditions. I have tried to report it 3 times now, and give up in frustration before I ever get close to being transferred to the correct department. My HOA should have their merchant account yanked for that behavior, as should any merchant who mandates a $5.00 minimum purchase rule at the counter.
I have taken steps to protect myself by using a unique password for every site, as long as allowed. My defaults are letters, numbers, and symbols, 32 characters in length. The password manager I use will adjust down if the site can't handle the length or characters. Yet I run into sites that mandate a 6 character password of letters only. Ugh. A bank being the 6 character one.
My main protection these days is to use gift cards and pre-paid visa cards. Apple screwed my account and I will never trust them with my CC again. Not for security reasons, but because if you ever ask support a question, they seem to think you are reporting a fraud case, and blacklist your CC for life. I had a business card that was shared with 10's of users, all of which now had to create a new Apple ID password, re-enable all iCloud services, and reset a ton of stuff.
Solution? $50.00 gift cards for everyone, they can get a new one at any time the old one runs out. No more CC's in Apple's kit ever again.
For the rest of the sites, I use pre-paid visa cards that have $100.00 on them. I figure I am OK to get burned on $100.00. If the purchase is any greater, and I need the protection of a real VISA card, I may take the chance, but I will look the site over carefully.
This is a lot to ask of your average user, and I consider this the bare minimum attitude that someone should have to online purchasing.
Or, just order everything from Amazon and don't do any CC transactions with anyone else. Look at the html source of ATT.com and tell me you trust them with anything at all.
Absolutely, as I said I outsource all storing of credit card information to Authorize.net. Storing them myself is not a responsibility that I would take lightly and I'm sure they'll do a better job than me.
For passwords, while I do not force users to have secure passwords, I of course allow complex passwords (including 32 characters with any symbols and so on) because this is what I use and if there's one thing I hate, it's websites like my bank that force me to only use 6 numbers for the password.
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.
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?
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.
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.
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.
Right, so you admit that there is no actual bearing on the security of the overall application, just individual user accounts. I think that's worth clarifying.
I don't like sites that make me use a "special character" very much because they break my automated alphanumeric password generation scheme. I store these passwords in an encrypted container that I reference whenever I want to use the site. The passwords I use are always huge, but I leave punctuation out for convenience in selecting the text with double-click. :) I think that my alphanumeric mixed-case very long passwords are safe enough without requiring punctuation.
I also occasionally run into length limits on passwords which I'm sure we all agree is silly. But encouraging enforcement of complexity standards somehow seems to make some people think they can place arbitrary limits for the convenience of their VARCHAR() fields or something.
People will either use a password they can remember or reset their password every time they go to your site, which will not only make it really annoying to use your site but also doesn't do much good anyway since the password is then behind their weakly-passworded email account.
I understand that exposing this information allows an attacker to know more about my potential passwords and maybe to enhance his ability to crack them. I'm not really worried about anyone doing that and I'm confident that the information I provided isn't a total giveaway. ;)
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.