Cryptography: is there any examples of data that should be encrypted?

[blep]

Concerning the following question in the web framework templates:
What in the application is encrypted? Are there items that should be
encrypted that are not?

Is there any concrete example of things that should be encrypted in
web framework? Security issues frequently come from the fact that
developers are not aware those information are sensitive, and I can
come up with an example that relate to web framework...

To my knowledge web framework usually persist little data, and even so
it usually done by application/extension/WSGI middleware made using
the webframework. Session being the most common one I think, but I
have trouble seeing why you would need to encrypt it...

Baptiste.

[Craig Younkins]

Baptiste,

Great question. When I wrote that question I was thinking more along the lines of an application rather than a framework. The two sometimes blend together depending on how much the framework handles. 

I can't think of a reason why most frameworks would need to encrypt data. If the framework handles user accounts the passwords should be salted hashes (different from encryption), and perhaps should encrypt user data such as names, addresses, etc. It's a grey area of how paranoid you want to be, and it certainly depends on the application.

I'd like to revise the question to be something like this: Does the framework provide a system for applications to encrypt data? If so, what is the algorithm, etc. We'd like to see frameworks provide the structure to do solid encryption in applications even if the framework itself doesn't need it. Providing a generic mechanism to encrypt data would be great, and a configuration toggle to encrypt stored user data (if such a thing is handled by the framework) would be wonderful as well.

Some things that should always be encrypted:

• Social Security Numbers
• Credit card numbers or other financial information
• Retrieve password questions and answers
• <I'm sure there are more, just can't think of any right now>

Then it gets into more application-specifics. For example, if you have a website with medical information for patients you had better use transport layer encryption as well as encrypt all patient information in the persistence layer. 

Hope this answers your question.

Best,

Craig Younkins

[Baptiste Lepilleur]

2010/7/2 Craig Younkins <cyou...@gmail.com>:

> Baptiste,
> Great question. When I wrote that question I was thinking more along the
> lines of an application rather than a framework. The two sometimes blend
> together depending on how much the framework handles.
> I can't think of a reason why most frameworks would need to encrypt data. If
> the framework handles user accounts the passwords should be salted hashes
> (different from encryption), and perhaps should encrypt user data such as
> names, addresses, etc. It's a grey area of how paranoid you want to be, and
> it certainly depends on the application.
> I'd like to revise the question to be something like this: Does the
> framework provide a system for applications to encrypt data? If so, what is
> the algorithm, etc. We'd like to see frameworks provide the structure to do
> solid encryption in applications even if the framework itself doesn't need
> it. Providing a generic mechanism to encrypt data would be great, and a
> configuration toggle to encrypt stored user data (if such a thing is handled
> by the framework) would be wonderful as well.

This new question makes more sense, though, given your explanation
below I think the first one could be kept and made more concrete...

> Some things that should always be encrypted:
>
> Social Security Numbers
> Credit card numbers or other financial information
> Retrieve password questions and answers
> <I'm sure there are more, just can't think of any right now>

The "Retrieve password questions and answers" is likely to be found in
some implementation of authentication "module" that comes along with
some web-frameworks (django comes to mind, but I don't know if it
stores such a question).

This needs to be encrypted to prevent stealing everyone account if you
somehow got your hand on the database, right? IMHO, this an example
that should be in the original question as it is not an "obvious" fact
compared to Social Security Number or Credit Card Number...

> Then it gets into more application-specifics. For example, if you have a
> website with medical information for patients you had better use transport
> layer encryption as well as encrypt all patient information in the
> persistence layer.
> Hope this answers your question.

Yes, you clarified many questions I had.

Thansk,
Baptiste.