Name.com Tells Customers To Change Password Due To Breach(thedomains.com)
thedomains.com
Name.com Tells Customers To Change Password Due To Breach
http://www.thedomains.com/2013/05/08/name-com-tells-customers-to-change-password-due-to-breach/
10 comments
For anyone who wasn't following HN yesterday:
https://news.ycombinator.com/item?id=5667027
https://news.ycombinator.com/item?id=5667391
https://news.ycombinator.com/item?id=5667027
https://news.ycombinator.com/item?id=5667391
Notice they said "encrypted" passwords not (salted password hashes) passwords.
I don't trust "encrypted" password because my experience with Host Gator: I contacted Host Gator support to reset my password and they were able to send me my previous PLAINTEXT password. I asked them how this was possible and they told me that the passwords were encrypted and only a few people had access to it.
People who also have access to it: Anyone who can see the Host Gator email que and the mail-servers the email passed through.
I promptly closed my account with them.
I don't trust "encrypted" password because my experience with Host Gator: I contacted Host Gator support to reset my password and they were able to send me my previous PLAINTEXT password. I asked them how this was possible and they told me that the passwords were encrypted and only a few people had access to it.
People who also have access to it: Anyone who can see the Host Gator email que and the mail-servers the email passed through.
I promptly closed my account with them.
In my opinion, HostGator is a joke. They constantly push people to use FTP instead of SFTP.
Want to add an SSL certificate to a subdomain? You have to provide them your main account login, which is logged in plain text in their ticket system.
They also took it upon themselves to look through one of my databases because they thought it was taking up too much of my unlimited quota.
Want to add an SSL certificate to a subdomain? You have to provide them your main account login, which is logged in plain text in their ticket system.
They also took it upon themselves to look through one of my databases because they thought it was taking up too much of my unlimited quota.
I also found it interesting how vague they were in "implementing additional security measures". I would hope that they've identified and fixed the core security issue that HTP exploited, and that these extra measures aren't simply asking their customers to change their passwords.
They also only mention personal information theft, while there was also supposedly a risk of configuration changes to domains hosted there.... were they able to track any malicious changes? Or are they confident none happened? Or did they have no idea about the breach until HTP publicized it? More information would certainly help my confidence with them as a registrar.
They also only mention personal information theft, while there was also supposedly a risk of configuration changes to domains hosted there.... were they able to track any malicious changes? Or are they confident none happened? Or did they have no idea about the breach until HTP publicized it? More information would certainly help my confidence with them as a registrar.
One of the reasons we liked name.com was their multi-factor support and email on action support, but it's all an illusion if hackers can get in at this level and go undetected until they helpfully post it publicly!
Yeah, one of the main reasons I use Name.com is MFA.
I'm not happy that my domain registrar was hacked by a group that wasn't even targeting the company; it was simply the weakest link. Not good.
I'm not happy that my domain registrar was hacked by a group that wasn't even targeting the company; it was simply the weakest link. Not good.
Encrypted is not the same as hashed. An encrypted password could be secure as long as the means to decrypt the password, for example the key used to encrypt, is not leaked. Sending you passwords over email however is horrible.
If your password is hashed, which it usually should be, then the service would not be able to give it to you. The reason services sometimes instead opt to encrypt instead of hash is for support reasons. Encrypting a password could be ok, as long as they never expose the password over something like email.
If your password is hashed, which it usually should be, then the service would not be able to give it to you. The reason services sometimes instead opt to encrypt instead of hash is for support reasons. Encrypting a password could be ok, as long as they never expose the password over something like email.
"The reason services sometimes instead opt to encrypt instead of hash is for support reasons."
I've seen _very_ few good reasons for encrypting passwords instead of hashing them - and that's certainly not one of them. Sure, "support" might need access credentials to my account - but it needs to be _their_ access credentials, not mine. Sure, you can build the infrastructure required to securely manage encrypted passwords and the decryption key storage - but you can almost certainly build an alternative system where support never need _my_ password instead.
I've seen _very_ few good reasons for encrypting passwords instead of hashing them - and that's certainly not one of them. Sure, "support" might need access credentials to my account - but it needs to be _their_ access credentials, not mine. Sure, you can build the infrastructure required to securely manage encrypted passwords and the decryption key storage - but you can almost certainly build an alternative system where support never need _my_ password instead.
I read "support reasons" as needing to send the customers their passwords in case they forget it. Resets are better, sure, so it's not a good reason, but at least it's an actual reason.
Thanks for explain the difference between hashing and encrypting. I neglected to make that explicit.
However, I disagree with you when you say, "Encrypting a password could be ok," because compromises happen and the attacker could do a memory dump, check the environment variables or perhaps find a location where the password is hardcoded (config or script, yes this happens). It's a sloppy practice that we should discourage. Hashing passwords is the most basic level of security and it's been known for decades.
However, I disagree with you when you say, "Encrypting a password could be ok," because compromises happen and the attacker could do a memory dump, check the environment variables or perhaps find a location where the password is hardcoded (config or script, yes this happens). It's a sloppy practice that we should discourage. Hashing passwords is the most basic level of security and it's been known for decades.
"If your password is hashed, which it usually should be, then the service would not be able to give it to you."
Good!
Good!
name.com's passwords were (still are?) not encrypted. They're unsalted MySQL 4.1 PASSWORD() hashes.
Where did you get this information from?
I was curious what algorithm is behind the MySQL PASSWORD() method. According to the MySQL reference manual, "you should not use it in your own applications. For that purpose, consider MD5() or SHA1() instead."[1]
1: https://dev.mysql.com/doc/refman/4.1/en/encryption-functions...
I was curious what algorithm is behind the MySQL PASSWORD() method. According to the MySQL reference manual, "you should not use it in your own applications. For that purpose, consider MD5() or SHA1() instead."[1]
1: https://dev.mysql.com/doc/refman/4.1/en/encryption-functions...
https://news.ycombinator.com/item?id=5677550
Hint: I'm the head of ops, the password matched what I had set (16 characters, mix of letters, numbers and symbols, not used anywhere else).
Hint: I'm the head of ops, the password matched what I had set (16 characters, mix of letters, numbers and symbols, not used anywhere else).
Also, in addition to confirming that our own hash was genuine, 9gag's password was very weak and their hash can be reversed with online rainbow tables.
Name.com user here. This is the first time one of my registrars gets compromised and I'm not sure I understand the (potential) severity of what has happened.
What would HN suggest doing in a case like this (aside from changing passwords)? Just let it be? Monitor credit card? Change registrar?
Looking forward to your feedback.
What would HN suggest doing in a case like this (aside from changing passwords)? Just let it be? Monitor credit card? Change registrar?
Looking forward to your feedback.
Make sure your domains are pointing to the nameservers you originally specified.
I will, thank you.
I try not use credit card online while other choices are given. Name.com only has my paypal account name (if they save this kind of information).
However I still changed my credit card since it was in the Linode database.
I considered changing registrar. But I really can't know to which one I can go. How do you know they won't be (or already are) compromised?
However I still changed my credit card since it was in the Linode database.
I considered changing registrar. But I really can't know to which one I can go. How do you know they won't be (or already are) compromised?
At least in the US, having your card number stolen is such a small deal that it hardly seems worth worrying about. Just keep an eye on your statement, which you should really be doing anyway. You don't have to pay for charges you didn't authorize. In my experience, the card issuer typically detects the fraud automatically.
Very true. Perhaps I should try getting into the habit of using PayPal instead of credit cards.
[deleted]
The article implies this is the first time they've notified customers, so they've either been unaware (seems unlikely since the FBI had a mole in HTP, who have claimed responsibility) or just not disclosing it? Is that true? I can understand why people are annoyed at Linode and everything, but this seems ridiculous if it's the first time.
It looks like they may have used RSA encryption with a 4096 bit key [1] and as far as I know, if the private key is not compromised; this is pretty darn secure...Can anyone confirm?
[1] - https://twitter.com/namedotcom/status/332260201535266816
[1] - https://twitter.com/namedotcom/status/332260201535266816
HNer kouiskas suggests it is a weak, unsalted hash. https://news.ycombinator.com/item?id=5677550
That seems to be for the password, right? Credit cards should be encrypted with a much stronger algorithm (hence the reference to the private keys).
Oh, I guess so. I'd be much more concerned about my password than my credit card.
Thanks for the heads up, I did not notice that.
Well, that confirms at least part of the Linode story.
What exactly wasn't believable about it before? Linode confirmed that someone cracked into their system on their blog, which I consider as being confirmation enough for everything.
Linode confirmed they were cracked, but the HTP write-up in https://news.ycombinator.com/item?id=5667027 included a lot of additional details, much of it hard to confirm.
FBI moles, compromise of a fairly large registrar, etc.
FBI moles, compromise of a fairly large registrar, etc.
The name.com sample data HTP showed in their log by querying the database was real. Source: I work for one of the companies they used as sample rows when querying the name.com DB. Our head of ops confirmed that the hash in the HTP log was indeed the MySQL 4.1 PASSWORD() unsalted hash of our password at the time. name.com is kind of generous with the term "encrypted" in their email.
I guess I just didn't see a reason for HTP to lie about it, especially with several smaller pieces out there confirming large portions of it.
I suppose I don't understand why it's necessary to know if HTP was being 100% honest when the big details have been confirmed.
I suppose I don't understand why it's necessary to know if HTP was being 100% honest when the big details have been confirmed.
This is the first confirmation I've seen of Name.com being hacked. That's a fairly significant sticking point, particularly as the known attack vector on Linode was a ColdFusion exploit, not a complete takeover of their registrar...
Oddly enough, as a name.com customer I kind of surprised that I found this out through HN first.
I haven't get an email yet either (wasn't in my spam folder and the whois details are correct). I hope that's not a sign of bigger issues.
[deleted]
That's strange, I did receive their email (at 1:45PM EST to be exact). Did you check your SPAM folder?
Ditto. I still have yet to receive the email. Checked spam to no avail.
I just received their email (5:35pm EST)
I received my email 90 minutes ago
Received mine early this morning.
Name.com seems to be on the same path Go Daddy was 8 years ago (sans scantily clad women for marketing).
I wouldn't appreciate the "humor" (Twitter) around this event if I were a customer. My only hope is that if anything like this happens to Gandi that they handle it with, true to style, no-bullshit transparency - spare the crap.
I wouldn't appreciate the "humor" (Twitter) around this event if I were a customer. My only hope is that if anything like this happens to Gandi that they handle it with, true to style, no-bullshit transparency - spare the crap.
I made an account on name.com 5 days ago. Anybody know when the breach happened?
It was back in April, in association with an attack on Linode [1]. See this HN comment by RoboTeddy from yesterday for a great summary of the group's story about these attacks [2].
However, Name.com has not disclosed much information. I don't know if they were aware of the attack until the group released their story yesterday. The systems could have still been compromised.
[1] https://blog.linode.com/2013/04/16/security-incident-update/
[2] https://news.ycombinator.com/item?id=5667391
However, Name.com has not disclosed much information. I don't know if they were aware of the attack until the group released their story yesterday. The systems could have still been compromised.
[1] https://blog.linode.com/2013/04/16/security-incident-update/
[2] https://news.ycombinator.com/item?id=5667391
"@HackThePlanet Can you just send a postcard next time?" https://twitter.com/namedotcom/status/332304801050271744
"@xDictate Yes. It's been a huge pain in the ass, yet it's hard not to appreciate great technical savvy." https://twitter.com/namedotcom/status/332308994255384577
Regarding elephants: "@BobSnooks Even though it feels like we're getting trampled by them, we still won't shoot." https://twitter.com/namedotcom/status/332232278078001153
Hopefully this is an indication they'll be willing to release full details of the incident. In contrast, Linode seems to take their image way too seriously and refuses to say anything that might make them look bad. (Of course, not saying anything makes them look worse, but they don't seem to realize that.)