I'd like to use Windows.Security.Credentials.PasswordVault in my desktop app (WPF-based) to securely store a user's password. I managed to access this Windows 10 API using this MSDN article.
I did some experiments and it appears that any data written to PasswordVault from one desktop app (not a native UWP app) can be read from any other desktop app. Even packaging my desktop app with Desktop Bridge technology and thus having a Package Identity does not fix this vulnerability.
Any ideas how to fix that and be able storing the app's data secure from other apps?
UPDATE: It appeared that PasswordVault adds no extra security over DPAPI. The case is closed with a negative result.
(this is from what I can understand of your post)
There is no real way of preventing data access between desktop apps when using these kind of API's http://www.hanselman.com/blog/SavingAndRetrievingBrowserAndOtherPasswords.aspx tells more about it. You'd probably just want to decrypt your information.
memory access restriction is difficult, code executed by the user is always retrievable by the user so it would be difficult to restrict this.
have you considered using the Windows Data Protection API :
https://msdn.microsoft.com/en-us/library/ms995355.aspx
grabbed straight from the source
DPAPI is an easy-to-use service that will benefit developers who must provide protection for sensitive application data, such as passwords and private keys
WDPAPI uses keys generated by the operating system and Triple DES to encrypt/decrypt your data. Which means your application doesn't have to generate these keys, which is always nice.
You could also use the Rfc2898DeriveBytes class, this uses a pseudo-random number generator to decrypt your password. It's safer than most decrypters since there is no practical way to go back from the result back to the password. This is only really useful for verifying the input password and not retrieving it back again. I have never actually used this myself so I would not be able to help you.
https://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes(v=vs.110).aspx
see also this post which gives a way better explanation than I can.
How to securely save username/password (local)?
If I misunderstood the question in some way, tell me, I will try to update the answer.
NOTE that modern/metro apps do not have this problem, although they still are accessible in other ways.
The hard truth is that storing a password in a desktop application, 100% securely is simply not possible. However, you can get close to 100%.
Regarding your original approach, PasswordVault uses the Credential Locker service which is built into windows to securely store data. Credential Locker is bound to the user's profile. Therefore, storing your data via PasswordVault is essentially equivalent to the master password approach to protecting data, which I talk about in detail further down. Only difference is that the master password in that case is the user's credentials. This allows applications running during the user's session to access the data.
Note: To be clear, I'm strictly talking about storing it in a way that allows you access to the plain text. That is to say, storing it in an encrypted database of any sort, or encrypting it yourself and storing the ciphertext somewhere. This kind of functionality is necessary in programs like password managers, but not in programs that just require some sort of authentication. If this is not a necessity then I strongly recommend hashing the password, ideally per the instructions laid out in this answer by zaph. (Some more information in this excellent post by Thomas Pornin).
If it is a necessity, things get a bit more complicated: If you want to prevent other programs (or users I suppose) from being able to view the plaintext password, then your only real option is to encrypt it. Storing the ciphertext within PasswordVault is optional since, if you use good encryption, your only weak point is someone discovering your key. Therefore the ciphertext itself can be stored anywhere. That brings us to the key itself.
Depending on how many passwords you're actually trying to store for each program instance, you might not have to worry about generating and securely storing a key at all. If you want to store multiple passwords, then you can simply ask the user to input one master password, perform some salting and hashing on that, and use the result as the encryption key for all other passwords. When it is time for decryption, then ask the user to input it again. If you are storing multiple passwords then I strongly urge you to go with this approach. It is the most secure approach possible. For the rest of my post however, I will roll with the assumption that this is not a viable option.
First off I urge you not to have the same key for every installation. Create a new one for every instance of your program, based on securely generated random data. Resist the temptation to "avoid having to store the key" by having it be generated on the fly every time it is needed, based on information about the system. That is just as secure as hardcoding string superSecretKey = "12345"; into your program. It won't take attackers long to figure out the process.
Now, storing it is the real tricky part. A general rule of infosec is the following:
Nothing is secure once you have physical access
So, ideally, nobody would. Storing the encryption keys on a properly secured remote server minimizes the chances of it being recovered by attackers. Entire books have been written regarding server-side security, so I will not discuss this here.
Another good option is to use an HSM (Hardware Security Module). These nifty little devices are built for the job. Accessing the keys stored in an HSM is pretty much impossible. However, this option is only viable if you know for sure that every user's computer has one of these, such as in an enterprise environment.
.Net provides a solution of sorts, via the configuration system. You can store your key in an encrypted section of your app.config. This is often used for protecting connection strings. There are plenty of resources out there on how to do this. I recommend this fantastic blog post, which will tell you most of what you need to know.
The reason I said earlier not to go with simply generating the key on the fly is because, like storing it as a variable in your code, you rely exclusively on obfuscation to keep it secure. The thing about this approach is that it usually doesn't. However, sometimes you have no other option. Enter White Box cryptography.
White box cryptography is essentially obfuscation taken to the extreme. It is meant to be effective even in a white-box scenario, where the attacker both has access to and can modify the bytecode. It is the epitome of security through obscurity. As opposed to mere constant hiding (infosec speak for the string superSecretKey approach) or generating the key when it is needed, white box cryptography essentially relies on generating the cipher itself on the fly.
Entire papers have been written on it, It is difficult to pull off writing a proper implementation, and your mileage may vary. You should only consider this if you really really really want to do this as securely as possible.
Obfuscation however is still obfuscation. All it can really do is slow the attackers down. The final solution I have to offer might seem backwards, but it works: Do not hide the encryption key digitally. Hide it physically. Have the user insert a usb drive when it is time for encryption, (securely) generate a random key, then write it to the usb drive. Then, whenever it is time for decryption, the user only has to put the drive back in, and your program reads the key off that.
This is a bit similar to the master password approach, in that it leaves it up to the user to keep the key safe. However, it has some notable advantages. For instance, this approach allows for a massive encryption key. A key that can fit in a mere 1 megabyte file can take literally billions of years to break via a brute force attack. Plus, if the key ever gets discovered, the user has only themselves to blame.
In summary, see if you can avoid having to store an encryption key. If you can't, avoid storing it locally at all costs. Otherwise, your only option is to make it as hard for hackers to figure it out as possible. No matter how you choose to do that, make sure that every key is different, so even if attackers do find one, the other users' keys are safe.
Only alternative is to encrypt password with your own private key stored somewhere in your code. (Someone can easily disassemble your code and get the key) and then store encrypted password inside PasswordVault, however the only security you have is any app will not have access to password.
This is dual security, in case of compromised machines, attacker can get access to PasswordVault but not your password as they will need one more private key to decrypt the password and that will be hidden somewhere in your code.
To make it more secure, if you leave your private key on your server and expose an API to encrypt and decrypt password before storing in Vault, will make it most secure. I think this is the reason people have moved on to OAuth (storing OAuth token in PasswordVault) etc rather then storing password in vault.
Ideally, I would recommend not storing password, instead get some token from server and save it and use that token for authentication. And store that token in PasswordVault.
It is always possible to push the security, with miscellaneous encryption and storage strategies. Making something harder is only making the data retrieval longer, never impossible. Hence you need to consider the most appropriate level of protection considering execution cost x time (human and machine) and development cost x time aspects.
If I consider strictly your request, I would simply add a layer (class, interface) to cipher your passwords. Best with asymmetrical encryption (and not RSA). Supposing the other softs are not accessing your program data (program, files OR process), this is sufficient. You can use SSH.NET (https://github.com/sshnet/SSH.NET) to achieve this quickly.
If you would like to push the security and give a certain level of protection against binary reverse-engineering (including the private key retrieval), I recommend a small (process limited) encrypted VM (like Docker, https://blogs.msdn.microsoft.com/mvpawardprogram/2015/12/15/getting-started-with-net-and-docker/) based solution such as Denuvo (https://www.denuvo.com/). The encryption is unique per customer and machine based. You'll have to encapsulated you c# program into a c/c++ program (which acts like a container) that will do all the in-memory ciphering-deciphering.
You can implement your own strategy, depending on the kind of investment and warranty you require.
In case your program is a backend program, you can pick the best strategy (the only I really recommend) of all which is to store the private key at the client side, public key at backend side and have local deciphering, all transmitted password would be hence encrypted. I would like to remark that password and keys are actually different strategies to achieve the same goal: checking if the program talks to the right person without knowing the person's identity; I mean this: instead of storing passwords, better store directly public keys.
Revisiting this rather helpful issue and adding a bit of additional information which might be helpful.
My task was to extend a Win32 application that uses passwords to authenticate with an online service with a "save password" functionality. The idea was to protect the password using Windows Hello (UserConsentVerifier). I was under the impression that Windows surely has something comparable to the macOS keychain.
If you use the Windows Credential Manager APIs (CredReadA, CredWriteA), another application can simply enumerate the credentials and if it knows what to look for (the target name), it will be able to read the credential.
I also explored using DPAPI where you are in charge of storing the encrypted blob yourself, typically in a file. Again, there seems to be no way (except obfuscation) to prevent another application from finding and reading that file. Supplying additional entropy to CryptProtectData and CryptUnprotectData again poses the question of where to store the entropy (typically I assume it would be hard-coded and perhaps obfuscated in the application: this is security by obscurity).
As it turns out, neither DPAPI (CryptProtectData, CryptUnprotectData) nor Windows Credential Manager APIs (CredRead, CredWrite) can prevent another application running under the same user from reading a secret.
What I was actually looking for was something like the macOS keychain, which allows applications to store secrets, define ACLs on those secrets, enforce biometric authentication on accessing the secret, and critically, prevents other applications from reading the secrets.
As it turns out, Windows has a PasswordVault which claims to isolate apps from each other, but its only available to UWP apps:
Represents a Credential Locker of credentials. The contents of the locker are specific to the app or service. Apps and services don't have access to credentials associated with other apps or services.
Is there a way for a Win32 Desktop application to access this functionality? I realize that if a user can be brought to install and run a random app, that app could probably mimic the original application and just prompt the user to enter the secret, but still, it's a little disappointing that there is no app-level separation by default.
Related
My situation is as follows:
I have to deploy a series of .NET desktop applications consisting of a file with encrypted data and an executable that will access that data and decrypt some parts of it in runtime.
What I need to achieve is that each data container should only be decryptable by that specific .exe it is provided with.
The first idea was to encrypt the data using, say, the hash value of the .exe file as a symmetric key and during decryption calculate the hash value of the .exe file in runtime and decrypt the parts of the data container with it.
However, the problem with that approach is that the user can easily look into the .NET assembly with ILSpy or any other decompiler and discover the whole encryption algorithm which will enable the user to decrypt all the data containers in my series of applications.
Another solution that comes to my mind is to make a small C native library (that is less easy to decomplile) that will perform some manipulations with the .exe assembly information and generate a key for decryption based on it (let's consider the user lazy enough so that he will not try to intercept the key from the memory).
But ideally I wouldn't like to resort to any languages other than C# because porting the application to other platforms with Mono will require additional effort (P/Invokes and so).
So my question is: is there a way I can encrypt the data so that only a certain application would be able to decrypt it?
Of course I understand that in case of a local application it is impossible to keep the data absolutely secure but I need to make the 'hacking' at least not worth the effort. Are there any reasonable solutions or I will have to stick to one of my ideas I described above?
Thank you in advance!
The simple answer is no.
To encrypt and decrypt data, you need an algorithm and, optionally, a secret or key. If a computer can execute the algorithm, someone else can learn what it is. Ignoring decompilation and disassembly, a user could just look at the instructions executed by the CPU and piece together the algorithm.
This leaves the secret. Unfortunately, if the computer or program can access or derive a secret, so can someone with root or administrator rights on that computer for the same reasons above.
However, maybe you are just thinking about the problem the wrong way. If you want the program to access data that no one else can, consider making that data available from a server that users must authenticate to access. Use SSL so data is protected in transit and encrypt the data locally using a key that only the local user and local administrators can access. It is not perfect but it is about the best you are going to get in the general case.
If you need more protection than that, you may want to consider hardware dongles but this gets expensive and complex quite quickly.
I need to store encryption/decryption keys for an encryption algorithm, on a public WPF application, available as free download to anyone.
Obviously, I would like to store these keys in secure way, so that the user may not see them.
As I see it, it's not possible, since it's very easy to decompile a .Net app, and obfuscating it doesn't do much. I can't think of a place to store these infos, that is either not user-accessible, or is "naturally" encrypted (like some kind of "Windows vault", but then the user could create an application pretending to be my own, wouldn't he?)
From the moment the user has access to the (compiled) code and the (clear) app.config, I don't see how I can store sensitive informations locally.
I saw plenty of help to encode connection strings and securing stuff on IIS, but none on WPF applications.
Is there any way to securely store arbitrary data with .Net/WPF?
Thanks!
Do not put it in the app - 'anyone' can get to it.
Store the secrets (private keys) in a certificate store so only processes with the appropriate rights will have access. Make installing the private keys part of a separate process/setup so admins can do that apart from installing the application and have the application search/query the certificate store
Simple: You do not.
NO way to do that ever has worked. None. Ever. All copy protections that get cracked within days are based on "hey, I can hide something".
You can safely store user specific data in the user's specific folders - and leave it to the OS to protect these places. But thinking you can hide encryption keys in your app - basically: you can hide them if noone smart looks at them (or: no dedicated hacker). This may work - but it is "relying on people not really wanting to find it".
As soon as information is stored on the user's machine, you have to assume he can access it; there's no way around it. The only option, if you want to make it impossible for the user to access the key, is to do the encryption on a remote server, but it's not always a viable option if the data to encrypt is large.
I'm looking for a way to securely store an API key in a WP7 application. The key is a string and is currently hard coded into the code (see below). I know that someone with a reflector program could easily view this. Is there a better way to package this key as part of my app? Would a resource be more secure?
string key = "DSVvjankjnersnkaecjnDFSD44VDS23423423rcsedzcadERVSDRFWESDVTsdt";
Thank you in advance.
Have a look at Safeguard Database Connection Strings and Other Sensitive Settings in Your Code, it is a good read. Your question is under the "Hiding Keys in the Application Source Code" section.
Excerpt:
If you define the key in the application, in addition to obfuscating the assembly, try not to store the actual key bytes in the source code. Instead, implement key-generation logic using persistent characteristics, such as the encryption algorithm, key size, pass phrase, initialization vector, and salt (see an example at Encrypt and Decrypt Data Using a Symmetric (Rijndael) Key). This will introduce an extra layer of indirection, so the key will not be accessible by simply dumping the symbols from the application binary. As long as you do not change key-generation logic and key characteristics, the resulting key is guaranteed to be the same. It may also be a good idea not to use static strings as key-generation characteristics, but rather build them on the fly. Another suggestion would be to treat the assembly the same way as the data store should be treated, that is, by applying the appropriate ACLs. And only use this option as a last resort, when none of the other data protection techniques work and your only alternative is leaving sensitive data unencrypted.
I've read through all these answers, and I don't think there is any way you can securely embed this - regardless of where you put it, or how you obfuscate it. As long as its in your XAP and decoded within the application then it will always be available to hacking.
If you need to ship the key inside the xap with a reasonable degree of protection, then I think #maka's answer yields your best bet - obfuscate it as best you can - but don't think this will make you secure - i.e. don't do this for your mobile banking apps!
Alternatively, if you really need security then don't operate solely within the app - use a web server as well. For example, if you were doing a Facebook app and needed to somehow protect your facebook secret key, then you would need to redirect the user from your app to a web page on your server for authentication. That web page would then need to guide the user through the process of getting an access token - and then just that access token (along with the public appid) would need to go back to your app. And for those webservices which require knowledge of the secret key to accompany every call, then I'm afraid every single call will probably need to go via your server.
You can encrypt Api key with ProtectedData and then decrypt it in runtime. This is good tutorial how to encrypt data in Windows Phone: Encryption in Mango
May be you can encrypt it before hand and save it in app.config. And while reading it decrypt it using the same algorithm.
You could use DotFuscator to disable the ability to use reflector.
But, this will not allow you to change the key without recompiling.
In the past I've used the following method in other (web/winform-based) software:
http://weblogs.asp.net/jgalloway/archive/2008/04/13/encrypting-passwords-in-a-net-app-config-file.aspx
It's not an answer maybe, but sure it's a suggestion:
Store encrpyted key in a db. And store encrypted "db password" in app.config.
Use two proper string encrypt/decrypt algorithm, let's say algorithm x and y.
Put encrypted db password in app.config before to publish it.
Decypt app.config password(algo y) to connect the db for taking new encrpyted string(real one).
Close the connection and decyrpt new string with algorithm x if reflector/etc. not running.
Use it.
Dispose the object that holds the string.
My application makes use of the RijndaelManaged class to encrypt data. As a part of this encryption, I use a SecureString object loaded with a password which get's get converted to a byte array and loaded into the RajindaelManaged object's Key at runtime.
The question I have is the storage of this SecureString. A user entered password can be entered at run-time, and that can be "securely" loaded into a SecureString object, but if no user entered password is given, then I need to default to something.
So ultimately the quesiton comes down to:
If I have to have some known string or byte array to load into a SecureString object each time my application runs, how do I do that? The "encrypted" data ultimately gets decrypted by another application, so even if no user entered password is specified, I still need the data to be encrypted while it goes from one app to another. This means I can't have the default password be random, because the other app wouldn't be able to properly decrypt it.
One possible solution I'm thinking is to create a dll which only spits out a single passphrase, then I use that passphrase and run it through a couple of different hashing/reorganizing functions at runtime before I ultimately feed it into the secureString object. Would this be secure enough?
Edit For clarity*: The encrypted data is being passed via files between machines. Think of it as a Zip file which always has a password, a default one is assumed if nothing is directly entered by the user.
There is no point in symmetrically encrypting with a string that's hard-coded into your executable. It will only give a false sense of security. No amount of hashing fixes this scheme.
See this Pidgin FAQ for the same point in a different context.
I am unclear why you think you need the inter-app communication to be encrypted. If this communication is local to the machine, then I don't see the need for encryption, particularly encryption that isn't user-specific. Is this a DRM scheme?
EDIT: If it's being passed to a different machine, perhaps you can hard-code a public key, and then have the other machine decrypt with the matching private key.
Let me tackle your final question first.
"Would this be secure enough?"
The only one that can answer that is you. Nobody here knows what "secure enough" means in the context of your application.
Are you building an application to keep the diary of teenage girls? Sure, it would be "secure enough".
Are you building an application to encrypt information or authentication for military grade secure systems? Nope, not even close.
You can only rely on one type of security if you intend to store the password in your source code and thus executable, and that is security by obscurity.
If your problem is that you can't, or won't, store the password in the source code, then moving it into a separate dll solves nothing, you've just moved the problem to a different project.
However, I'm wondering about something. You say "I have to default to something". Is that it? You're trying to store a default value for the secure password string in the source code? How about "THISISNOTAPASSWORD"?
Eric Lippert's You Want Salt With That? (original blog post)
Also read his post to Use the right tool for the job where he ends with the following tips:
If you possibly can, simply don’t go there. Encryption is extremely difficult to get right and is frequently the wrong solution in the first place. Use other techniques to solve your security problems.
If the problem is an untrustworthy client then don’t build a security solution which requires trusting the client.
If you can use off-the-shelf parts then do so.
If you cannot use off-the-shelf-parts and do have to use a cryptosystem then don’t use a cryptosystem that you don’t fully understand.
If you have to use a cryptosystem that you don’t fully understand, then at least don’t use it to solve problems it was not designed to solve.
If you have to use a cryptosystem to ski through the trees, then at least don’t allow the presumably hostile client to choose the message which is encrypted. Choose the token yourself. If the token must include information from the client then sanitize it in some way; require it to be only straight ASCII text, insert random whitespace, and so on.
If you have to allow the client to choose the token, then don’t encrypt the token itself. Sign a cryptographically-secure hash of the token. Its much harder for the attacker to choose a token which produces a desired hash.
Don’t use the same key pair for encrypting outgoing messages as you do for protecting incoming messages. Get a key pair for each logically different operation you're going to perform.
Encrypt the communications both ways.
Consider having a revocation mechanism, so that once you know that Eve is attacking you, you can at least revoke her license. (Or you can revoke a known-to-be compromised license, and so on.)
This article on securing SQL connection strings should be just as applicable for storing encrypted passwords, where you let the OS handle the encryption of the salting seed for your decryption.
It sounds to me like perhaps you should be using a PKI solution instead of encryption/decryption. If you have another application that needs to consume the encrypted data, then you could have a key pair for that application, and give the public key to the app that is doing the encryption. That way you are still keeping your data secure, but not introducing a bunch of additional code that ultimately doesn't give all that much protection.
A quick google search gave me this Code Project article that talks about using the Windows Certificate Store in .Net
I am about to sell a program I have written in C# and I want to control licenses for it, strictly. That means I want to let the client connect to my server every single time it starts. This also gives me the ability to disable keys (in case of chargebacks on paypal or distribution of the code). Of course this might be a hassle for other users, but it is necessary in this case.
Since I was unable to find any good .NET Licensing systems that are uncracked, I wanted to take the approach of writing a little one myself.
My plan was to do the following:
Generate a key.dat containing 1024 characters that gets shipped with the software (individual to each user)
In the application entrypoint add a httprequest to my server that sends the key.dat + current timestamp, encrypted.
My HTTP server (running PHP) decrypts the request and checks if the key is valid (in my database) and replies with the "access level" (license type). If the key is invalid or disabled it replies with an errorcode. Just like with the request, the reply is being salted with a timestamp, so someone can't validate his program by sending a valid packet to himself. The timestamp is being checked in the client. The reply is encrypted with RSA and a previously generated public key.
Client receives response, decrypts with private key and reacts.
Is RSA the correct approach for this, so I can assure that the packets are sent by me and are not crafted (by noone else having the public key)?
Is there a better approach for solving this problem?
Someone who wants your software bad enough will just decompile it and remove the part of the code that phones home on startup.
If you were to add a checksum to the app that checks whether the code has been altered, someone can just change the checksum the program checks against (or remove the check entirely).
People who want your application enough will find ways around any type of protection you can conceive. You're better off sticking to something simple, having a product that is worth paying for (and easily) and make sure it's worth the price you're asking.
EDIT
Given that protection is important, the fact that the users will have code running on their machines is a risk you can avoid. If the users don't have the code, they can't crack it. They can't copy it and share it.
Now, it might not apply to the application you intend to write, but you should consider writing a web, Flash or Silverlight application instead of a regular client application. That way you don't have to distribute the code to customers. All you have to do is manage credentials into the application, which should be a lot easier than your round-about RSA system.
It's also easier to push out new versions of the software in a centralized model, and you won't have to worry about theft at all. Of course, load will become an issue when it wasn't before. And not all applications can be centralized easily (or at all). I'm just proposing this to make sure you consider it because it is a valid solution to your problem.
A web-based application will have the same issues as your application (i.e. it will be down whenever the user is offline, whenever the network is down, whenever your server is down, etc). So there's no added risk in that regard.
Is RSA the correct approach for this?
I do not think RSA is your best choice.
One of the capabilities of PKE (Public Key Encryption) is that it lets parties talk to each other who previously have never exchanged information before (eg. strangers).
I do not see this applying to your case. Your software knows your server well. They are not "strangers".
Consider instead Shared Secret Key encryption, where each copy of the software you distribute is given a unique secret key, and your server knows each user's secret key as well. The keys are never sent, and must be protected, but can still be used to encrypt, sign, and validate communications.
Edit After considering the comments and other answers.
Anyone who wants your software badly enough will be able to bypass the authentication completely. RSA does nothing to prevent that.
The real question is: Does breaking a single license make all licenses vulnerable/worthless. In both cases, (RSA and Secret Key), the answer is No. Just because one copy of the software got hacked and got its key exposed, or the licenses system bypassed, other copies are no more exposed. PKE and SSE seem equal in that respect to me.
Because Shared Secret Key is easier to implement, and computationally faster to execute, I think it is preferred in this case over RSA/PKE. That is not to say RSA is "wrong". It will accomplish what you are after, to the same degree that SSE will (no more, no less). But I think SSE is the smarter choice.