Specialforces.com Site Hacked
pastebin.com
pastebin.com
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.
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.
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.
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.
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.
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?
Not having a password creation rule is just one heuristic that I have started to use to indicate poor security.
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.
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.
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'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.
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.
I guess it's mostly about the perception of authority / security theatre.
Equally morally bankrupt positions.
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.
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.
http://www.godaddy.com/security/website-security.aspx
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."
Line 30:
"In reality, for the past few months, we have been in possession
of approximately 14,000 passwords and 8000 credit cards from
SpecialForces.com."
Line 36-37: "http://[redacted].gz <- orders/addresses/ccs
http://[redacted].txt <- just the passwords"