We got hacked
name.com
name.com
This language is such a turn-off. Very few organizations can use that type of flippant language successfully, especially in a serious email like this. Now's not the time to try to be hip or cool. This is a serious issue and the writer should be just as serious.
Edit: Their site is down now so here's a copy of their post
Many of you received our email or saw online that name.com was hacked. The truth is that it's one of the more painful admissions that can be made on the Internet. We want you to know that when we say that we “give a shit” we truly mean it. In an effort to maintain the open, honest, and transparent reputation we’ve built for ourselves, we’re going to give you the lowdown on what happened and what we did in response.
Our security team alerted us that unauthorized individuals had accessed our database. After doing some digging we found that the attack seemed to be geared toward a few specific accounts. The hackers had a target and name.com was a means to that end.
The information that was accessed includes usernames, passwords, physical addresses, email, hashed passwords and encrypted credit card data. EPP codes (required for domain name transfers) are not stored in the same place so those were not compromised. For the techies who are wondering, the encryption on the credit card information is 4096 bit RSA. Since the password hashes were compromised we took proactive steps and initiated a site-wide password reset (hence the email, apologies for the inconvenience).
We are genuinely sorry for the annoyance and the scare. We’re taking this incredibly seriously and are doing everything possible to continue to improve the security of our systems. We greatly appreciate the support across the web and over the phones.
(Also, fwiw, I am grossed out by casual references to poop, no matter how nicely they say it, but especially when using the S word. I am very prone to F bombs, but, then, I actually like sex. But references to poop have me envisioning it. No thanks. Ick. Y'all are disgusting. And, though perhaps not the norm, I am probably not the only person who dislikes having images of poop forced upon them, even if others don't necessarily have the quirk of finding it more offensive than the F word.)
"You don't have permission to access /blog/general/2013/05/we-got-hacked/ on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request."
Edit: And, their bulk domain search still appears to be broken for entering more than five domain names: http://www.name.com/names
Edit2: The new error with their blog post:
The webpage at http://www.name.com/blog/general/2013/05/we-got-hacked/ has resulted in too many redirects.
Oh, and gandi.net for TLDs I can't get from namecheap, like .io, .cx.
http://community.namecheap.com/blog/2011/12/29/25000-eff-don...
I also have one domain at networksolutions (it was worth a $100 difference over five years vs gandi), but I definitely would avoid them in the future. As soon as I ordered, they started calling once per day attempting to sell further services. They are on my avoid list now.
I've never done it myself but I've read it in multiple occasions so it might be worth checking if you're really looking at moving away.
Edit: here's a great way to show personality without being crude http://www.name.com/aboutus#/ourTeam
In all cases I'd rather deal with real people than whitewashed "employees". In many ways I'm glad they offended someone over the word "shit" because it means they're being at least a little true to themselves.
I disagree.
Blunt honesty without being crude: We screwed up, we're sorry.
Avoiding being generic without being crude: We want you to know that when we say that this matters to everyone in the company, we truly mean it.
If that doesn't sound like whitewashed corporate-speak, I don't know what does. It sounds like an empty platitude and I wouldn't even believe it if someone said that to me.
I wish I could still edit my original post to put this in.
We value you as a customer and appreciate your business. Thank you for your consideration, and don't forget to sign up for our newsletter.
"Name.com is a fully accredited ICANN domain name registrar. In addition to great pricing and service, we offer SSL certificates, web hosting, premium and expired domains. Most importantly, we've been giving a $#*! since 2003!"
"Name.com is a fully accredited ICANN domain name registrar. In addition to great pricing and service, we offer SSL certificates, web hosting, premium and expired domains. Most importantly, we've been giving a $#*! since 2003!"
I still don't think it comes off well but, in that context, I guess it's not as bad as I originally thought. And that's probably why they put it in quotes in the message. It makes more sense now.
Thank you!
This commentary though, it is unnecessary. They are making an attempt of remain open and communicate with their customers. Responses like these aren't going to aid further such attempts of similar observers. Others are going continue as many still do: skating by with such breaches unreported. Your data will be out there and you won't have a clue. Would that be better?
This very view has been much of what is wrong with HN these days. Comments with this air of pseudo-intellectual, overly-critical analysis over the inherent nature of intentions (and word use).
Honestly, I would feel much more comfortable if sites publicly disclosed their password encryption strategy. Just saying "oh they're hashed" really doesn't make me feel any better -- how do I know they didn't just do a quick MD5 instead of a proper password-appropriate process?
Funny you should mention that.
I thought at one point that I could set up a http://tosdr.org/ like database, showcasing the best password securities in use. You could have lists of the people using MD5, scrypt, bcrypt, and so forth. Think of it as a trophy case of password storage algorithms. My sticking point was finding the information, aside from looking at already leaked databases, you just have to go and ask the developers.
I emailed about 35 companies with a standard block of text asking if they were willing to disclose their scheme, the responses were mostly in the following:
• "our passwords are encrypted, you don't need to worry"
• "we can't disclose this for security reasons"
• "you're trying to hack us!"
I don't know what I expected really. We will have to stick to laughing at the atrocities listed on on http://plaintextoffenders.com/ .
This sounds like the beginning of a pretty good blog.
And, from a security perspective, it's mostly irrelevant as to whether passwords were hashed (where hash = MD5, SHA, or some other high speed hash function), or salted+hashed.
Why:
Look at two scenarios,
Scenario #1: The security of your Strong, high-entropy password.
Scenario #2: The security of all the n00b's weak passwords.
Option #1: Hashed, no Salt
Option #2: Hashed + Salt.
In Scenario #2 - the vast majority (60%+) of those weak passwords can be brute forced with sophisticated dictionary attacks in a couple days even with a hash+salt - no need to use rainbow tables.
Ironically, Salt's offer no security for you (you don't need them), or the vast majority of people (whose password will be broken, even if they are salted+hashed). Salts+Hash were relevant from 1990-2010, prior to high speed GPUs and ASICs overtaking Rainbow Tables. People learned lessons then, that are no longer relevant.
Now, where Salts ARE important, is with a multi-iteration key-derivative function like bcrypt or scrypt. There, a salt (which is part of the bcrypt and scrypt algorithm) actually does offer (a lot) of security to the n00bs. Without salts scrypt/bcrypt would once again tip the balance back in favor of Rainbow Tables. But, of course, scrypt/bcrypt are inherently salted.
But your high-entropy password is safe regardless.
As always, http://codahale.com/how-to-safely-store-a-password/
http://www.name.com/blog/general/2013/05/we-got-hacked/#comm...
In an ideal world we wouldn't use passwords anymore. But right now we have no choice so we have to do whatever we can to mitigate our eventual compromised accounts.
That really doesn't make that much of a difference anymore, given the fact that it's known information that's easily parseable. Rainbow tables are really just a quick convenience, but it's not like there aren't programs that can automate the process of getting and appending the salt to a password string and then just brute forcing. Even with something like bcrypt, you're still working against 1) infinite time and 2) users who don't understand how dangerous a weak password is.
I'm not sure if this answered much.
Why would they be using RSA to encrypt fields in an internal database, rather than a symmetric algorithm?
If they really did use RSA, I'd wager they did not pad it correctly and don't have any authentication.
The web server can write the credit card info to the database, but isn't able to read (and decrypt) that same info in case it gets hacked.
Presumably there is another machine that only does billing and has a much smaller attack surface, which is the only online place with the key to decrypt the card info.
That was strictly for performance overhead and key rotation flexibility. Perhaps name.com didn't care about that.
"Name.com recently discovered a security breach where customer account information including usernames, email addresses, and encrypted passwords and encrypted credit card account information may have been accessed by unauthorized individuals. It appears that the security breach was motivated by an attempt to gain information on a single, large commercial account at Name.com.
Name.com stores your credit card information using strong encryption and the private keys required to access that information are stored physically in a separate remote location that was not compromised. Therefore, we don't believe that your credit card information was accessed in a usable format. Additionally, your EPP codes (required for domain transfers) were unaffected as they are also stored separately. We have no evidence to suggest that your data has been used for fraudulent activities.
As a response to these developments, and as a precautionary measure, we are requiring that all customers reset their passwords before logging in. If you use your previous Name.com password in other online systems, we also strongly recommend that you change your password in each of those systems as well."
Based on their suggestion to change your passwords on other online services using the the same password one could assume that there is a good chance they could be decrypted. On the other hand they could just be overly cautious. In any case I agree it would be nice if they could divulge more information on the encryption strategies in use.
Nothing to see here.
I only mention it because there's an important difference in that with hashing, it doesn't really matter as much what the strategy is, since a bad password is a bad password. Better hashing only means a lower percentage of your intermediately-secure passwords are compromised right away. Since they (should) have no way of knowing which passwords are secure, they have to treat them all as compromised even if they were storing them "right".
LOL
After the hackers clued them in!
Why else would they release this on a Friday?
I haven't heard anything from Moniker. My trust for them has be waning for a while, and radio silence on this doesn't help -- though I haven't attempted to reach out to their support at all either.
Also, if you just wrap your current hashing scheme, you don't even have to bug your users to update their passwords. https://gist.github.com/cagerton/5485241
"Hypothetically, what would happen if some bad guys managed to transfer domains? What recourse would there be: would it be dealt with by yourselves, or would the previous owners of the domains have to take legal action against whoever the domains were transfered to?"
There is a procedure in place between registrars to cover situations like this. Of course this assumes that the person who has the name stolen knows it has happened and that the proper people are notified fairly quickly. There are many cases where people might not know a domain was stolen (extra domain pointing to another site for example or an unused name) so there is definitely a risk here. But assuming this was discovered right away by the person whos name was taken it could be reversed and transferred back to the losing registrar. Of course all this can be time consuming and there is no guarantee that the registrar that the name was transferred to would act quickly etc. YMMV.
I'm glad a despicable company got hacked, but I do feel empathy for their customers--both because of the hack and because they have a malicious registrar.
This language, however, is awesome.