Ah, yes. That was it. Thank you for jogging my memory. I had almost forgotten. I guess if people have been asking for something for EIGHT years and no changes have been made, then I guess I sort of put it aside in my memory to just wait until Anonymous drops by for the lulz…
For those who need some reminding, I’ve been keeping a set of security-related tips gleaned from these here discussions. One that might come in handy at this time, and perhaps for the next few days, is:
last -i | grep $(echo $USER | cut -c -8)
last -if /var/log/wtmp.1 | grep $(echo $USER | cut -c -8)
which will show the IP addresses used to log into your account over the past month or two. You’ll need to either log in as each user and run it or replace $USER with other users.
It’s also interesting to note the small privacy glitch inherent in that information. If you have the extra web panel security turned on so that only certain IPs can log in, you can get the IPs used by others on your machine if you know their usernames. It’s not hard to find their usernames either. Anyway, someone smarter than I may be able to spoof some of those IP addresses for nefarious purposes. I don’t really know, actually. I’ve just become more paranoid about security the more I read up on it.
Hi. I’m becoming a little uneasy about the direction of Dreamhost. In comment on the Dreamhost blog today, the CEO says, “And we’re investigating further measures to ensure security of passwords including when a customer requests their password by email (this was not the issue here, though).”
The CEO does not convincingly convey his awareness of the fact that Dreamhost allows person X to request that customer Y’s password to be emailed to customer Y
(where X does not necessarily equal Y).
If X has a way of intercepting Y’s email, then there is a problem. I have not yet seen any statement from Dreamhost which acknowledges this.
Sure, it shows all, but it’s a lot of crap to look through if you are just looking for your own. But if you want to see who else is on your machine, it’s interesting. you can just do:
to see all your friends.
Sorry, I’m not sure about SFTP. I only use SSH and am on a shared server, so the location of the log files may be different for you. I would assume, though, that SFTP would produce the same log entries as it’s essentially FTP over SSH.[hr]
You can check your ~/.ssh/authorized_keys file to make sure no one has logged into your account and added their key. I was actually completely unaware of all the ruckus despite making many code updates to one of my sites over the past few days because I only use passwordless authentication. The bad part of that system, though, is the same as authenticated cookies. Should an adversary add their key or get an authenticated cookie, changing passwords won’t keep them out.
Another thing I do is a daily cronjob that emails a list of all files modified in the last 48 hours along with scanning the logs for 404 codes and sending the list of requests. Sometimes they are innocent, but often it’s a script looking for exploits. I occasionally add the request patterns to a blacklist even though they result in 404.
You can also ask Support to disable access to your databases via myPhpAdmin and access to your account via webFTP/AjaXplorer. They are not safe and there’s no reason to use them, but they are enabled by default on all domains.
Enabling an IP-based whitelist to your web panel account is also good practice.
I could go on and on as I’ve been working on this for a while now. You can see part of my notes here. Eventually I’ll add it all to the wiki.
I like the part where he wrote [quote]We’ve already implemented changes to prevent any similar attempted hacks, and we’re performing a rigorous security review including a detailed review of customer input on potential vulnerabilities.[/quote]
Um, a detailed review of customer input on potential vulnerabilities? Dude, check your little suggest-a-feature-thingie in the panel and you’ll notice that customers have been asking for non-recoverable passwords for eight years.
This is from the same company that still has the following statement at the top of their Contact Support section:
despite the fact that Support will tell you that it hasn’t worked for a long time. What’s up with that? It’s new, but it hasn’t worked for a long time? Then take it down.
I just extended my hosting plan by 5 years, despite some of my misgivings and concerns, because overall it seems like DH is still better than most others around the same price point. But come on, DH. You are supposedly pushing out updates to the panel weekly, so hide that announcement already. And the conueries which apparently don’t matter as much as long query times.
There are a lot of good things about DH, but some of the bad things are so blatantly and frustratingly bad… As I said, I’ve had a good enough experience to commit to 5 more years, but it would be nice to see some progress on those bad spots…
I’ve started work on a wiki page to share tips here. That’s all the time I have right now, but it’s a start. Perhaps others could contribute tips as well? I’ve only covered a daily cronjob, but it would be useful to add .bash_profile additions as well.
Just FYI, I got a very clear reply from Support regarding the little password issue that has come up recently. For the record, I’ve been a customer for about 3 years, so if you have been a customer for less than that, you, and your passwords, are probably safe:
I would like to know
whether any of my passwords were in the unencrypted database that was recently breached
if so, which of my users was affected?
if not, were encrypted passwords of any of my users also accessed?
if so, what level of encryption was used to protect my passwords
I also note that there have been requests for the past EIGHT years to stop storing passwords in a recoverable format. Could you tell me when you will start storing them securely in one-way hashes?
The databases that may have been accessed was an extremely old legacy database which we have now removed. None of your information was present on that database. Your passwords are stored in a hash format that cannot be reversed on the servers. We do keep a symmetrically encrypted version of the password on a very secure location as well. This is only used to help increase the efficiently of support and would not be reversible without knowledge of our algorithms.
If you do not want this version stored you can simply change your password from the shell with the passwd command. The the only record of your password will be in the hash file on the server.[/quote]
So, assuming that DH is not just using MD5 or even sha1 without salt, even if my passwords were leaked, there should be a good amount of time before they can be cracked. Still, within the next six months or so, it wouldn’t hurt to consider your own personal password management system and perhaps upgrade. For example, adding your own salt to passwords improves their strength while not adding much burden to your memory. You can add something as simple as [font=Courier]1234567890[/font] to the beginning or end of each of your passwords and you’ll be doing much better than you are now.
Note to powerusers, or whatever the PC term is these days for people who actually know the difference between a hash and encryption, make all of your password changes in the shell to avoid the possibility of them being stored in cleartext.
If you’re on shared hosting, and you’re just going to copy and paste that command in from your notes file, you might want to use full paths for those commands, especially since those commands are recommended on a DreamHost wiki page. If someone knew you were on a DreamHost-hosted site, and that you’d use those commands to see if you’d been hacked, they could trivially drop an alias for them into your .bash_profile, and you might never know it. Something simple like “alias last=‘last -i | grep -v hacker-ip-address’” or more complex like “alias last=~/.hidden_trojan” would keep you from seeing their tracks or potentially undo any of the fixes you’ve already made.
So you might want to save in your note file, instead:
Good point. Thanks for the tip. I run a daily cron job which emails me a list of files modified in the past 48 hours which I monitor fairly closely (i.e. a change to my .bash_profile would stand out), but it’s better to have multiple layers of defence.