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