Hacker News Reader

Comment by regularfry | Hacker News Reader

This needs repeating: there is no way for a VPS provider not to have access to the internals of your VM; it is unrealistic to have such an expectation.

It might not be unrealistic to expect them to ask before looking, but if your concern is "one bad apple" then you've already lost.

View on HN

I don't particularly care if they have access to the internals of my VM; I don't even care if they have the ability to log in to root using a specific ssh key (or a similar backdoor, so long as it's only accessible from within their network). Those things may be required for the reasons noted by the GoDaddy CSO.

I do care if someone uses my password to log in. I'm better than most folks at password security, but there's still too much opportunity provided by letting them have plaintext access to the password (I don't care if it's a decryptable format).

the important part is the difference between a compromised authentication secret and having local control over hardware/software. the password is now out in the open. there is now one more way for someone to root the slice other than getting control over the node(s) running the slice.

If they have root on your VM, they have your root password too. We're talking about maybe a couple hundred lines of code, tops.

It's clearly easier to get root passwords out of a database, but in the unlikely scenario where an internal employee sets out to sabotage the whole operation, a couple hundred lines of C code doesn't make the effort that much more unlikely.

Don't get me wrong; storing the passwords in the clear is very bad. The thing that is really going to go wrong? Someone's going to commit a change to their web app that coughs up everyone's password to an outsider.

I think there's a pretty huge difference in the risk of a bad apple writing code and inserting it into the system vs a bad apple looking up a password and logging in normally.

One requires significant sophistication and risk (of colleagues knowing your intentions are malicious), the other requires virtually no knowledge and low risk.

> If they have root on your VM, they have your root password too. We're talking about maybe a couple hundred lines of code, tops.

The default hash for crypt(3) (and thus /etc/shadow) in newer Linux distributions is salted SHA-512. Shouldn't that be significantly more difficult to crack than the old MD5 hashes? john didn't even support it when I checked a few months ago.

You don't have to crack it if you can just replace the login binary with one that logs it somewhere.

Oh, of course. I errantly assumed they didn't have root at the same time as you still had access.

In effect, No. The computing power required to crack SHA-512 is infinitesimal compared to that for, say, bcrypt. However, modern crypt() implementations support multiple rounds just like bcrypt and that would make it significantly more difficult (time-wise) to crack. But then again SHA-512 is already being replaced due to some potential flaws found, so.... shrug

Kind of pointless to crack your password, though. I mean, it's not like you use the same one for more than one account.

No of course not. I'm sure we all use a different password for every box, webapp account, registrar, email address etc. I myself keep 100 or so passwords in my head, just like everyone else...

i know right? after the 16th character in the 96-character set it gets a little tiresome to type but i think keeping my twitter account secure is worth it.

To be honest, I even don't know my remote passwords. They're completely random. I just use SSH keys.

1Password and encrypted text files serve well as a backup.

I agree with that completely. I use dsa for my boxes, but still there's so many other services I use where it isn't an option.

I guess it's ok if they have local access. For cheap, crappy hosting it might be even ok if admins had access to passwords (but if they don't know about ssh keys, what can they fix really?). It is NEVER ok if some random support person can request your password because they need it, then write it on a piece of paper and log into your host as root once they get back home. (what are you doing allowing root access via ssh anyways?)

If the filesystem is shared (i.e. server has / , and your vm1 is under /data/vm1 for example), they can access any files or databases without even logging in. If the filesystem is on a SAN they can access it read-only of course without you even knowing.

Thats true and it goes for dedicated servers and colo'd servers as well in some cases. The issue here isnt outrage about a host having access to your box, which almost all of them do anyways(IPMI, Root Disks, etc..) - but that they used his password to do it and without asking him.

I'm pondering a truecrypt'd system... unless they weed through the virtual-RAM to find the decrypting key, or they install a keylogger (likely against their end of the hosting agreement (though I haven't read any)), it'd essentially be secure against even them.

No, it wouldn't. The guest kernel has unencrypted access to the filesystem (it has to if you want to get anything in or out), and that's just a process running on their host. I'm reliably informed that getting the FS contents under those circumstances is relatively trivial.

Reply on news.ycombinator.com