[WEB SECURITY] Encrypting Client Data

Gautam gautam.edu at gmail.com
Fri Jun 10 15:26:47 EDT 2011

I agree to points by Paul.

In my view there are things to answer.

   - Does your application need to decrypt the data from the database and
   show it onto the web application: If No, then what you are looking at is Pre
   Internet Encryption (PIE) where your client is just using you as a data
   store. In this case you don't need to do lot of things and follow as Paul
   mentions above.
   - If you need to decrypt the data that comes from the client then, i
   don't see a reason why they have to encrypt and send to you, and also share
   the key. I would rather take the data and encrypt it myself before it goes
   in the database.

I would say that if you want to do any kind of encryption/decryption your
side, you should consider using HSM and let it do the task of managing the
keys and encrypt/decrypt. This will isolate tasks and not do everything on
one server.

I am not a sales guy for SafeNet, but I have seen this getting used in some



On Fri, Jun 10, 2011 at 1:55 AM, 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110610/512be844/attachment-0003.html>

More information about the websecurity mailing list