Live data from Hacker News

Securing PostgreSQL [pdf]

thebuild.com

11–20 of 72 posts

Re: Securing PostgreSQL [pdf]

#11
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.

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

Re: Securing PostgreSQL [pdf]

#12
post #5

The problem with pgcrypto is the fact that in the logs there's the password? that's it? I would like to see the talk to get a better understainding of the whole message, is it available somewhere?

The fundamental issue is that you should not be exposing the encryption keys to the database. If you're using pgcrypto then you're issuing SQL statements in the database with the key. You should do your encryption client-side so that the key is never passed over the wire at all.

That said, pgcrypto is still useful, you can compute hashes or generate UUIDs with it.

Re: Securing PostgreSQL [pdf]

#13
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.

What companies do you think offer the most competent Postgres hosting?

Re: Securing PostgreSQL [pdf]

#14
post #12

Earlier quoted context omitted.

The fundamental issue is that you should not be exposing the encryption keys to the database. If you're using pgcrypto then you're issuing SQL statements in the database with the key. You should do your encryption client-side so that the key is never passed over the wire at all.

That said, pgcrypto is still useful, you can compute hashes or generate UUIDs with it.

The point was that you probably shouldn't use it for data encryption in the DB and think the server doesn't have the keys.

Re: Securing PostgreSQL [pdf]

#16
> Use a well-known secure algorithm (AES256 is considered the standard).

> Never roll your own crypto.

Directly using a primitive like AES is pretty much rolling your own crypto. (Creating an actual cipher and using it is just beyond ridiculous.)

What you should use is secretbox from NaCl (libsodium or tweetnacl). Or Keyczar, I guess that's still maintained (last commit on github is 21 days ago). Or TripleSec for long term things that you're really really paranoid about.

The point is, use a library that does authenticated encryption for you.

Re: Securing PostgreSQL [pdf]

#17

> Use a well-known secure algorithm (AES256 is considered the standard). > Never roll your own crypto. Directly using a primitive like AES is pretty much rolling your own crypto. (Creating an actual cipher and using it is just beyond ridiculous.) What you should use is secretbox from NaCl (libsodium or tweetnacl). Or Keyczar, I guess that's still maintained (last commit on github is 21 days ago). Or TripleSec for lon…

It's exactly rolling your own crypto. This is the second thread today on which someone has had to point this out (thanks!).

Virtually nobody writes their own ciphers. But "Don't roll your own crypto" is still important and still very common advice. Why? Because the stuff you do to actually apply "AES256" to your data is the stuff that actually causes crypto vulnerabilities.

In fact: if you do some reading on modern stream ciphers and design your own stream cipher, and then plug that cipher into libsodium, you are probably more secure than you would be if you tried to use AES256 in your own library without libsodium!

Re: Securing PostgreSQL [pdf]

#18
post #5

The problem with pgcrypto is the fact that in the logs there's the password? that's it? I would like to see the talk to get a better understainding of the whole message, is it available somewhere?

The bigger problem is that pgcrypto is 1990s cryptography: it supports Blowfish, has optional authentication, uses all-zeroes IVs, falls back to insecure RNGs, uses old cipher modes, has ambiguous padding...

Don't use pgcrypto. Use libsodium to encrypt in your application.

Re: Securing PostgreSQL [pdf]

#19
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.

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

PG has an good list in their website: https://www.postgresql.org/support/professional_hosting/

Re: Securing PostgreSQL [pdf]

#20
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.

Precautionary principle.

Multiply the odds of the problem by the costs of the problem. If a DO outage would cost you millions of dollars, then it will be much, much cheaper to spend $250,000 a year to fix a problem than it will be to deal with the consequences.

The problem is that most software developers are gamblers, and most businesses encourage that behavior. Some even cultivate it. We take stupid risks all the time and when we don't get caught we think that means that none of our actions have consequences.

And mostly those people are right. Stock options pay off so infrequently and so inconsistently that they are a poor incentive for long term thinking. In fact the only time I ever got any money out of options was because of a pump and dump by the founders (aka an acquisition).

Even the worst developers I've worked with would take 3-5 years to drive a company into the ground, unless nobody else was paying any attention at all. And when the company folds, they've still got years of take-home pay and they just have to find a new job.

Post reply on HN