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

21–30 of 72 posts

Re: Securing PostgreSQL [pdf]

#21

Post by tonyhb »

floatboth wrote: post #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 lon…

Yep. I've used NaCl for edwardian curves using djb's boxes and it's pretty much ideal as far as I'm concerned.

Re: Securing PostgreSQL [pdf]

#23

Post by knorker »

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.

Re: Securing PostgreSQL [pdf]

#24

Post by Cyph0n »

floatboth wrote: post #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 lon…

Why is using AES-256 directly considered "bad"? Is the issue key management? RNG? Padding? Or what exactly? Genuine question.

Or do you mean that re-implementing AES-256 in your own library instead of using a well-tested implementation is "bad"?

Re: Securing PostgreSQL [pdf]

#25

Post by greendragon »

Cyph0n wrote: post #24
floatboth wrote: post #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 lon…

Why is using AES-256 directly considered "bad"? Is the issue key management? RNG? Padding? Or what exactly? Genuine question. Or do you mean that re-implementing AES-256 in your own library instead of using a well-tested implementation is "bad"?

https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

Re: Securing PostgreSQL [pdf]

#26

Post by rch »

whitepoplar wrote: post #13
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.

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

I've been happy with Amazon RDS.

Re: Securing PostgreSQL [pdf]

#27

Post by Cyph0n »

greendragon wrote: post #25
Cyph0n wrote: post #24

Earlier quoted context omitted.

Why is using AES-256 directly considered "bad"? Is the issue key management? RNG? Padding? Or what exactly? Genuine question. Or do you mean that re-implementing AES-256 in your own library instead of using a well-tested implementation is "bad"?

https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

The context of the long-winded conversation you linked to is user auth and session cookies. That's a VERY specific use case for AES.

I'm talking about AES in general.

But I still skimmed through it.

TL;DR

* AES CBC instead of ECB or (gasp) Triple DES

* SHA-1 instead of MD5

* Use MACs

* Be careful with padding

Re: Securing PostgreSQL [pdf]

#28

Post by tptacek »

Cyph0n wrote: post #27
greendragon wrote: post #25

Earlier quoted context omitted.

https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

The context of the long-winded conversation you linked to is user auth and session cookies. That's a VERY specific use case for AES. I'm talking about AES in general. But I still skimmed through it. TL;DR * AES CBC instead of ECB or (gasp) Triple DES * SHA-1 instead of MD5 * Use MACs * Be careful with padding

* ECB is not an alternative to 3DES

* If you use 3DES or any other 8-byte block cipher you import several additional security concerns you have to code around

* If you use CBC you also have to get the IV right, which tons of carefully designed crypto has failed to do

* SHA-1 is also insecure

* Neither MD5 nor SHA-1 is a MAC

* Your choice of MACs brings with it new security pitfalls

* How you apply the MAC also has pitfalls; see, for instance, all the systems that have managed to leave CBC IVs out, because they were specified as separate arguments

* Padding is a pitfall if you use CBC... or a few other modes --- guess which!

* If you use something other than CBC you get other pitfalls

* "Be careful with padding" is a vague description of like 6 different padding vulnerabilities you have to know about

* You still haven't even generated a key yet

* In the unlikely event you get all of this right, all you've managed to do is write a very basic symmetric key seal/unseal --- you're still only 40% of the way (in functional terms) to something as simple as NaCL

So, no, I would not say that was the TL;DR of that piece. I think the TL;DR of that piece is right there in the title.

Re: Securing PostgreSQL [pdf]

#29

Post by tptacek »

tonyhb wrote: post #21
floatboth wrote: post #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 lon…

Yep. I've used NaCl for edwardian curves using djb's boxes and it's pretty much ideal as far as I'm concerned.

Edwards curves, not Edwardian. They didn't have those curves in 1905.

Curve25519 isn't an Edwards curve. Ed25519 is the equivalent Edwards curve. Curve25519 is a Montgomery curve. NaCL uses C25519 for DH, and Ed25519 for signing.

I'm just responding to the nerd snipe (and eagerly awaiting my comeuppance from 'pbsd). You're right (in advance) that the point of using NaCL is that you don't need to know any of this trivia.

Re: Securing PostgreSQL [pdf]

#30

Post by rzzzt »

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...
Post reply on HN