I am developing an distributed VB.NET 1.1 application with a TripleDES capable socket layer for communication with my server app.
I need to secure the distributed app from the users within the organization I am developing it for (a franchise).
I do not wish to store any encryption keys in the source code as these would be obvious to any seasoned hacker through decompilation of my binaries (even with obfuscation). I have decided to use the windows DPAPI (under machine storage mode) to secure manually entered (at installation) encryption layer keys in the registry. The salt values for this DPAPI mode also need to be secured, as a disgruntled franchise owner may be the hacker (and hence would have admin privilege on the machine the software is installed on). Not as far fetched as you think !
This is the beginning of a vicious cycle. How do I secure and where do I store this salt value safely With it a hacker with admin privilige can easily decrypt my keys if they know I am using machine mode DPAPI. Can I use ACLs to protect the keys with an account I set up manually on the machine If so then I would need to be able to switch account identities in my code (which I haven't researched as yet) and then would need to store the password to that somewhere.
If anyone could offer any insight or direction it would be much appreciated.
Secure .NET 1.1 application from users
totem_pty
Thanks Nicole.
In light of your answer I think the best approach for us would be a disconnected centrally held DB driven model. Whereby requests for data are handled remotely by my server app and only sets of authorised data are transmitted.
I have one more question regarding my revised approach if you would indulge me. I am planning to encrypt the TCPStream on which the communication will be based on a symmetric method (due to its ease of use on streams). This key will be stored manually using DPAPI and changed regularly.
Is it recommended to include a further method of authentication (kerebos if possible ) on top of the client having to know the secret key if providing simple static user based authorisation
That is, if the client apps provide static hard-drive/windows serial numbers as authorisation then they would receive no authorisation if they didnt know the correct secret key to encrypt the credentials with (implied authentication in a sense).
Lucas Loizaga
As well you shouldn't--it's quite easy to hack.
In that case, the minimal exposure of the key would presumably be in memory at the time of its use (assuming it were fetched from your central server at each use rather than storing it locally). However, it would still be retrievable by a sufficiently determined machine admin, so this probably isn't adequate protection for your target scenario.
In addition, I doubt that searching through high volumes of encrypted data is going to offer the performance benefit that you seem to desire. Unless very few searches are likely to involve pattern matches against encrypted strings (which is actually one of the most common search types in many/most LOB apps), speed is not likely to be one of the benefits of your proposed approach.
Sounds like that might be a good idea. Running all searches against a centrally held db would be an obvious alternative, but it might require a greater hardware and/or infrastructure investment than your organization is willing to support. If so, another candidate approach might be to parcel out the "local" data in sets that only include data to which the local folks ought to have access. Running with your current proposal and accepting the risk of key "theft" by a malicious admin is yet another possible approach. Evaluating the trade-off between the risk and cost of each of these is, however, a business decision, and probably not one that should be made without the active participation of the key stake-holders.
JamesPMoranIII
Thanks for the reply.
In answer to your question there are two types of data that require encryption. One is general communication traffic to and from my server app over a TCPStream. This is not such an issue as the main purpose of that encryption is to deter remote attackers and the key will be changed regularly (say every 3 to 4 weeks).
However, the other type of data I need to encrypt is connection strings and database information. This is for a co-deployed microsoft access database that will store confidential information (customer details). I require this database to be deployed on the client due to the sheer volume of information that needs to be rapidly searchable by the users.
I do not particularly trust the password feature on access databases so all information will be stored encrypted (by my application). This encryption method thus needs to be symmetric and the key cannot be changed. Hence the importance of its protection.
If this key cannot be sufficiently protected though I will need to find an alternate approach.
NB. I have changed my display name (Originally wozza35)
megadith
I see, I thought this post might have been moved from somewhere else, but I wasn't sure why it was moved here. As your question is about a solution, and not about a specific product issue, I can't really recommend a forum for it.
Thanks
Laurentiu
VipinDuck
It will be hosting a web service (for an internal website) and an internal email service. The clients will be connecting through the internet with a minimum 256k adsl connection. The server is colocated at an ISP.
I wish to know which computer is accessing my server application. Each branch has at most 2 computers (except for the main branch). Thus I will know which branch is requesting the information by the hardware credentials supplied and can filter it appropriately.
Some preliminary research on various .NET forums indicated the hard-drive model and volume serial number to be the most "reliable" identifier of a particular machine.
Thus attackers wanting information from other branches would have to breach those systems as well as knowing the current encryption key. This stops branches sharing their passwords or writing them down in unsecure locations and makes it harder for an attacker outside the organization to gain access (e.g They cant just rummage through the rubbish or bribe someone).
In addition, an attacker from within the organization needs alot more information than just his own serial numbers to gain access to anything worthwhile.
jeremiah3000
Kumona
Warren, why did you post on this forum Your question is not SQL Server related.
You are looking for a DRM type of solution. SQL Server does not provide a solution for DRM.
Thanks
Laurentiu
Shelby Goerlitz - MSFT
If you're connecting to a web service over the internet, why bother with a custom comms encryption approach. If you want to encrypt the traffic on the wire, HTTPS would be much simpler to implement, and the risk of data exposure due to flaws in either the design or implementation of the encryption scheme would be considerably lower. For a web service, you also have the choice of encrypting just the message data rather than the entire comms channel. If you're interested in exploring this, you might want to take a look at the web service security guidance document at http://msdn.microsoft.com/library/en-us/dnpag2/html/wssp.asp.
Unfortunately, that's generally quite easy. Just about any code run on the machine would have access to that information. It could also be retrieved by anyone with physical access to the machine (e.g.: a janitor or someone who steals the physical machine).
If you're concerned about password mismanagement, why not use client certificates (also covered at http://msdn.microsoft.com/library/en-us/dnpag2/html/wssp.asp)
codemare
What's sitting on the server (e.g.:web service, remoting server, database only, etc.), and over what type of network (e.g.: LAN, WAN, internet) will the clients be connecting to it
That depends on your application requirements. Do you need to know who the caller is for any given request
Serial numbers do not involve secrets, so they aren't really suitable for authentication purposes. Also, if you're interested in the identity of the human user, you should keep in mind that humans can use more than one machine, so no property of a machine will reliably serve to identify its human user.
DaveGriffin
Hi Laurentiu,
I did not originally post in this forum, it was in the .NET CLR forum but was moved to this forum after my reply to Nicole. I guessed that the mention of an access database justified moving this thread to this forum by someone.
Can you suggest a forum where this type of question will be answered (and hopefully not shuffled around)