

We got hacked - subsection1h
http://www.name.com/blog/general/2013/05/we-got-hacked/

======
MichaelApproved
_“give a shit”_

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._

~~~
X-Istence
It's their tagline:

"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!"

~~~
MichaelApproved
Holy shit, you're right! I thought this was a joke at first. Even after
jonmrodriguez confirmed it, I thought he was continuing the joke but it's
true. They actually say:

"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!

------
MichaelGG
This is a registrar that, if you use their DNS service, refuses to return not
found records and instead serves up ads, on your domain. That's cheesy thing
to do. I had started to move some domains to them from GoDaddy, found out
about it, contacted them to see if they can remove it, and was told off.

~~~
staunch
Breaking DNS for profit is enough reason not to use them.

------
carlsednaoui
"The information that was accessed includes usernames, passwords, physical
addresses, email, hashed passwords..." They mention passwords AND hashed
passwords, I wonder if this means they had some passwords saved in the clear.

~~~
aroman
And also whether "hashed" means salted and hashed or just simply hashed.

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?

~~~
nwh
> Honestly, I would feel much more comfortable if sites publicly disclosed
> their password encryption strategy.

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/> .

~~~
DanBC
> "you're trying to hack us!"

This sounds like the beginning of a pretty good blog.

------
GigabyteCoin
Name.com: Why did it take you over a month to report the fact that you were
hacked to your users if you "give a shit" about us?

~~~
err_badprocrast
I think they only realized it happened after name.com was mentioned as a
hacked site in HTP5.

<http://www.exploit-db.com/papers/25306/>

~~~
highace
Or they only chose to do something about it once it was public domain.

~~~
rubbingalcohol
So they're either incompetent or really shady. At least they're handling it as
well as Linode did.

~~~
deminature
It says in the HTP5 release that Linode was placed in an intolerably
difficulty situation between the HTP group and the FBI and were not in a
position to make a public statement until they were directly instructed to by
the FBI.

------
sweis
"For the techies who are wondering, the encryption on the credit card
information is 4096 bit RSA."

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.

~~~
tbrownaw
It's a Write-Only Memory.

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.

~~~
sweis
I've seen web frontends that encrypt submitted credit card info with a public
key, then had billing backends that re-encrypted with a symmetric key (usually
in a HSM).

That was strictly for performance overhead and key rotation flexibility.
Perhaps name.com didn't care about that.

------
gmanley
Here is an excerpt from the email I received from them:

 _"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.

~~~
Cushman
Passwords aren't (usually) encrypted, they're hashed. Hashing buys you time,
nothing more; if an attacker has a copy of your hash you should treat your
password as compromised.

Nothing to see here.

~~~
gmanley
Hashed was indeed what I meant. I tend to use the words interchangeably, in
error. What I meant to say is the strategies in use can vary quite a bit. Are
they using a salt and/or a pepper? Are they using bcrypt or the like? Based on
those answers one can usually guess if its feasible to break those in a
reasonable amount of time.

~~~
Cushman
Sorry, reading that again I sound like a dick. I know it's a common error and
I didn't mean to nitpick.

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".

------
cmstoken
Here's the cache:
[http://webcache.googleusercontent.com/search?q=cache%3Awww.n...](http://webcache.googleusercontent.com/search?q=cache%3Awww.name.com%2Fblog%2Fgeneral%2F2013%2F05%2Fwe-
got-hacked%2F&aq=f&oq=cache%3Awww.name.com%2Fblog%2Fgeneral%2F2013%2F05%2Fwe-
got-hacked%2F&aqs=chrome.0.57j58.971j0&sourceid=chrome&ie=UTF-8)

------
Spearchucker
I'd like very much to know _how_ they got hacked. All the talk of 4096 bit RSA
and security is great, but how did the database get compromised?

------
kevcampb
They've clearly omitted the line “the private key was stored securely on a
separate system which was not compromised” after the statement about card data
and RSA. I'd go as far as to suggest that was deliberate.

------
agj
Has anyone heard anything from Moniker, or the other registrars claimed to be
hacked? I wasn't able to fetch the registrar data from the zine release, and
haven't found another source, though it had sounded like HTP obtained root or
privileged access on Moniker.

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.

~~~
josephlord
Don't know about Moniker but Melbourne IT admitted to some breach (although
play it down):
[http://www.theregister.co.uk/2013/05/09/melbourne_it_hacking...](http://www.theregister.co.uk/2013/05/09/melbourne_it_hacking/)

------
lm741
This seems like a good time to remind everyone how easy it is to upgrade to
scrypt.

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>

~~~
pyre
What does scrypt offer over bcrypt? The only difference I seem to recall is
that scrypt is more memory-intensive (making it so that the CPU/GPU/whatever
isn't the only bottleneck).

~~~
tptacek
scrypt is designed to be difficult on hardware. Both bcrypt and scrypt are
currently difficult on GPU hardware, but it's unlikely to remain that way.
Both are better than PBKDF2. scrypt is likely to be better longer. But really:
throw a dart at any of the three of them.

~~~
jplewicke
It sounds like one of the Bitcoin alternatives is scrypt based, and they are
putatively getting a roughly 10x speedup from GPUs:
<https://en.bitcoin.it/wiki/Litecoin#Scrypt_Proof_of_Work> . Is that a new
development, or is it in the neighborhood of how GPU-resistant it was supposed
to be?

~~~
JoachimSchipper
The Litecoin guys just set the "make GPUs suck" (aka "memory use") parameter
too low.

~~~
jplewicke
Thanks!

------
larrys
Someone asked this question on the post so I will answer it I run a registrar
(but not name.com obv.).

"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.

~~~
duskwuff
Also worth noting that there's a mandatory 60-day waiting period between
transfers for a domain, so a stolen domain can't be taken very far.

~~~
aidos
That's only after its first registered, no?

~~~
larrys
No it's also when transferred between registrars.

------
pentarim
3 days after HTP supposedly hacked linode (and name.com in the process),
name.com suddenly "give a shit" and did "an effort to maintain the open,
honest, and transparent reputation". I do wonder if this would be made public
at all without HTP announcement made.

------
pi18n
Name.com isn't opposed to doing a little hacking of their own, on the DNS
responses.

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.

------
huhtenberg
This reads like something written by a marketing/PR team. Not just OK'd by
them, but actually _authored_.

------
clemc
HackerNews effect - got hacked + servers down with the traffic?

------
L0j1k
"the encryption on the credit card information is 4096 bit RSA."

This language, however, is awesome.

