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. ;)
I agree, much nicer and smoother than constantly getting removed from various upload sites and traversing through acres of dead links before you finally find a valid mirror, and a lot safer than something like BitTorrent.
Never a good idea, unless you want people to give you money via credit card. From my experience, having one of those badges on your checkout form results in a measurable increase in conversions, even if it doesn't mean anything to people who understand security.
I doubt that this is the case. I'd expect to see it on a lot more sites were it true. I'm guessing some other factor created your measurable increase. Willing to be proven otherwise though.
I would love to see an A/B comparison of this. For me, if I see those badges, I assume the site doesn't know what they are doing, as they should know, any GoDaddy automated scanner is not worth the wasted disk space from the hits in your httpd logs. Any programmer that aspires to show those logos is dangerous and that site will not get my personal information.
I don't think this is so much a question of liability as it is one of customer perception. If 'GoDaddy Secured' sites aren't really secure and start getting hacked, then 'secured by GoDaddy' signs will mean no more than "hackable in 10 minutes or it's free". We'll see how GoDaddy squirms when that happens.
I think that beyond customer perception, there is an actual question of legal liability here. If GoDaddy is purporting to be an expert in security and selling a service, that is supposed to ensure security, then they should be found liable for some degree malpractice.
I'd love to get a real lawyer's opinion on this...
Hacking a server is a very specific act, different from hacking a website. One exploits weaknesses in the underlying OS - the other exploits weaknesses in the publicly exposed software running on the server. To the end viewer, there may be no difference, but the "how they got in" would determine the liability.
If anon breached the OS, then common sense would say GoDaddy is somewhat responsible. Otherwise, it pretty much falls on the client. All the hardening in the world can't patch for stupid.
The "Hacker Proof" badges are supposed to verify your web application as well, but this attack could have been entirely non-technical social engineering to get access to the cart admin account or MySQL username/password. We don't have any details right now at all as far as I know and I tend to doubt they will be forthcoming.
In fact, I doubt that specialforces.com will even inform users of this breach. They don't seem to be especially security-savvy and the initial reaction of secuirty-naive businesses is to keep something like this under wraps so it doesn't hurt their reputation.
Of course, this is just idle speculation and they could have already informed users. I have no malintent. That's just how I read the situation and the likelihoods involved.
Let's be honest here. Has any "Secured by X company" certification ever actually meant a damn thing? I swear I hear reports about sites like this getting broken into every week. Those banners are basically the equivalent of painting a target on your back.
I can't find a source just now, but I recall reading somewhere that user testing showed a much higher signup/purchase rate when using those sorts of 'certified hacker-proof' badges, with very little difference between
'legitimate' (from recognisable anti-virus/whatever brand name organisations) certificates and completely arbitrary ones.
I guess it's mostly about the perception of authority / security theatre.
I agree with you, these certifications are generally crap. My company signed up for Hacker Proof a few years ago (badges and shields look secure, ya know), and it found one SQL injection vuln we had in some old Classic ASP stuff that nobody used but was still out there. That was good, of course, but I'm sure it was the equivalent of running an off-the-shelf fuzzing app.
While I find it's awesome that people like this bring these security issues to attention, at least leave the CC & password details out. Sure, you got them, whoopty-doo, we believe you. Still isn't moral to share them.
Different set of morals. Just by virtue of buying tactical gear through specialforces.com -- which a LOT of people do, not necessarily cops or military, btw, and most of those people are good honest citizens. Most of the LEO/mil folks who do are good honest citizens. But to them it is just as moral to leak credit card info because of guilt-by-association as certain cops think it's moral to hose down a 62-year-old man with pepper spray until he's dead.
Former Soldier, the type that would have purchased things from sites like this before venturing overseas, and I'm highly annoyed by the childish nature of this hack.
Some of these products keep people alive, and it's juvenile to blame SpecialForces.com for pepper spray during a protest.
If they were really intending on improving the security of these websites, they wouldn't hand out the data. Sadly, I fear that the worst of this type of behavior has yet to come.
I haven't downloaded the dump files yet, but from what I can tell, their entire db was stolen. Meaning, customers' names, emails, addys, credit cards, etc. But most importantly, they were able to decrypt the customers' passwords back into plain text, too...
Judging by all the bitcoin-exchange-related spam I received after the MtGox database was stolen, my guess is that even if they don't bother to, their competitors will happily notify their customers via email for them.
This was just a hack of a random e-commerce site. They (like thousands of similar small businesses) sell equipment to police and weekend warriors.
The title is a bit misleading, the site had a "Secured by GoDaddy" logo on it, because the site had purchased its SSL certificate from GoDaddy and they throw the security logo thing in for free.
EDIT: My bad. They also paid the $4.99/month for the "Hacker Safe" logo.
Notice how they have 2 godaddy badges. The one of the right is the SSL one, as you're describing. The one on the left however, actually reads: "Hacker Proof... Scanned by...".
Under the "Common Threats" tab, they claim to find "spyware, back doors, SQL injection opportunities and cross-site scripting (XSS) holes".
They also imply that they check input fields "properly", since "When fields aren't checked properly, hackers can insert code that exposes everything in your database."
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.