On Thu, Aug 09, 2018 at 02:34:07PM -0600, Bear Giles wrote:
> Some regulatory standards require all UII, even all PII, information be
> encrypted within the database, not just on encrypted media. That's to
> reduce exposure even if someone gets access to a live server, e.g., via SQL
> Injection.
Some regulatory standards require all UII, even all PII, information be
encrypted within the database, not just on encrypted media. That's to
reduce exposure even if someone gets access to a live server, e.g., via SQL
Injection. (The perennial #1 risk for software vulnerabilities.)
UII is
On Thu, Aug 09, 2018 at 03:00:26PM +0300, Danylo Hlynskyi wrote:
> The problem
> ==
>
> [...]
>
> We don't trust full-disk-encryption or any other transparent encryption,
> because of possible SQL injections.
Can you elaborate on this?
> Solution 1 (possibly can be used even now)
>
There are alternatives. If you know what you want to find, e.g., a search
by username or email address, you can store a strong hash of the value as
an indexed column. By "strong hash" I mean don't just use md5 or sha1, or
even one round with a salt. I can give you more details about how and why
On August 9, 2018 5:30:26 PM GMT+05:30, Danylo Hlynskyi
wrote:
> ?Is it hard to implement soluition 2?
Yes.
To the point that I'm fairly certain that an implementation would be considered
to costly to maintain (vs benefit) of proposed.
Andres
--
Sent from my Android device with K-9
Hi! Haven't found discussions on possible ways to encrypt indexes. Let's
start!
The problem
==
I'd like to encrypt some columns (first name, last name, SSN, etc...) in a
nondeterministic way. This can be done using `pg_crypto`, but then I loose
full-text-search (and any other indexing)
