Cormac Redmond

Hi,

I'm building an app in C#. I won't bore you with the details, but basically I have two security questions. Any help would be much appreciated!

1. I will be saving files on a external server. I would like to encrypt the files before sending them. Different 'users' will be using this app. What are the best practices regarding C# to encrypt files Public/Private key encryption Where would I store the keys...in the registry I'm well versed with regards the cryptography in theory, but do not have much experience in practise. What API's....where Etc, etc...Any ideas ..


2. The application be will be using a third-party service, which requires a username/password. I suppose this username and password will be kept on a database somewhere, and the app will retrieve it. What are normal practises for this kind of thing Store it on a database on server, and have the application request it Should it be plain-text or encrypted If so, how so Remember, the idea is that users of the app can use this service, but should never know the username/password.

There's just a huge amount around on encryption, etc - but no real 'this is the right right way' methods. Any help appreciated.

By the way, this is for a fictitious company, so don't worry - this won't be a security risk!


Regards,

Cormac Redmond


Re: Visual C# General Security - normal practise? Please reply

Keith Rome

First and Foremost: don't try to write your own cryptography. It is good to understand the mechanics involved and even the actual implementation to a degree - just dont try to build that part yourself.

1. Have you considered using EFS support from Windows Server 2003 It might be enough protection for your situation.

2. Take a look at DPAPI. This is a built-in API in Windows Server that allows for safe storage of credentials (protected by the LSA). The usernames and passwords assigned to Services for startup parameters are stored here. There even some support in the Cryptography Application Block that can probably help make it a little easier to use:

http://msdn.microsoft.com/practices/compcat/default.aspx pull=/library/en-us/dnpag2/html/crypto1.asp

HTH






Re: Visual C# General Security - normal practise? Please reply

frederikm

Hi,

one thing you could do is the following:

choose an encryption type like DES3 (see http://msdn2.microsoft.com/en-us/library/system.security.cryptography.aspx)
decide on the key, initial vector and password (you can keep these hard coded)

- store the encrypted user credentials in the registry (see http://msdn2.microsoft.com/en-us/library/microsoft.win32.registry.aspx )
- @ runtime retrieve the credentials and decrypt them and use them in any fashion you desire.

when deploying the assembly use the obfuscator tool to "hide" the key, inital vector and password

Hope this helps, please close the thread if it does






Re: Visual C# General Security - normal practise? Please reply

Keith Rome

Relying on an IL obfuscator to protect a hardcoded encryption key is an extremely insecure method. It is considered a trivial task to open the compiled assembly in ILDASM or Reflector and locate and extract the embedded key data.

In general, "security through obscurity" is not a good tactic.






Re: Visual C# General Security - normal practise? Please reply

frederikm

Hi

i know that this a tactic to be frowned upon,
however it is a practice that i have had to implement a number of times due to real-world constraints.
security through obscurity works as long as you have a not-so-tech-savy end user...

In this case, if you need to store credentials in the registry,
you need to encrypt them, otherwise why even use the registry

if you have encrypted values, you need to decrypt them...
so you need the initial vector, key and so on

Could you point me to a better solution than relying on obfuscated code






Re: Visual C# General Security - normal practise? Please reply

PhilipRieck

If they have Google, that not-so-tech-savy end user can surprise you. I've seen a case where a temp hired for inbound phone order entry that had very little technical experience (didn't own a computer, etc) managed to change commission rates because she used google and found a tool written by someone who was tech-savvy. Yes, this was a custom, internal-only application. It was only discovered because she bragged about it to a few too many people.

If you hardcode your encryption key, you're stopping only the casual curious from reading the data. You're not actually securing anything. It's the same reason I don't put a key to my front door under my doormat. You may think you're thwarting burglers by putting it in the flower pot instead, but they'll look there too.

The bigger problem is when you do this and the people relying on the security feel all secure. Knowing that you have no security at all is much better than thinking you're secure when you're not. If what you're doing is simply making it harder to casually read/edit the data, make sure people know that is what you've done. It may be that due to the value of the data and the constraints of the system, this is acceptable. *

As to a better solution than relying on obfuscated code - I feel that they are all better. It's tough to give you a hard example that will satisfy you without an actual system and environment to discuss. (Let me point you to "Writing Secure Code" by Howard and LeBlanc). For the purpose of keeping keys, use Keith's suggestion and look at DPAPI. Here's a link on DPAPI in .net - http://blogs.msdn.com/shawnfa/archive/2004/05/05/126825.aspx. Or, again as Keith points out, look at EFS for keeping data. But whatever system you're working on will have it's own needs - perhaps

* (As an aside; We all have real-world constraints, but look into threat modeling to determine the holes you need to plug, what's important, and what the risks are of the security tradeoffs you have to make - here's a good quick read that has concepts beyond the web app it refers to.)





Re: Visual C# General Security - normal practise? Please reply

frederikm

Hi,

I must admit that the link you gave seems to be the better solution :)

As for the real world constraints, the company we had to implement the hard coded keys
in was actually a bank... Due to the securtiy processes in place already we could only
use the aforementionned solution.

The application ran serverside, so the exposure was minimal.

Furthermore, the registry was protected, something that slipped my sleepy mind yesterday.






Re: Visual C# General Security - normal practise? Please reply

Keith Rome

I am actually quite surprised that a bank's IT policy would send you down that path. Any financial institution that I have done work for has always had the opposite policy. In fact, they almost always have a security review of every project where these things are looked at under a magnifying lens, and in one case they even brought in a 3rd party firm that specializes in security to perform the security audits.

I would also point out that just because the application runs server-side only does not make it immune to attack.






Re: Visual C# General Security - normal practise? Please reply

frederikm

Hi

we actually had to deliver a securtiy dossier, which is standard practice at our firm..
also, the bank has an internal security division..

the constraint was that the password used was one of a technical user,
so it had to be resettable by script, hence the inserting into the registry...

I know that even server side programs are attackable,
but to get to the registry and dll you had to have administrator credentials on the server box,
so that was already a very limited subset of people.