I understand this might be a repeat of this question: How to encrypt data in sql server and decrypt it in .net apps
- But this was asked almost a year ago and I'm hoping there might have been advancements or something.
Anyways, we have an application that FTPs files from one location to another and obviously the FTP profile needs a password. We have a database with all the details of the profiles, but we need the passwords to be encrypted. We've thought of decrypting them in SQL then sending them to the app, but that would mean sending it over the network, which we don't want.
We want to encrypt the stored passwords, pass the details to the application, then decrypt them within the application.
Is this possible?
From my googling, it doesn't seem it is, but I'm hoping someone has a trick or something.
Thanks in advance!
Note: I'm using .Net 4 and SQL Server 2008 R2.
Encryption and Decryption using SQL Server column crypto API functions (like EncryptByKey) is not compatible with any client side encryption or decryption because it uses an internal, undocumented, storage format.
I would call out that your fear about sending passwords over the network are not founded, since SQL Server provides network connection confidentiality, see Encrypting Connections to SQL Server.
Your best options would be to either store the password in an encrypted column and use the built-in SQL Server crypto functions (EncryptByKey, DecryptbyKey) or use Transparent Database Encryption. the criteria too choose one or the other is mostly the licensing requirement (TDE requires Enterprise Edition) since TDE is superior to column level encryption in every aspect. No matter what solution you choose, you'll quickly realize that the main problem is key management, and for that SQL Server offers a viable story, see Encryption Hierarchy. No matter how you design the solution, there is never any need for the application to encrypt or decrypt the password itself, if you need such then you're clearly down a wrong path (since the application cannot manage the keys itself), so the issue of CLR crypto and SQL crypto compatibility should never arise.
Simpy encrypt and decrypt the passwords in .net, as far as SQL is concerned it is just storing text.
Have you thought about SQL Server's Transparent Data Encryption (TDE)?
It seems to me that "the obvious answer" is that you need to use the same algorithm (or the appropriate matching encrypt/decrypt pair) in both the SQL server and dotNet. Because the former uses T-SQL and the latter a managed code language like C#/VB you would have to write/source the two halves of the algorithm in different languages. Yuk.
Have you thought about using SQL CLR? That way you could write both halves in, say, C# and run that code from SQL.
I've had a copy of this sitting on my shelf for a while but never delved too deep into it - mainly because, whilst very cool in principal - I've never found a 'need' to use SQLCLR. Your problem however sounds like a strong candidate :-)
HTH :-)
Damien
Related
What native technology exists to encrypt/decrypt a string in the database for reading into a single application?
Scenario:
I have a set of connection strings that I need to use to securely access a set of production servers, for a polling application. I would like to store those in a table in a database and pull them out as I need them via a service. That will give me the ability for a handful of users (with permissions) to edit/add those entries.
My target audience using this application are all developers, these are servers to monitor our production and staging environments for some specific SQL flaws that I may need to later fix. This is a devops application.
Knowing that my target audience is developers, and that these are production servers, I would like to "lock the door" to keep people from actively seeing the production passwords/useraccounts unless they need them (auditing purposes). I realize that a lock is only as good as the frame around the door, and is only to keep honest people and petty thieves out, and that anyone dedicated will eventually be able to get past whatever safeguards I try to set.
Problem:
What technology in C# exists to secure this information and still allow me to dynamically add/alter connection strings but still keeps the data in the database reasonably secure? I am willing to make some changes to a machine.config or the like, but I need to actively develop the application too, so would like if it could be done in either machine.config1 or web.config, to allow for local development before deployment to the devops servers.
I understand that some of my alternative suggestions are:
Use strong database passwords to keep people out
Use strong schema organization to keep people out
Trust the developers, they work for your org (see "audit trail". I need to make some stab at securing production credentials)
Don't let people have access to the server and store them in the web.config (already plan on this in the first place)
Ideally:
Ideally I would just use a private key for encryption/decryption on the application server, but I don't exactly know the most secure way to do this, other than base64. I know this is not encryption.
What technology exists in the .NET native stack to securely encrypt/decrypt a string that may contain special characters in a single application and what is an example usage of this technology?
If I knew a name and technique, I would not be asking this question.
1 using machine.config/web.config to indicate something inherent in the .NET stack. I'm open to any suggestions.
Saving connection information in a database table is going to be unsecure, always. At some point, you're going to have to decrypt the password, and send it to the server. Developers tend to be smart enough to figure out any "security by obscurity" approach, and get to the passwords at some point. Even if you encrypt the password in the DB (not too hard), as long as you pass it to the SqlConnection at some point, you still have to decrypt it somewhere on the user (developer) end.
Rather, the only way to do this securely, is to make sure the password actually never gets anywhere close to the developers (or anyone else). There's a few ways to handle this:
Use an external security provider, such as Windows authentication. This means you don't have to use any username or password at all.
Create some kind of a tunnel to send any required SQL. This is very easy if your developers only ever need to run SQL commands, and a bit trickier if they want to use productivity tools like Management Studio; however, even that's doable - SQL can run fine over TCP, and you should be able to emulate that quite easily. Only the tunneling server would have access to the actual credentials, your developers would only have credentials to the tunneling server (and limited ones at that).
Use the Linked servers feature. This allows you to link local users (your devs) to remote users (su on the target server or whatever). It should work just fine with all the usual security settings.
Out of these, I'd say linked servers might be the best. They're quite easy to use, they can be administrated by the select few, and they don't publish the password at all. You can also do queries that span servers this way - very handy for a maintenance tool :)
Windows authentication is incredibly useful, but usually only on LAN, since we're talking about having all the DB servers in a domain. VPN could help, but that's getting into complicated territory.
Using a tunnel isn't necessarily a bad idea, although I assume you'll run into a few issues before you get it working 100%. And in the end, that's what Linked servers do for you for free, so why not use that?
Now, if you really do want to go through with the encryption idea instead, you can pick from a plenty of .NET supported encryption schemes. AES should work fine - it's assymetrical, so knowing the encryption key doesn't mean you can decrypt the data (the decryption / private key should only be stored in a secure location and on the maintenance application server, in a place noone but the application itself can reach; do note that admins can reach anything, so if your people have administrator rights, this isn't going to work).
For an example, see the AesManaged class in System.Security.Cryptography - http://msdn.microsoft.com/en-us/library/system.security.cryptography.aesmanaged(v=vs.110).aspx
Most applications only need one database, but you can use the Manager to create as many as you need. Multiple databases are independent of each other. If your application supports switching between multiple users, each with their own separate content and settings, you should consider using a database for each user. Otherwise, it's usually best to stick with one database.
I have just started developing a desktop application using C# and SQlite database (with sensitive information) that will be installed on any PC locally. I would like to store the database password and the sql commands somewhere safe. I have a some questions about this:
How much do you think is the SQlite database secure? I have read
that by adding the encryption the whole file is encrypted, even the
header. By How much do you think it is secure?
To store the password, there are a lot of choices (and some are maybe simple suggestions that I was thinking of):
a) Storing the password and the SQL commands in a dll file and obfuscating it. But has anyone tried before to crack this or searched for it using Olly Debugger for example?
b) Encrypting it in the app.config file, custom encryption. But I've read a couple a articles and the encrypting connection string seems to be crackable...
c) Putting the password in an XML file and encrypting it or maybe in a serialized file (But the encrypting will also be stored in a the source code and can be refracted).
If the application has been obfuscated and the database encrypted. Do you think there will be any performance issues?
Thank you.
You need to ask yourself what is it exactly that you are trying to protect against and what for. Anything you can do in a purely client-installed application, especially a managed one, can be cracked quite easily. Dongles are more crack-proof, but will not stop an experienced cracker if the payoff is large enough, and they are both expensive and a pain in the ass for users and distributors. The only reliable way to protect your application is to run sensitive parts of it on your own servers. In your case, the database could reside on your server, then you can give out individual passwords, check IP addresses, limit query rates to deter scraping etc.
OTOH if your sole object is to protect your database against casual interest by persons having little technical knowledge, any scheme for database encryption and any scheme for password storage more complicated than plain text in the configuration file will work just fine.
I'm new to C# and ASP.NET and I have to do a project now. It deals with confidential data of a firm's employees so it needs to be encrypted. I am not sure if I will be able to get through with my own encryption algorithm. If I use any existing algorithms, they said that I should find a foolproof way to store the key.
To be honest, I don't really understand the term "key" in encryption. I would like someone to brief about it and help me with how I should move forward with this project.
http://en.wikipedia.org/wiki/Key_%28cryptography%29
dunno, but maybe start there?
IMHO:
as already advised, don't cobble up your "own", use existing algorithms in the framework that have been tested extensively. Whatever weaknesses they may have will (likely) still be better than what you can cobble up on your own.
understand what needs to be encrypted which pretty much means at some point will need to be decrypted vs. data that needs to be hashed (one-way - e.g. passwords).
decide if you want this to happen on the application side or perhaps, if resources are available to you like SQL server (to store data), on the database side (discuss this with your DBA). You can do both encryption and hashing in SQL server alone.
on the application side, you can think about storing keys in your web.config and subsequently encrypting that section - just like the option to do so for your db connection strings (encrypting the connection section of web.config). This way even your keys aren't in plain text.
The first rule of cryptography - never use your own algorithm, unless you are a Ph.D. and several other Ph.D's are helping you, even then, use only after public auditing.
What they mean about storing the key is that it shouldn't be exposed anywhere - if an attacker can get the key, they can decrypt all data in the database. Currently, there are no known ways to do this. You can store the key in a file outside the website's root folder - this way either the server itself must be compromised, your app must be compromised (e.g. by making it display the "../../key.txt" file, thus descending below the webroot) or your app must be tricked into encrypting/decrypting the data transparently for the attacker (e.g. by having a bug that allows authentication bypass, thus allowing them to use your app to talk to the database).
For the last part of the question, use #Haxx's answer :)
To be more specific, if I create a symmetric key with a specific KEY_SOURCE and ALGORITHM (as described here), is there any way that I can set up the same key and algorithm in C# so that I can encrypt data in code, but have that data decrypted by the symmetric key in Sql Server?
From the research I've done so far, it seems that the IDENTITY_VALUE for the key is also baked into the cypher text, making things even more complex.
I'm thinking about just trying all the various ways I can think of, ie hashing the KEY_SOURCE using different hash algorithms for a key and trying different ways of encrypting the plain text until I get something that works. Or is that just futile?
Has anyone else done this, any pointers?
UPDATE
Just to clarify, I want to use NHibernate on the client side, but theres a bunch of stored procedures on the database side that still perform decryption.
Are you opposed to encrypting the data in SQL Server?
Not knowing the requirements of your application, from an architectural standpoint I would stick to encrypting & decrypting on the SQL side.
However, I can only speculate that one reason you'd want to do this is that you might not trust the transporation medium between your application & your SQL Server, and you want to encrypt the TSQL going across that channel in case it is intercepted.
If this is the case - I'd suggest looking into SSL HTTP endpoints in SQL Server, as those might be a viable option.
What is the best approach to secure winform data? In other words how to secure the data from hacking for winforms c# projects?
There is a winform project with 25-30 forms. It stores data to the access DB.
If i start writing encryption/decryption logic to all the forms its going to take much time.
Is there any .NET dll/technique which can auto-encnrypt/decrypt before storing DB?
Is there some efficient quick approach for this?
Thanks,
Karthick
As the comments have said, depends on what you're trying to secure.
If you're trying to secure access privileges, you could use Identity and Principals to determine thread based authentication, permissions and roles.
If you're storing sensitive strings in memory, use SecureString instead of a regular stings.
If you are referring to preventing someone from "cracking" your software, employ obfuscation software to hinder any would be attackers.
First you must define what area of security you are looking for, then it's just a matter of doing the research... or asking here!
So if I understand correctly you want the data encrypted when you put it into the database and decrypted when you get it out again?
Firstly it is important to know who you are protecting the data from. Other users of the app? External people that might get access to the physical machine?
you should also probably have your code structured so that all access to the database goes through a single data layer. Perhaps single class or group of classes that do all of the data access code. This would mean that adding encryption and decryption as data goes into and out of your database would not be needed for all of your forms.
On the encryption side of things, you need to determine what you will use as the keys to encrypt your data. The fastest, and probably easiest, way to encrypt the data is with DPAPI through the Protected Data class.
The protected data class would allow you to encrypt the data so that it can only be decrypted on the same machine it was encrypted on, and an aditional value can be given so that only your app or something else that knows the extra value can decrypt it.
Another alternative may be to encrypt the entire database, though I am not sure what support Access has for this. Using the Encrypted File System and File.Encrypt might work if Access does not have anything built in.
These may or may not work for your scenario, it really depends on who you are trying to stop and how long you need to protect the data for.