• Confidentiality attacks against the database are more generally more lucrative than eavesdropping; the database is the equivalent of the "bank vault"
  
• SSH, HTTPS, VPNs etc.. protect data in transit. Database encryption protects the data at rest.
  
• Access controls, backup, recovery plans, regular audits, secure connections all important, but database encryption is the last line of defence
  
• Database encryption can help with:
• External attacks (access to the live database, stolen database backups, SQL injection, etc..)
• Internal attacks (database admin, QA staff with read-only db accounts, "casual reading" by super-admins, etc..)
• Privacy and Security Legislation, Corporate Compliance Agreements, Trade Regulations, Business Reputation, e.g. in the USA:
  
• Health Insurance Portability & Accounting Act (1996 - Health Data)
• Sarbanes-Oxley Act (2002 - Financial Data)
• Gramm-Leech-Bliley Act (2005 - Financial Data)
• California Information Practices Act (2005 - Privacy)
• Children's Online Privacy Protection Act (1998 - Privacy)
• Payment Card Industry (PCI) Data Security Standard, requirement 3.4 (Financial Data)
• File-system encryption is too transparent, doesn't help much
  

• WebGUI::Crypt namespace
• WebGUI Site config file used to choose Crypt provider:
  {...
      crypt: {
          provider: 'WebGUI::Crypt::MyProvider',
          provider_specific_option_x: '...'
      }
  }
• Provider implements an encryption strategy (some possible providers discussed in the next section)
• Extra "encrypt this field" Yes/No option added to Field definition dialog in Wobjects such as UserProfile, Thingy, Survey2, DataForm, etc.. When selected, Wobject automatically calls WebGUI::Crypt provider's encrypt() and decrypt() subroutines prior to reading/writing that field to the database
• N.B. This might be best done via the new WebGUI 8 Form API
• N.B. Encryption is a performance hog so users would only want to enable this for fields that really need to be protected (identifying confidential data is the responsibility of the site admin)
  
• N.B. General caveats of db encryption applies. Manual SQL will need to change (e.g. keywords such as ORDER BY won't work unless we get clever and add in extra fields such as "first_letter" for encrypted fields)

• Single encryption key, stored in broad-daylight in the webgui site config file.
  {...
      crypt: {
          provider: 'WebGUI::Crypt::Simple',
          key: 'ABCDEFG'
      }
  }
• Uses Crypt::CBC to encrypt() and decrypt() via a symmetric key
  
• Key only as safe as the webgui account on your modperl server(s)
• Minimal performance hit, no real scalability problems
  
• A good candidate for the first "proof of concept" crypt provider due to its simplicity
• A possbile extension that JT thinks is lame =p
  
• If the key is specified as "ask" then prompt the sys-admin to enter the key at modperl start-up
• Means that key is stored in memory and not in the webgui site config file (but it might end up in your O/S swap file, etc..)
  
• Will annoy the hell out of your sys-admin, and any security improvements are arguable
• The whole "modperl restarts as soon as it starts" thing thwarted me from figuring out how to make this work
  

• Do the encryption in a separate process and have modperl request encryption/encryption via IPC
• Log all crypto requests and monitor for suspicious spikes in activity
• Again, could prompt for key on service start
  
• Again, no fundamental improvements in security, but may increase the difficulty in extracting the key via obfuscation if separate process runs off compiled code (although it could still be extracted from memory, swap, etc..)
  
• Increased performance hit, but no scalability issues (you just need to run the service on every modperl server)

• Use a dedicated, Hardware Security Module (HSM), connected via serial port, local network etc..
• All crypto requests go via HSM. Log and monitor for suspicious activity.
  
• Key never leaves HSM. 
• HSM is preferably a commercial-grade, tamper-proof device, but could also be a locked-down regular server
• The recommended approach according to "Cryptography in the Database: The Last Line of Defense", Kevin Kenan , Symantic Press/Addison Wesley
• Much increased performance hit, scalability issues

• I've only proposed crypto solutions that use a single key to encrypt/decrypt everything. Mature crypto systems have an entire key management infrastructure so that columns can be mapped to keys, keys can be introduced and revoked, retired after key fatigue sets in, etc..
  
• Implementing crypto badly can be worse than no crypto at all because it creates a false sense of security, might lock you out of your own data, etc..
  
• None of the providers I've mentioned are perfect, they all suck. Then again, storing confidential information in plaintext sucks more.
  

knowmad wrote:

Hey Patrick,

Good discussion and explanation of the issues and possible solutions. Before we decide on how to encrypt, I think we need to discuss what to encrypt.

It doesn't make sense to me that the whole database gets encrypted. There'd be a double performance hit of decryption plus the loss of the ability to do page caching.

For the sites we've rolled out, the only tables with sensitive data that I can think of are the user profile info and the shopping cart data.

In addition, it would be useful to be able to encrypt some of the external databases though I'm not sure your solution intends to support that feature. We'd potentially need to be able to use it outside of WebGUI so that non-WebGUI services could decrypt the data.

 

William

----
Knowmad Technologies
http://www.knowmad.com

http://www.plainblack.com/webgui/dev/discuss/webguicrypt/1


--

Plain Black, makers of WebGUI
http://plainblack.com

arjan wrote:

He Patrick,

Very nice discussion of the options.

Right now, I don't think I would use this. It's not something I would want to use, but I can very well image that it will be demanded of us in the future. First to store emailadresses safely and profile data. But also the contents of mailboxes. We also run a website where medical specialists have subsites and use WebGUI's mailboxes to email with patients. But potentially anything, because if you're building a site with medical or privacy sensitive data it's nice to have all kinds of assets at your disposal.

I also agree with Williams last two remarks: it's usefull to be able to encrypt an external database and it's very nice if you could use it outside of WebGUI.

I don't know much about this subject, but it seems that it requires an analysis of the whole proces of storage in a database, data transfer mechanisms, database authorization and access controls, and database auditing. Database encryption makes sense if you have an overview over all the duplication of the data and the whole proces of acess. That doesn't seem that easy.

Somebody who used to work with us and used be active in the WebGUI community, Leenert Bottelberghs, does know a lot about encryption and storage. I'll point him to this thread.

 

Kind regards,

Arjan Widlak

United Knowledge
Internet for the public sector

www.unitedknowledge.nl

http://www.plainblack.com/webgui/dev/discuss/webguicrypt/2


--

Plain Black, makers of WebGUI
http://plainblack.com

WebGUI::Crypt::Simple seems like a great idea as the conf files and swap are inherently more secure than the database.  I don't see how this is anything but an improvement over no security.

WebGUI::Crypt::IPC also is a great idea.  IPC can be offloaded to other machines for load balancing, and the key can be protected so that it can never be compromised, and only accessed if the webserver's root account is compromised.  The only real gain here is that if root is compromised, the data can only be accessed from this machine (that and the crypto load balancing).  The data can't be taken home for later decryption.

But in the end, the easiest vector is WebGUI itself.  If WebGUI::Auth is defeated, then all the system controls in the world won't keep WebGUI from doing what it is supposed to do; serve up the data to an account with permissions to view it.

JT wrote:

I've waited to respond to this to see what the community had to say.  
In general I'd agree that this is a nice thing to have in the core,  
and definitely not only important but required by some sites.

My primary concern with this is performance, which is why I wouldn't  
support whole database encryption. Most stuff simply doesn't need to  
be encrypted.

On the fields that do need to be encrypted, I think that we shouldn't  
use a perl module to do it. Instead, I think we should use MySQL's  
native encryption mechanisms. Because I don't think it's important to  
encrypt information in memory, you really only need it encrypted in  
transport (covered by SSL) and storage (the database). If you have to  
worry about whether the memory of your running processes is  
compromised, then you have a whole hell of a lot of problems, and  
encryption isn't likely to help you out of them. In addition, handling  
encryption inside of WebGUI using perl modules would be ten times  
slower than doing it at the field level in the database.

• MySQL native encryption - fast. key stored in webgui config file. compromise of modperl enough to steal data and key. compromise of db server may yield key too.
  
• WebGUI::Crypt::Simple - slow. key stored in webgui config file. compromise of modperl enough to steal data and key. compromise of db server only yields encrypted data, not key.
  
• WebGUI::Crypt::HSM - fast. compromise of modperl enough to decrypt data request-by-request via live HSM. key never leaves HSM.

• lib/WebGUI/Crypt.pm - the pluggable crypt layer
  
• lib/WebGUI/Crypt/Simple.pm - a simple proof of concept provider that uses Crypt::CBC
  
• t/Crypt/Crypt.t
• t/Crypt/Simple.t

• Session.pm - so that you can do: $session->crypt->encrypt("..")
• Inbox.pm - to demonstrate simple encrypting of the message field
• t/Inbox.t

• WebGUI::Crypt::Simple uses AES by default (Crypt::Rijndael), but you can specify any Crypt::CBC supported cipher in the WebGUI site config file
• I'm using hex-encoding of the ciphertext in WebGUI::Inbox so that message field db type didn't need to change to binary (but obviously would be more efficient to store as binary)
• Crypt::CBC generates a random initialization vector and prepends this to the encrypted data as a standard header that can be re-read at decryption time. This is necessary to prevent various cryptographic attacks on the database. A WebGUI::Crypt::MySQL provider would need to generate and handle this manually.