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.
Securing PostgreSQL [pdf]
11–20 of 72 posts
Re: Securing PostgreSQL [pdf]
#12The 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.
Re: Securing PostgreSQL [pdf]
#13So 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.
Re: Securing PostgreSQL [pdf]
#14Earlier 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.
Re: Securing PostgreSQL [pdf]
#15Re: Securing PostgreSQL [pdf]
#16> 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…
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]
#18The 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?
Don't use pgcrypto. Use libsodium to encrypt in your application.
Re: Securing PostgreSQL [pdf]
#19So 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]
#20So 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.
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.