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

Securing PostgreSQL [pdf]

thebuild.com

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Securing PostgreSQL [pdf]

#51

Post by tptacek »

rascul wrote: post #50
technion wrote: post #48

Earlier quoted context omitted.

You can get a good example of this by simply hitting this link and reviewing the first few hits: https://github.com/search?utf8=%E2%9C%93&q=aes+encryption I'm not going to call out any project by name, but on the first few pages, I see: - A project which implements unauthenticated CBC mode AES - A project that does not, in any way, document its mode or implementation beyond "using AES 256" - A project with - A projec…

What is wrong with mcrypt?

It's a low-level crypto library that leaves avoidance of virtually all the exploitable crypto mistakes as an exercise for the programmer.

Re: Securing PostgreSQL [pdf]

#52

Post by tptacek »

Cyph0n wrote: post #49
technion wrote: post #48

Earlier quoted context omitted.

You can get a good example of this by simply hitting this link and reviewing the first few hits: https://github.com/search?utf8=%E2%9C%93&q=aes+encryption I'm not going to call out any project by name, but on the first few pages, I see: - A project which implements unauthenticated CBC mode AES - A project that does not, in any way, document its mode or implementation beyond "using AES 256" - A project with - A projec…

I see, thank you for explaining. I'll definitely stick to the "known" libraries if I need AES.

Be a little more careful than that. Unless you're doing TLS or PGP, you essentially want to stick to NaCL/libsodium, and nothing else.

Re: Securing PostgreSQL [pdf]

#53

Post by technion »

rascul wrote: post #50
technion wrote: post #48

Earlier quoted context omitted.

You can get a good example of this by simply hitting this link and reviewing the first few hits: https://github.com/search?utf8=%E2%9C%93&q=aes+encryption I'm not going to call out any project by name, but on the first few pages, I see: - A project which implements unauthenticated CBC mode AES - A project that does not, in any way, document its mode or implementation beyond "using AES 256" - A project with - A projec…

What is wrong with mcrypt?

I started writing an answer, but this blog is more comprehensive than anything I could put together:

https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...

Problem #2 is something I've hit in multiple real-world codebases.

Re: Securing PostgreSQL [pdf]

#54

Post by Cyph0n »

tptacek wrote: post #52
Cyph0n wrote: post #49

Earlier quoted context omitted.

I see, thank you for explaining. I'll definitely stick to the "known" libraries if I need AES.

Be a little more careful than that. Unless you're doing TLS or PGP, you essentially want to stick to NaCL/libsodium, and nothing else .

I will keep that in mind, thanks!

Re: Securing PostgreSQL [pdf]

#55

Post by zie »

smkdtr wrote: post #22

One of the constraints I am working with is that a human is not necessarily in the loop all the time. What is the best way then bootstrap the encryption process?

You can use something like vault, they have "crypto as a service" https://www.vaultproject.io/docs/secrets/transit/index.html

You still have to bootstrap vault, but it's a pretty robust and easy to implement HA system.

Re: Securing PostgreSQL [pdf]

#56

Post by sandGorgon »

pjlegato wrote: post #44
sandGorgon wrote: post #11

Earlier quoted context omitted.

here's a question - other than RDS, which other PG hosting would you recommend ?

Try us! https://www.databaselabs.io/ . Professional PG hosting in Google, AWS, and DigitalOcean. Happy to discuss more details -- pjlegato at databaselabs.io.

good to know. i just checked out your website on my phone . i have to do a google login auth before i can see pricing?

i wanted to see what you offer... replication strategy, etc

EDIT: I just went to your desktop website and can see pricing. Do you do failover ? AWS RDS does failover and high availability - which makes it worth it.

If you can do high availability on digitalocean. That will be killer.

Re: Securing PostgreSQL [pdf]

#57

Post by fulafel »

rzzzt wrote: post #30
knorker wrote: post #23

The advice on FDE is misleading if not flat out wrong. It's NOT just to protect against media theft. It's also about "shit, the drive crashed. How do I destroy the data on it before throwing it in the trash?" Same with replacing a smaller drive with a bigger drive. Yes, DBAN it, but that won't take care of remapped sectors. It's easier to destroy an encryption key than it is to destroy the data.

To the point that more recent hard drives already come with hardware encryption enabled, and the secure erase/sanitize command can finish in mere seconds, because it only needs to throw away the existing key: https://en.wikipedia.org/wiki/Hardware-based_full_disk_encry...

That requires you to trust the disk to implement many finicky crypto details correctly in its proprietary black box, you can't get any assurance about that with reasonable cost. And SSDs have a horrible track record in the area, manyimplementing SECURE ERASE so it leaves your data on the flash chips. And if you choose a disk model, make your investigations and find it passes your sniff test, disks are no longer a commodity part for you.

Re: Securing PostgreSQL [pdf]

#58

Post by amirmansour »

pjlegato wrote: post #43
tzaman wrote: post #2

So true, which is why I find it kind of awkward when I say to young developers/business owners they should pay for a professional PostgreSQL hosting and they argue it's open source and they can host their DBs on a $25 (or less) Digital Ocean instance. Until it's too late, I guess.

We (databaselabs.io) are the first Postgres as a Service on DigitalOcean. We fight this sales battle on a daily basis. The problem is that younger devs/owners are much less likely to have ever experienced any significant outage, so it's a non-issue for them. They can't see why they should pay good money to prevent it. We've had much better results with slightly older and more experienced people, who realize that our…

How are you guaranteeing 100% uptime if your service relies on third-party infrastructures?

Re: Securing PostgreSQL [pdf]

#59

Post by jve »

"For critical passwords, use split passwords with dual custody."

Could anyone comment on the practice? Does it mean that I have the first half of password and other guy has the other? We can only log in by combining password? How do we type the password in by not sharing a physical computer?

Re: Securing PostgreSQL [pdf]

#60

Post by srd »

I have a question about storing the encryption keys. How would one actually securely store them and distribute them among the application servers in a cloud environment.

I don't buy into the 12-factor-application way of storing sensitive data in an environment variable ("ps ae" and a local intruder has the data).

Storing it in a secured file on the server requires the file to be distributed by the provisioning service, thus implying the key being stored in a repository (that just isn't your application code, but a repository none the less).

Using an api service to with client certificates doesn't really help either, because if the application code can access the required configuration and certificates, so can an intruder with shell access (since the intruder most likely has the user permissions of the running application before doing a privilege escalation attack).

I haven't seen an answer to that question that really satisfied me in the past. Does anyone have a battle tested method for storing database encryption keys?

Post reply on HN