I want to pass information to athenticate a user to an XBAP application running in a browser. It's a username and password, where the password is hashed.
I've figured out how to do it via GET request (i.e. just pass in the information in a query string and use BrowserInteropHelper.Source.Query to get the information).
However that means exposing the data in the query string. Since the password is hashed it's not like you can actually see it, but it feels like bad practice to me. I can't find any real information about whether it's possible to pass data in via POST or a cookie. From what I've gathered from the internet cookies won't work for XBAP applications, but I might be wrong.
Does anyone know if and how it's possible to transfer this kind of data in a more secure way? It would also be nice to get a confirmation that cookies indeed won't work in this scenario - or how I need to go ahead and implement them.
From what I could gather from various sources on the internet, GET really is the only way to go in this scenario.
POST doesn't seem to work at all. Also, XBAPs cannot access any session cookies, so that option is not feasible as well.
(I would link to the sources, but it was more about collecting bits and pieces from everywhere and putting it together.)
We settled on passing the parameters via GET, but encrypting the whole query string. This is not an ideal solution, but it has to do until we have the resources to implement a more complex and prettier solution which enables sharing authentication details between two completely separate applications - where one is a Java application and the other an XBAP.
Related
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.
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.
Lets say my program is an Anti-Virus.
Lets also say I have a file, called "Signatures.dat". It contains a list of viruses to scan.
I would like to encrypt that file in a way that it can be opened my by anti-virus on any computer but the users wont able to see the content of that file.
How would I accomplish that task ?
I was looking at thigs like DPAPI, but I dont think that would work in my case because it's based on User's setting. I need my solution to be universal.
I've got a method to encrypt it, but then I am not sure how to store the keys.
I know that storing it in my code is really unsecure, so I am really not sure what to do at this point.
You want the computers of the users to be able to read the file, and you want the computers of the users to be unable to read the file. As you see, this is a contradiction, and it cannot be solved.
What you are implementing is basically a DRM scheme. Short of using TPM (no, that doesn't work in reality, don't even think about it), you simply cannot make it secure. You can just use obfuscation to make it as difficult as possible to reverse-engineer it and retrieve the key. You can store parts of the key on a server and retrieve it online (basically doing what EA did with their games) etc., but you probably will only make your product difficult to use for legitimate users, and anyone who really wants to will still be able to get the key, and thus the file.
In your example are you trying to verify the integrity of the file (to ensure it hasn't been modified), or hide the contents?
If you are trying to hide the contents then as has been stated ultimately you can't.
If you want to verify the file hasn't been modified than you can do this via hashes. You don't appear to have confused the two use-cases but sometimes people assume you use encryption to ensure a file hasn't been tampered with.
Your best bet might be to use both methods - encrypt the file to deter casual browsers, but know that this is not really going to deter anyone with enough time. Then verify the hash of the file with your server (use https, and ensure you validate the certificates thumbprints). This will ensure the file hasn't been modified even if someone has cracked your encryption.
So I have inherited this project and it has around 20 forms, hundreds of controls, and many tens of thousands of lines of code. I've been working on it for a while and now my boss is requesting the addition of user accounts.
Basically, there would be different levels like User, Supervisor, and Administrator. When you start the application you would have to log in and it would check your log in credentials against some database of sorts and determine what kind of permissions you hold.
User would have all the controls disabled on the main form except for the Go button (good way to do this?). Supervisor would have everything enabled and could make user accounts (just on some form). Administrator is identical to the Supervisor but can also backup the user accounts.
Now my problem is I'm not exactly sure how to implement this. I cannot query an online service or database because the program has to be usable without an internet connection. The problem with having an external file on the computer is that someone can edit it or delete it.
My idea was to store the user accounts in the Settings class in the application but even that stores an external configuration file. I think I'd need it to be able to be stored in the executable but also be saved and imported as a file.
Obviously the password would have to be hashed as well in this file. Does anyone know any good and easy to use classes (preferably one that doesn't have restrictions on use because this application will be commercially sold). Should the usernames be hashed too? Because if someone gets a hold of the file they shouldn't know all the user names either because it could make it easier to guess passwords.
Your boss is requesting a major shift in your application.
Without knowing all of your requirements I can't really push you in one direction or another. Check out the Smart Client Architecture and Design Guide (also available in PDF), it should help you understand the scope of what you're trying to accomplish as well as identify some design/architecture patterns your going to need to consider.
Chapter 5 deals with security considerations and describes different authentication models. This should at the very least give you a good starting point.
I was just thinking about the URLs of my current web project. The user can access different resources, like images using a web site. The URLs look something like this http://localhost:2143/p/AyuducjPnfnjZGfnNdpAIumehLiWaYQKbZLMeACUqgsYJfsqarTnDMRbwkIxWuDd
Now, I really need high performance, and one way could be to omit the extra round trip to the database for authentication and just rely on the URL to be unguessable.
Google does this with Picasa Web Albums, you can make an album private or unlisted. This secures the album but not the photo itself. Take this photo of Skagen (Denmark); http://lh4.ggpht.com/_Um1gIFfF614/TQpVMvN3hPI/AAAAAAAANRs/GY5DxrDPHUE/s800/IMG_4074.JPG, it's actually in a private album, but you can all see it.
So what is your take on this? Is a 64 character long random string "secure" enough? Are there other approaches?
Let's say I choose to do authentication for each request to the resources. The users have logged in to the site on somedomain.com, where they access their, let's say photo albums. A cookie is dropped to maintain their authentication.
Now the actual photos are served through some form of CDN or storage service on a completely different URL.
How would you maintain authentication across multiple domains? Let's say the content of two albums could be delivered from to different servers.
Do the math. 64 characters chosen cryptographically randomly (NOT rand()!) from the alphabet of 62 possible values (26+26+10: caps/lowercase/numbers) will yield 5.16e+114 possible values (62^64). Trying a million combinations a second, it would take 1.63e+101 years (moar than a googol) to guess the code. It's probably good enough. A shorter one is probably pretty good too.
64 characters * 6 bits of entropy each (Base-64 encoding, right?) is a 384-bit key. That would be considered quite weak by today's standards, if the key can be tested off-line. As long as the key can only be tested using your live system, it will probably be quite effective and you can also add active countermeasures to block clients that try many bad keys.
You're probably at much higher risk of the keys becoming public through server logs, browser logs, referrer headers, transparent proxies, etc.
There is definitely a risk to only using an "unguessable" URL. It really depends on what sort of stuff you are trying to secure. Take picasa, they are photos that are being secured, not bank records, therefore a random query string is fine. Plus, the larger your website gets the larger attack surface you will open up. It is one thing if there is only one page, that could take a fair bit of scanning to try and figure out what single URL is in use. But if you have hundreds of thousands of pages like that, then attackers are far more likely to "guess" the right page.
So, I don't really have an answer for you, just some advice on the "unguessable" url approach: don't do it. It's not secure.
Cheers,
Here is my 2-cent. I had similar problem. Our intial approach was to rename the file with random but unique name and do a two way encryption with a complex key for that name. But the things eventually boiled down to the fact that once a URL is in someone's hand, you can't guarantee the stuff's privacy. We eventually went down to DB based authentication route. See here
Edit#1:
On CDN issue, I am not sure what the solution would be. But even if what martona is saying is correct. One of the purposes of CDN is to reduce load from your main servers, and pinging back to server for each resource is probably not a good idea.
There's no such thing as an unguessable URL, and even if there were the very first time you used it over a non-SSL connection it could be seen by anyone who wanted to, by ISPs and by proxies, caches, etc. Do you really want your users/customers to trust their private photos to "unguessability"?
Making URLs unguessable isn't a great approach to security, unless your unique URLs have a time limit on their usefulness (e.g. they're short-lived URLs)