Hetzner client data exposed after attack

[stevenv]

I want to know why they are storing personal data of a "previous Hetzner customer with an inactive account" ... that is the email that I got. Cancelled about 10 years ago, surely they can't be allowed to store personal data that long?

 

[quovadis]

I want to know why they are storing personal data of a "previous Hetzner customer with an inactive account" ... that is the email that I got. Cancelled about 10 years ago, surely they can't be allowed to store personal data that long?

I'm pretty sure there is no local law (currently enacted) to prevent it.

 

[quovadis]

A properly implemented API mitigates sql injection and of course direct attacks on the database server if you keep your DB server off the public web. There's also less chance of data leaks through app and platform exploits.

https://www.owasp.org/index.php/Top_10-2017_A1-Injection

The OWASP top 10 is an excellent starting point for self analysis.
https://www.owasp.org/index.php/Top_10-2017_Top_10

If a database server is public facing - that imo would be negligent. There is no less chance of a data leak through an API or any other means if it's implemented poorly - I've seen API's where SQL injection was still possible. Furthermore, based on previous posts for argument of the encryption of data within the DB, it would not be further mitigated by usage of an API either.

 

[Tinuva]

I'm not advocating for a non-holistic approach. You can have a completely unencrypted database and still have a secure solution if implemented and secured correctly and it's not "leaving the door open".

My statement for "You cannot encrypt everything" as I stated, is because:

1) You reduce the ability for a database to be queried in an efficient manner.
2) You cannot dictate to your software provider (whether its an accounting system, marketing system or admin system) that they should encrypt your data when and how you see fit.
3) The benefit of doing so is technically worthless if exposed at any other level which has been exploited.

Random question.

Lets say this attack was done with SQL injection (I know its 2018 but it happens).
If the data was encrypted in the DB, would this SQL injection attack be able to get the data? Possibly yes in encrypted format. So not as useful as would be the case if not encrypted?

IMHO, always worth encrypting at every level, because you can never know how the attack will take place. If they do get in, at least make it as much work as possible for the hackers to read the data.

 

[quovadis]

Ok, I'm going to assume you're not going to edit this post again and reply.

Security is not an absolute thing, it's relative. You cannot have a more secure system with a database that's unencrypted at rest than a system with a database that is encrypted at rest. Same goes for data in transit.

You have to take the entire environment into account. An encrypted DB is more secure than an encrypted DB in isolation but not anymore effective in securing your data depending on the vector.

Sure, which is why you encrypt sensitive information. It's a trade off. POPI is going to catch a bunch of people with their pants down... LOTS.

It's not a trade off its basic functionality. Like being able to search by partial surname or other field? And if you're bulk-loading all data and decrypting before parsing a condition it may not be possible if you've got millions of records.

You can chose a different product and you can do perform due dilligence checks on the product / provider before you pick them. Or you can include proper security in requirements when getting a third party to develop a bespoke solution.

Yes, because companies choose bespoke solutions over SAP and Sage and other large software providers all the time.

There are many threats, encryption of sensitive data is a must for anyone taking security seriously.

An encrypted DB is more secure than an encrypted DB in isolation but not anymore effective in securing your data depending on the vector.

An unencrypted DB is a significant attack vector.

No it's not a vector of attack. The DB is the vector or the Endpoint accessing the DB is the vector.

 

[quovadis]

Wot, you think people shouldn't update / edit their posts? What planet?[/QUOTE
Missed my point again. It doesn't help with discourse if I have to reread your posts because you edited them 30 minutes later.

 

[quovadis]

Then you clearly just don't understand the technology or the threat.
https://www.owasp.org/index.php/Top_10-2017_Top_10
It's #1 on the list for a reason. Encryption of data at applies mostly to #3, not #1.

Ok I don't think you grasp the concepts being discussed. Let me ask you two questions, what is the purpose of encrypting sensitive data and are passwords and let's say id numbers encrypted in the same way?

 

[Sapphiron]

These days I think its rare for a prominent online company not to have had a breach.

The difference between the bad, the mediocre and the good is as follows:
1. The Bad never tell you, or never know themselves
2. The Mediocre have lots of data exposed and need to let the entire public know (like Hetzner)
3. The Good have breaches that expose very little data, and contact the affected clients, without having the make a public announcement

 

[quovadis]

Passwords should not be stored, encrypted or otherwise, why would you even ask that.

Based on your answer no point engaging further.

 

[quovadis]

Random question.

Lets say this attack was done with SQL injection (I know its 2018 but it happens).
If the data was encrypted in the DB, would this SQL injection attack be able to get the data? Possibly yes in encrypted format. So not as useful as would be the case if not encrypted?

IMHO, always worth encrypting at every level, because you can never know how the attack will take place. If they do get in, at least make it as much work as possible for the hackers to read the data.

It would depend on the way the data was being decrypted. Lets say you did a SQL injection concatenating all fields in one table into another field and then the front end ran a decryption function before displaying the data it would still decrypt the data.

Encrypting helps if someone gains DB access directly either by an unencrypted backup or via network access independently of the front end somehow knowing the credentials etc however it would severely hamper the ability to query the database. Frankly if an attacker can gain access to your database you have bigger problems than whether or not your data is encrypted.

 

[Hemi300c]

I hope they are insured.

 

[quovadis]

Hopefully that means you agree.

No.

 

[Murmaider]

I think people are missing some of quovadis points about encrypting everything in the Database.

So to give an example, lets say that name and email address should be encrypted in the database and lets say you have 100 000 records.

A customer calls in and they don't know their customer number, so they give the support agent their name or email address in order for him/her to search their system to locate the customers account.

In an unencrypted format, their software passes a query to the DB, and the results would return almost instantly because of Database Indexing.

The moment the data is encrypted, you can not search the database on those fields or even use the database indexes. The software will need to take all 100 000 rows, decrypt them 1 at a time, compare the unecrypted information in the software, build an array of matches and then return the results. This process would need to be done every single time any staff member search for a customer on their system. It is just not practical to decrypt 100 000 rows every single time you want to search for an account on their system. It would also slow down the entire system.

There is a fine line between security and convenience and the more secure you make something, the more inconvenient it becomes, both on a user level and on a system / processing level.

However I do agree that information like bank account details should be encrypted as there should not be any direct searching on these fields.

 

[Jet-Fighter7700]

will the data breached be made available to haveibeenpwned.com?

or will hertzner just mail people individually?

 

[quovadis]

Also physical theft. Not uncommon in SA. As for security at large centers, well, everything has a price - FNB proved that one . For many systems out there that's one of the easier ways - via a cloud control panel. Many spend time locking down their system but still share cloud interface passwords or has them compromised... no 2fa etc. etc.

If you've ever been in a PCI compliant DC there are measures and multiple physical layers to prevent theft. I'm not going to go into the plethora of ways to ensure that even if a server or disk or storage sub-system is stolen to protect that data.

If you're implementing any form of system using a cloud-based service and serious about what you're doing you would ensure that the endpoints within that environment are locked down and cannot be overridden by having access to the cloud control panel. Yes you could delete, stop, start, modify the container/vm but not gain access to the data.

 

[quovadis]

Well then explaining your point of view shouldn't be difficult.
I stand 100% by what I said. Passwords are never stored, encrypted or otherwise. If you feel confident arguing your POV, please do for everyone's sake? Let's not make this a kiddies playground.

I've already argued my point - it's clear as day above. You're not understanding it. Re-read my question about passwords. You misunderstood it completely.

 

[Praemon]

The moment the data is encrypted, you can not search the database on those fields or even use the database indexes.

True, but very sensitive data like ID Numbers should always be encrypted regardless. There shouldn't be a need to search partial ID Numbers, which means if you use an encryption that results in the same output each time (less secure, but better than nothing), you can then index that column and perform full match queries by encrypting the search param before querying the DB. It will be slower, but the data will be encrypted and you won't lose the ability to do full match searches (and you don't have to run through each row and decrypt the column to test).

 

[quovadis]

Certificate based transparent encryption is a great option for this scenario. Just make sure you don't store the certificate on the same system.

You have clearly very limited understanding about this. Are you talking about symmetric encryption of the database itself or encryption of the transport between the server and client? The data eventually gets decrypted at the endpoint anyway?

 

[quovadis]

True, but very sensitive data like ID Numbers should always be encrypted regardless. There shouldn't be a need to search partial ID Numbers, which means if you use an encryption that results in the same output each time (less secure, but better than nothing), you can then index that column and perform full match queries by encrypting the search param before querying the DB. It will be slower, but the data will be encrypted and you won't lose the ability to do full match searches (and you don't have to run through each row and decrypt the column to test).

Noone is advocating for not encrypting sensitive data where necessary - only that you don't have to encrypt everything. However, if you have access to the endpoint the purpose of encryption is technically ineffective completely.

 

[quovadis]

I'm talking about TDE using PKI. What aren't you getting?

You love your acronyms but dont actually understand what it means. TDE isn't encryption the way you're arguing it to be. It encrypts the database FILES. The data would be returned unencrypted to the client on query.

What are you going to copy/paste next?