Hacker News Reader

Comment by edmond_dantes | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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

"If your password is hashed, which it usually should be, then the service would not be able to give it to you."

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

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

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.

Reply on news.ycombinator.com