From: | Toby Corkindale <toby(dot)corkindale(at)strategicdata(dot)com(dot)au> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Two-way encryption |
Date: | 2014-07-02 01:10:27 |
Message-ID: | 1807730134.323269.1404263427691.JavaMail.zimbra@strategicdata.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
----- Original Message -----
> From: "Patrick Simcoe" <patricksimcoe49(at)gmail(dot)com>
> To: pgsql-general(at)postgresql(dot)org
> Sent: Wednesday, 2 July, 2014 1:42:04 AM
> Subject: [GENERAL] Two-way encryption
>
> I have a question regarding two-way encryption data for specific columns.
>
> Does anyone have a technique or recommendation for two-way encryption which
> somehow obfuscates the decrypt key so that it isn't easily retrievable from
> the database or the application source code? We've already considered (a)
> letting users hold the decrypt key and (b) obfuscating the decrypt key with
> the user's own (one-way encrypted) password, but neither of these
> approaches are viable for us.
If you want the application to be able to decrypt the data automatically, then it has to hold the decryption key somewhere. There's really no way around that.
(Except getting humans to enter the key, but they get bored of typing passwords pretty quickly, and then post-it notes and keyboard macros end up storing your secret keys instead of relatively-secure server filesystems)
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2014-07-02 01:31:10 | Re: pl/perl and recent perl versions - failing to load internal modules |
Previous Message | Jeff Janes | 2014-07-02 00:57:12 | Re: what specifically does vacuum have to scan / why does it need to rescan the same indexes many, many times |