Sensitive Info

A portion of building secure applications is protecting them from others. But yet another portion is protecting them from ourselves. Below is a trick which may help in building applications which respect privacy.

Do note that before going further that this does not solve all security issues, and that you are still responsible for making sure sensitive information is kept secure. I present this trick simply as a concept for individual consideration or ideas. The idea requires individual implementation of which I am not responsible for any damages. It is a springboard to other privacy features as well.

Sensitive Info Container

pub struct SensitiveInfo<T> {

item: T,

privacy_setting: PrivacySetting,

}


impl<T> SensitiveInfo<T> {

pub fn get_sensitive_info(&self /* Add parameters if needed */) -> &T {

//Do extra logic here.

&self.item

}

}

Here is one example of a sensitive info container. The structure has two members: the item (sensitive information), and a privacy setting. To continue with this example, the privacy setting is simply an enumeration.

pub enum PrivacySetting {

Me = 0,

Friends = 10,

Everyone = 20

}

Benefits

Code Kept Clean

pub struct User {

name: SensitiveInfo<String>,

age: SensitiveInfo<i32>, //int

occupation: SensitiveInfo<String>,

}

Both the security and the value itself are all one parameter. It may reduce the complexity.


Proactive Approach

let name_new = SensitiveInfo {

item: "Alex",

privacy_setting: Me,

};

Data is initialized right with the privacy settings. Privacy isn't an afterthought, nor is some extra feature to be implemented later, forgotten about, etc.


Reminders

let person_name = name.get_sensitive_info();

Calling such a function is a constant reminder that the data retrieved is sensitive.

Notice how calling user.name in this example doesn't actually return a string, but returns the container:

let name: &SensitiveInfo<String> = &user.name;

To actually retrieve such value, one must call get_sensitive_info(). This acts as a constant reminder that the information kept here is sensitive, and to not be passing the value all over the place in code.

let name: &String = user.name.get_sensitive_info();


Validation

get_sensitive_info() could be implemented virtually, abstract, etc. It provides a nifty accessor by which an error could be thrown if, for example, the wrong user is trying to access the data. Careful though, as not all pieces of sensitive info should be validated the same. Consider sub-classes, or the equivalent. In Rust, this could be a Trait.


Word of Caution

Privacy should still be considered case by case

One can create other types of sensitive info containers, and adapt them to individual needs. Don't just get into the habit of sticking everything in the same type of container.


Data can still be accessed by other means

This container does not prevent from other exploits.

  • There is a pointer/reference to the data. Private does not prevent someone from using a hex editor. Many languages can use reflection and other means to access private variables.

  • Pointers can still point to it.

  • Etc.

It is more of a design technique. While even the developer can get around it with the above suggestions, it makes it more inconvenient to do so, and simply calling get_sensitive_info() then solves it.


This reminder ends when retrieved

If the value is saved somewhere else outside the container, the point is lost. Exercise caution when assigning the value to a temporary variable.


This isn't a completely secure container

This discusses ways in which a container can be used to better organize and be reminded of sensitive information. Additional features are needed to make this more secure from other potential vulnerabilities, such as encrypting the contents.


Where is it being validated?

I personally would not do any of this logic on a client application.


This is just one arrow in the quiver

Employ all other needed security and privacy concepts which can correctly keep private data secure.


Disclaimer

The following is presented conceptually. While I am not responsible for any damages in the use of this concept, adapted or otherwise, I hope it helps or stems ideas. Similar concepts exist already, this is simply an introduction.