jerra
asked on
Thick client application security (C# <-> SQL Server 2008 Express) .NET 4. Looking for good advice here
"Standard" thick client application.
Existing application, this means that major refactoring will take a lot of time. Application is moving from inhouse solution to product. Making it a 3-tier application is not an option at the moment.
I am not intending to overdo the security bit but I do not want to make really basic mistakes. This software will be located at customer locations and I need a good security architecture that we can stand behind.
SQL statements are currently written in the client code. All statements follows "Prepared Statement" format (named parameters), no string concatenations are made. That should prevent SQL injection.
Here you can get some info on security issued concerning thick clients.
Client/Server Security Assessment and Awareness
Thick Client Application Security
Application has it's own login for the users and uses only one account with the database. Any ideas on this? How do I store database login at the client location? In the resource file?
Other considerations?
Existing application, this means that major refactoring will take a lot of time. Application is moving from inhouse solution to product. Making it a 3-tier application is not an option at the moment.
I am not intending to overdo the security bit but I do not want to make really basic mistakes. This software will be located at customer locations and I need a good security architecture that we can stand behind.
SQL statements are currently written in the client code. All statements follows "Prepared Statement" format (named parameters), no string concatenations are made. That should prevent SQL injection.
Encrypted connection between client and database
Passwords will be hashed in the client and validated at the database
Sensitive information in SQL Server tables will be encrypted using SQL Server's encryption features
Client will check that the user belongs to a certain Active Directory user group
C# assemblies will be obsfucated, encrypted using some software intended for this use. I was looking at Remotesoft's Salamander but that is not an option anymore. Perhaps {smartassembly}
Here you can get some info on security issued concerning thick clients.
Client/Server Security Assessment and Awareness
Thick Client Application Security
Application has it's own login for the users and uses only one account with the database. Any ideas on this? How do I store database login at the client location? In the resource file?
Other considerations?
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
Nevermind, we'll think of some way to bundle SQL Server with our software in these cases where the customer doesn't use AD.
ASKER
I am assuming you mean that this type of architecture then uses SSPI connection type?
Quote: 'I am assuming you mean that this type of architecture then uses SSPI connection type?'
SSPI = integrated = kerberos = Yes! Ofcourse
:-)
Good luck. If you have any more questions, fire away.
//Marten
SSPI = integrated = kerberos = Yes! Ofcourse
:-)
Good luck. If you have any more questions, fire away.
//Marten
ASKER
OK thanks.
When you wrote "deploy your thick application using AD" does it have to be deployed through Group Policy? Can't it be installed normally?
When you wrote "deploy your thick application using AD" does it have to be deployed through Group Policy? Can't it be installed normally?
yea it can, but you are missing the point. the ad group both deployes the app and grants the rights to execute the stored procs. it makes a neat package
\\Maryen
\\Maryen
ASKER
Personally I am not too familiar with AD and how to deploy software using policies but I will pass the information on! Thanks a lot!
ASKER
Ok, with your recommended changes made do you see other obvious security problems?
Just one thought that came to mind. What if the customer doesn't use AD? Just a single computer or two. (argh so much to consider)