Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hetzner Servers Compromised

wiki.hetzner.de

Post reply on HN
Print view View original

121–130 of 133 posts

Re: Hetzner Servers Compromised

#121

Post by bashinator »

darkarmani wrote: post #54
gommm wrote: post #9

Earlier quoted context omitted.

Just got the email too. I'm quite happy with how clear they are about what happened and how they hash their passwords. Very different from Linode. I just wish that they used bcrypt instead of a salted SHA256 but at least it's salted (and anyway in my case I never reuse passwords so no big deal).

> I just wish that they used bcrypt instead of a salted SHA256 but at least it's salted (and anyway in my case I never reuse passwords so no big deal). If they fall under PCI:DSS, they might not be able to use bcrypt since it isn't an official recommended standard. (I am of course assuming that they mean PBKDF2 when they say salted SHA256.)

Could you double hash passwords? First with bcrypt for actual security, and then a second time with SHA256 as a bureaucratic measure?

Re: Hetzner Servers Compromised

#122

Post by sbalea »

warrenm wrote: post #86
925dk wrote: post #69

Earlier quoted context omitted.

Yes seriously, here is what they asked me on first order with them: "Since you're a new customer with Hetzner, we ask you for a scan of your passport or ID card (authenticity check). It's only necessary for your first order with us. Please send the scan by fax or as an email attachment." When they say they delete it after 21 days, as they did in the mail I've just received, I trust them. I find their communication on…

not true for all customers - I needed to send them nothing of the kind (in the US)

I did need to send them scans of ID documents and I am in the US.

Re: Hetzner Servers Compromised

#123

Post by FooBarWidget »

e12e wrote: post #119
FooBarWidget wrote: post #11

Sigh, another hosting provider hack. As if Linode and OVH are not enough. This is the reason why we use full disk encryption, where we enter the key manually during boot. This way we're protected against many types of hosting provider hacks.

Well, maybe. Do you have servers with a secure boot environment? Also, if the attackers are able to attack your servers in a similar fashion (gaining access without reboot) -- they have full access to the already decrypted disks (well virtual devices). As for other comments on automating booting -- as eg cryptsetup allows entering the encryption key via ssh -- automating that shouldn't be too hard. I still think that…

Even without secure boot environment, if you're paranoid enough you can throw away and reconstruct the boot environment on every unplanned boot.

Encrypted disks are not meant to protect against attackers that can gain access to the server without rebooting. But all your OS-level security mechanisms (user separation, AppArmor, file permissions, firewalls) become useless if the hosting provider's admin interface has an exploit and the attacker can reboot the machine into single user mode. In other words, the Linode scenario. That's what encrypted disks protect against.

Re: Hetzner Servers Compromised

#124

Post by gizzlon »

FooBarWidget wrote: post #94
raylu wrote: post #83

Earlier quoted context omitted.

Wait, this sounds way harder than the previous solution and entering the password over a remote IPMI console.

It's harder to set up. But when the password entering automation system exists, you just grab the key, go to that system, unlock & boot it, then tell it to enter the passwords for your 1000 servers.

With that many servers you probably have to reboot a few of them pretty often.. You'd have to live in the datacentre :)

Re: Hetzner Servers Compromised

#125

Post by gizzlon »

ahi wrote: post #95
saturdayplace wrote: post #85

Earlier quoted context omitted.

Is it just the customer account details that apparently make hosting companies attractive targets. If that's the case, I'm wondering why we're not seeing more breaches from all over the e-commerce world. Why just hosting companies?

Maybe the hosting companies are simply more likely to detect a breach. Not a happy thought I know.

And more likely to disclose it perhaps?

There are a lot of breaches that you will never hear about because they go undetected or undisclosed.

Re: Hetzner Servers Compromised

#126

Post by 1SaltwaterC »

MrCheese wrote: post #35
tbh wrote: post #33

Earlier quoted context omitted.

Of course not, but regardless of who in the company said it, the official support response was as quoted. Not exactly encouraging!

To be fair, Hetzner has very "google translaty" English support for simple matters, so it is not impossible that they simply didn't understand the question

Kinda reminds me of http://www.youtube.com/watch?v=gmOTpIVxji8

Re: Hetzner Servers Compromised

#127

Post by dspillett »

Gravityloss wrote: post #103
samspenc wrote: post #52

Earlier quoted context omitted.

They're really inexpensive, which explains their niche popularity...

They're very big, not just a niche. Also reliability / support is not necessarily always so much worse than some higher price solutions.

Aye, they seem to have a very good reputation for a cheaper provider. I've not used their services myself though.

Re: Hetzner Servers Compromised

#129

Post by andyhmltn »

Dylan16807 wrote: post #120
e12e wrote: post #118

Earlier quoted context omitted.

They might be stolen.

Okay, but stealing a backup gets you 21 days of those documents, the same amount you can get from the live system. There is no need to worry about backups in particular.

Correct me if I'm wrong, but if you had a backup from 15 days ago, wouldn't that backup contain documents 21 days prior to it? So in effect: up to 36

Re: Hetzner Servers Compromised

#130

Post by e12e »

FooBarWidget wrote: post #123
e12e wrote: post #119

Earlier quoted context omitted.

Well, maybe. Do you have servers with a secure boot environment? Also, if the attackers are able to attack your servers in a similar fashion (gaining access without reboot) -- they have full access to the already decrypted disks (well virtual devices). As for other comments on automating booting -- as eg cryptsetup allows entering the encryption key via ssh -- automating that shouldn't be too hard. I still think that…

Even without secure boot environment, if you're paranoid enough you can throw away and reconstruct the boot environment on every unplanned boot. Encrypted disks are not meant to protect against attackers that can gain access to the server without rebooting. But all your OS-level security mechanisms (user separation, AppArmor, file permissions, firewalls) become useless if the hosting provider's admin interface has an…

My point was that getting back to a known good boot scenario isn't all that easy if you don't have physical access?

I suppose the sanest middle ground is to wait for the dust of an event like this to settle (or have someone investigate, in case of "just" an unexpected reboot) -- then wipe the server(s) in question, reinstall (hoping the install media is ok) -- and importing the disks/backup.

I still think it is little gain for a lot of work.

Basically if your server software is secure, you've avoided data compromise due to a reboot into single user mode or similar -- but you have to assume (for the sake of guaranteeing the safety of the encrypted data) -- that attackers have a copy of the data at rest (which they can get if the can boot into a recovery image etc.

So now you have to make sure that you can boot a safe environment in which to import the data to, without leaking your key(s).

All the while, it is rather likely there are a few vulnerabilities in your software stack that all this never did mitigate.

I'm not saying don't do it -- I'm in favour of doing it for the (relative) peace of mind that no that will get lost/out as the servers are recycled -- I'm not sure it makes much sense to avoid hackers -- the online threat seems to dominate for most cases I can think of.

Post reply on HN