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. (T
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 uniquely
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
off
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 Mail.
