February 21st, 2014, 02:04 PM
What is the best security strategy for an application with locally encrypted data?
I'm an experienced developer, but I'm new the forums and rather new to the topic of security. I'm developing a local desktop application (C# WPF) that acts like an encrypted journal. I'm imagining when the application first loads up, it asks the user for a password to decrypt all its data. I'd like this application to be secure enough that even if someone got physical access to the hard drive, it would be very challenging to decrypt the data without the password.
I was thinking of using the RijndaelManaged class in C# (Please google it for details - I can't post links)
The user would enter a password, and I would pass it along without ever storing it and attempt to decrypt their data using it. If it works it works, if it doesn't, it doesn't.
First question: How secure is this as an overall approach? Is there a better one I'm missing?
Second question: Where does "salt" come in? Do I need it if I'm not storing passwords?
February 21st, 2014, 02:44 PM
the question is: Why are you doing this?
If this is supposed to be an actual application for real users, I strongly recommend that you don't do it. Cryptography is one of the most difficult areas of all. It sounds really easy at first, and everybody thinks they could do it with a bunch of Wikipedia articles and premade tools. But this is a delusion. In reality, you have no chance of winning unless you have lots and lots of professional experience and a community of experts behind you.
You wouldn't believe how many details and pitfalls you have to take care of. Most of it wouldn't even occur to ordinary mortals like us. So instead of creating yet another failed crypto application, I strongly recommend you use a proven solution like TrueCrypt.
On the other hand, if this is purely for fun, you could of course play with some home-made cryptography. Whether it's secure or not doesn't really matter then.
You're probably confusing two different things.
Originally Posted by jessewatson
If you wanna encrypt or decrypt data using a password, you first need to generate a key from the password. This is called key derivation and involves a random salt. The salt has to be stored so that you're able to preproduce the key.
This has nothing to do with storing the password. The technique is actually very similar, but the goal is obviously totally different.
February 21st, 2014, 04:11 PM
Hi Jaques, thanks for your answer!
"I strongly recommend that you don't do it. Cryptography is one of the most difficult areas .... In reality, you have no chance of winning unless you have lots and lots of professional experience and a community of experts behind you."
Wow! That is quite a statement!
When you ask: "Why do you want to do it?" I'm not sure if you're being rhetorical or not.
I'll assume not and explain my motivations. The reason why something like TrueCrypt would not work is because I didn't mention many other aspects of the application... It is much more than just an encrypted journal, it is a guided, interactive process for people in recovery from addiction who want additional support and guidance through the recovery process. It interacts with them, gathering information about their recovery, and along the way, they record their reflections on their healing process -- the application needs a secure way of storing their information.
In the recovery world, there are lots of horror stories of spouses (or recent ex-spouses) reading journals and freaking out because they're reading words not meant for them. Sometimes these spouses are pretty determined to get at the data, and I can imagine a scenario where they might minimally try reading the underlying file system using notepad, or in extreme cases, even hiring an amateur programmer or IT person to get at the data -- this is extremely unlikely, but could happen. That said, I'm not talking about the FBI getting a hold of the hard drive or something. The financial resources of an upset spouse in a situation like this are probably pretty limited.
So this is where the requirement for encryption comes from. This isn't a "crypto application", it is an addiction recovery tool with encryption requirements. Furthermore, I don't think it has quite the same level of security requirements as someone who might be investigated by the feds. It needs to be non-trivial to break into, but not impossible.
I would like to think that if something like TrueCrypt exists, libraries exist which can be OEM'd for use in an application like this?
As for your second answer, thank you for that -- that helps to clarify how I might use salt. Would you recommend using something like the user's birth day for salt, or generating random salt and saving it at the time the password is generated?
Also, something else I don't understand about salt -- if I save the salt, wouldn't it would need to be saved separately from the data it is being used to encrypt? If so, what is the point? If it is saved, it would be sitting right on the hard drive for an attacker to use. The thing I don't understand about salt is where to put it that doesn't make it irrelevant. Any thoughts?
February 21st, 2014, 10:47 PM
The salt doesn't have to be kept secure, knowing it won't let the user decrypt the data. The salt is used to prevent the same password from generating the same encryption key each time. Just like how you use a salt to prevent the same password from generating the same hash when storing passwords in a web app.
Originally Posted by jessewatson
For an average-joe target audience, using a good algorithm with a decent sized key would probably be "good enough". The most likely attempts people would make to access the content would be trying to get the password either through social engineering, guessing, or using key logging software/hardware.
Other possible attacks would involve trying to intercept the password and/or key after they have been entered. Waiting til the data is decrypted then trying to access it that way, etc. As mentioned for true security there is a lot to be considered. Some of it is stuff you need to consider and handle, some of it is stuff your customers would need to consider and handle.
Comments on this post
Recycle your old CD's, don't just trash them
If I helped you out, show some love with some reputation, or tip with Bitcoins to 1N645HfYf63UbcvxajLKiSKpYHAq2Zxud
February 22nd, 2014, 01:41 AM
I find this somewhat contradictory. You have no experience with cryptography or security in general, which is perfectly fine. Yet at the same time you make all kinds of statements about attack scenarios, the abilities of attackers and the strength of cryptography. How do you know that? How do you decide that your software is “good enough”?
In my experience, people who are new to security totally underestimate the abilities of attackers and overestimate the quality of their products. What you think is “very unlikely” can be done by average people using average PCs. And what you think is “good enough” often turns out to be entirely broken.
There's no such thing as halfway cryptography. There's actual cryptography which can be used to protect sensitive data. And there's fun cryptography which can be used for entertainment and education. That's it. There's no “cryptography which is good enough against your spouse but not necessarily against the FBI”. What this means is that you're misusing fun cryptography for actual data.
I think you're looking at this from the wrong angle. Instead of speculating about what average people can and cannot break, you should ask yourself this: How important is the data? Is it not really important? Then forget about cryptography. Is the data very important? Then you need real cryptography which actually works. This rules out the option of doing it yourself.
This may sound strange, but bad security is worse than no security at all. It's perfectly fine to store plaintext data and tell your users they have to take care of the encryption themselves. They'll act accordingly. It's also fine to promise security if you're actually an expert with a lot of experience and a big community to peer-review your work. But making security promises you cannot keep is deception, even if you have the best intentions. Your users will make bad decisions based on the false assumption that they're secure.
So my honest advice is: Don't do it. Don't be the one who's responsible for people losing highly sensitive data. Leave out the crypto stuff and let your users take care of this.
Comments on this post
February 26th, 2014, 10:09 AM
Thanks Kicken, that's the info I was looking for!
Comments on this post
February 26th, 2014, 10:21 AM
Of course. I didn't really expect anything else.
As long as it makes you feel good, I guess you're happy with it. Looks like cryptography is the new homeopathy now.
Last edited by Jacques1; February 26th, 2014 at 10:23 AM.