T5WTPYAFGP - Encrypt Sensitive Information

转载 2012年03月21日 10:11:57
At South by Southwest this year, during my talk Defense Against The Dark Arts - ESAPI I covered the "Top 5 Ways To Protect Your Application From Getting Pwnd" [T5WTPYAFGP]. After a couple offline conversations I decided that this would make an excellent series of follow-up blog posts so what follows is the adaptation of that presentation material from that talk. Unlike a lot of other Top-N lists, the goal of this one is not to iterate the flaws, but rather to iterate the solutions.

Additionally each post includes some samples on how you can use ESAPI to implement the solutions discussed and gives us the opportunity to dive into each area a little deeper than we were able to in a one-hour presentation.


You can use the navigation below to navigate between each of the posts.

[5] Encrypt Sensitive Information [current]
[4] Become Big Brother

5. Encrypt Sensitive Information
Number five on our list is to encrypt sensitive information. To understand this one we first need to define what actually constitutes sensitive information.

Most organizations that store credit card numbers are (hopefully) storing those credit card numbers in an encrypted format already, but what about the rest of the information that is stored. Think about your own organization or application - what information do you collect from your users?

According to published information, anything that is personally identifiable information, financial information, or medical information is to considered sensitive data and should be treated accordingly. Any organization that has to deal with standards verification will generally check the box for storage of sensitive information as long as that information is stored on an encrypted volume. This protects your customers from physical theft but what about run-time theft, which accounts for most of the largest breaches that occurred last year.

The key is to examine the risk for your application, determine what information would be damaging to release for your customers, and encrypt that data at rest. A lot of organizations simply don't want to incur the performance penalties of performing encryption and decryption of client data but some things are simply too important to ignore.

There are a number of ways to help mitigate the performance impact of using encryption in an application  and we will cover a few of them in this post.

The important thing is that once you have encryption configured (ie you have selected a provider and algorythm) actually performing the encryption and decryption of sensitive information is incredibly simple. 

  1. // Populate User Object from Request  
  2. // ...  
  3. // Encrypt Sensitive Information  
  4. CipherText encryptedSSN = ESAPI.encryptor().encrypt(new PlainText(userInfo.getSSN()));  
  5. userInfo.setSSN(new String(encryptedSSN.asPortableSerializedByteArray());  
  6. // Persist User Object  
  7. // ...  

To decrypt the data is just as simple. 
  1. // Retrieve persisted User Object  
  2. // ...  
  3. // Decrypt Sensitive Information  
  4. CipherText encryptedSSN = CipherText.fromPortableSerializedBytes(user.getSSN());  
  5. PlainText decryptedSSN = ESAPI.encryptor().decrypt(encryptedSSN);  
  6. userInfo.setSSN(decryptedSSN.toString());  
  7. // Prepare User Object for use in application  
  8. // ...  

Of course this can be abstracted into a service, added as an annotation processor in your persistence layer, and altered to be used in a more generic form that meets your specific platform needs. Additionally, depending on the type of information you are dealing with and the perceived risk of that information being leaked - it may make sense for the data to be encrypted all the time until it needs to be viewed or altered on the front end. This approach can also increase performance of the encryption and decryption because you are only ever performing this step when it is needed.

A comprehensive design is a little beyond the scope of this post, but when I do design I like to envision the end goal - that is what will the object I am protecting look like when I am done. To take the concept of the UserInfo object - here is what I envision as the end results:


  1. public class UserInfo implements Serializable {  
  2.    private final static long serialVersionID = 1L;  
  3.   
  4.    private Long id;  
  5.    private String username;  
  6.   
  7.    // This field will be stored in-memory and persisted as a hashed value using SHA-256   
  8.    @Sensative(type=SensitiveDataProtection.Type.HASH,  
  9.               algo=SensitiveDataProtection.Algo.SHA256  
  10.               mode=SensitiveDataProtection.Mode.RUNTIME)  
  11.    private String password;  
  12.   
  13.    // This field will be stored in-memory and persisted as an encrypted value using the SecretKey "UserData.SSN" for encryption and decryption  
  14.    @Sensitive(type=SensitiveDataProtection.Type.ENCRYPTED,  
  15.               key="UserData.SSN",  
  16.               mode="SensitiveDataProtection.Mode.RUNTIME)  
  17.    private String ssn;  
  18.   
  19.    // This field will be persisted as an encrypted value using the Master SecretKey but will be stored in-memory as a PlainText representation  
  20.    @Sensitive(type=SensitiveDataProtection.Type.ENCRYPTED,  
  21.               mode=SensitiveDataProtection.Mode.PERSIST)  
  22.    private String address;  
  23. }  


This looks pretty simple to implement for a developer and seems to address a lot of design needs, particularly the need to apply encryption only at the point where it is required. Annotations aren't for everyone however, so how can we accomplish a similar design goal without using Annotations? 

  1. public class UserInto implements Serializable {  
  2.    private final static long serialVersionID = 1L;  
  3.   
  4.    private Long id;  
  5.    private String username;  
  6.   
  7.    // This field will be stored in-memory and persisted as a hashed string  
  8.    private HashString password;  
  9.    // This field will be stored in-memory and persisted as an encrypted string  
  10.    private CipherText ssn;  
  11.    // This field will be persisted as an encrypted string  
  12.    private PlainText address;  
  13. }  


This example relies on the usage of data-types to specify the behavior of the data. While this breaks some rules in the world of design, it illustrates a possible solution to the problem.

Now do not be fooled into thinking that these solutions are simple to implement, they aren't - however the benefit of centralizing a standard control to perform this work is that you only have to write it once, you only have to maintain it in one place, and every developer of your application doesn't have to understand how the process works, just that it does.

In closing, here are each of the steps you should perform to address this problem and resolve it.

  1. Identify sensitive data in your application
  2. Design and implement a standard and centralized control
  3. Apply encryption to sensitive data in your application
Stay tuned for #4 on our top 5 list "Become Big Brother"!

相关文章推荐

Encrypt or Decrypt sensitive data using PLSQL - DBMS_CRYPTO

Oracle 10g introduced Transparent Data Encryption, which is about storing data physically as encrypt...

AES256 Encrypt information

  • 2014年09月15日 04:02
  • 1.3MB
  • 下载

Encrypt ——MD5、SHA等的Java实现

package com.siwen.security; import java.io.File; import java.io.FileInputStream; import java.io.Fil...

PMD 18T vector information

  • 2014年07月22日 16:13
  • 402KB
  • 下载

思考mysql内核之初级系列5---information_schema不是innodb数据字典

上次谈到了innodb缓冲区里面有些页被使用了,这些中有些被数据字典用了。那么什么是数据字典呢?bingxi和alex继续思考。   1) information_schema不是innodb数据...

Story of a PoC - F5 BIG-IP Cookie Information Disclosure

http://www.garage4hackers.com/f10/story-poc-f5-big-ip-cookie-information-disclosure-281.html Curios...

intel cpu 分类 i7、i5、i3、T系列、P系列

现在市场的CPU有T系列、P系列、E系列、还有i3、i5、i7.   T系列,是intel 双核,主要应用于笔记本。包括奔腾双核和酷睿双核,2以下的,比如T2140,是奔腾双核。2以上,T5800...
  • zqlovlg
  • zqlovlg
  • 2013年01月27日 00:11
  • 20678
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:T5WTPYAFGP - Encrypt Sensitive Information
举报原因:
原因补充:

(最多只允许输入30个字)