[WEB SECURITY] Encrypting Client Data

Kevin Stewart kevin.g.stewart at gmail.com
Sat Jun 11 16:35:59 EDT 2011


IMHO, data encryption at rest is best accomplished between the
application and data tier. Generally speaking, passing an encryption
key to the client isn't a good idea. Relying on the client side at all
to protect the integrity of data (or encryption keys) is just bad
form. So the data should be encrypted at the application before it
gets to the database, and decrypted at the application before it goes
to the client. Then use standard SSL/TLS to protect the data in
transit. The database information is now secure and you only need to
protect the encryption keys at the application layer - which is a
completely different conversation...

Kevin


On 6/10/11, Paul Johnston <paul.johnston at pentest.co.uk> wrote:
> Hi,
>> One of the
>> proposed solutions is to have the end user download an encryption key
>> file as part of the process of establishing an account on the system.
>> When they log in they would then upload the encryption key file as
>> part of the authentication process.  The key would then be temporarily
>> stored in memory on the web server and used to decrypt the data coming
>> out of the database, or to encrypt new data before it's stored.
> An alternative you could consider is to have the client generate the
> encryption key during account setup, and for this never to leave the
> client. They encrypt everything before it goes to your server, and
> decrypt it when it comes back. In this case they are (almost) completely
> protected against a server compromise. However, it would stop your
> server being able to do any processing of that data.
>
> With the scheme you propose, a dedicated attacker could sit quietly on
> the compromised server, and record encryption keys as they are used -
> eventually being able to access all the client data.
>> In my mind this also helps to create strong
>> authentication because we're using two factors: something they know
>> (account password) and something they have (valid encryption key
>> file).
> Some would argue that the encryption key file is still "something they
> know". But either way, this is certainly stronger than single-factor
> authentication.
>
> An arrangement somewhat similar to what I propose is used by Firefox
> Sync, but for different reasons. It's primarily intended as a privacy
> mechanism - so the servers never see your browsing data. The protection
> against server compromise is somewhat incidental. Apart from that, this
> isn't an arrangement I've seen in any production system. I suggest you
> think carefully - and ideally produce a written risk assessment - about
> how sensitive your data really is. Most organisations are happy with
> HTTPS encryption for data in transit, and for particularly sensitive
> data, full disk encryption of data at rest. Key management for these
> scenarios is well understood.
>
> Regards,
>
> Paul
>
> --
> Pentest - When a tick in the box is not enough
>
> Paul Johnston - IT Security Consultant / Tiger SST
> Pentest Limited - ISO 9001 (cert 16055) / ISO 27001 (cert 558982)
>
> Office: +44 (0) 161 233 0100
> Mobile: +44 (0) 7817 219 072
>
> Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
> Registered Number: 4217114 England & Wales
> Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK
>
>
> _______________________________________________
> The Web Security Mailing List
>
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
>
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> WASC on Twitter
> http://twitter.com/wascupdates
>
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>


-- 
Kevin G. Stewart




More information about the websecurity mailing list