I am developing an app (in windows phone 7) that manages basic data: customer data (or contacts) and orders
I want to protect the credentials to access to the database. I want to do the following:
xxx.dll
I have put the credentials in the dll (obfuscated)
zzz.dll
In other DLL (obfuscated too) I do this:
when you install the application: I read the credentials in xxx.dll and stored them in an encrypted file (using DPAPI)
In this DLL (zzz.dll) I have a function to return decrypted credentials (using DPAPI). This func is called in the app
Every free app in the marketplace can be downloaded (eg http://mktwp7.codeplex.com/) and reverse engineered (eg http://www.ilspy.net/). If you want to store your credentials somewhere in the code, it cannot be secure (if someone invests enough time). You will always have only security through obscurity (see http://en.wikipedia.org/wiki/Security_through_obscurity). I recommend using a proxy (web) service without credentials in your app. This service stores the credentials and connects to your database. This way the credentials are secure.
Related
Is there a way to securely store and retrieve an API key in windows?
For instance, is there a windows service/api that can be used by a (c#) desktop app to store and retrieve a key?
If the key has to be placed on a client machine, it can be read out. Which language you use or what kind of storage doesn't matter. At the end you'll have to send that API key to your server to authenticate yourself and at this point someone can use a proxy like Fiddler to inspect the data and record that API key.
To accomplish this issue you need a (web) interface for your customers, where they can log-in and manage their API keys, so they can request new or revoke old keys. Also your desktop tool needs in that case some input mask, where the user can enter that key (and you store it in registry or file system).
By using this approach each customer can use its own key and if it is compromised you (or the customer) have only to revoke this single key without affecting the other customers.
Sorry to answer my own question, but it appears Windows Credential Manager and the underlying Data Protection API is designed for this very purpose. It's the same vault used by Windows to store it's various passwords.
And it has a nice c# API.. https://learn.microsoft.com/en-us/dotnet/standard/security/how-to-use-data-protection
Answered more fully here.. PasswordVault security when used from Desktop app
I want to connect to a network share path '\domainname\folder-name' using domain account, without passing credentials, through my VB6 code.
My legacy VB6 application service (running on server A) currently accesses shared folder (on server B) using local account credentials(stored in encrypted .ini file). This service is running on behalf of 'LocalSystem'.
application is using 'WNetUseConnection' API to connect to shared folder.
To ensure security local account needs to be replaced by 'domain account' and password policy should be CyberArk dynamic password.
Now this credentials can't be stored in .ini file anymore. The idea that I am working on is to get service running on behalf of 'domain account' rather 'LocalSystem'. My thought is if i make service run on behalf of 'domain account, and give relevant permissions to this account on shared folder. Shared path should be accessible to service without providing credentials.
I need help to understand which API shall I use.
The API(s) you'll need for this is WNetAddConnection.
See this example.
Hi i have Outlook plugin that send request to my WCF Service. I faced with some issues regarding public folders. So the one way to resolve it to save user Account and Password inside plugin configuration (saved in system registry key). What is the safe way to save it and send it to server?
You can use CryptProtectData and store the data in file or registry. The data can be decrypted using CryptUnprotectData. The data is encrypted in such a way that only the user with the same credentials can decrypt the data, i.e. it cannot be decrypted from another computer or when running in a secury context of a diffent Windows user.
Microsoft itself uses these functions to store credentials for the POP3/IMAP4/SMTP accounts in Outlook.
I have a REST web service running on a Windows 2003 Server. I want to prompt my users from a mobile app to enter their Windows domain credentials. I want to send those credentials to the web service, and cache them for a few days. It appears I can cache the credentials using the low-level Credentials Management functions but everything I've seen so far implies they're made to be called from an interactive session. What's the best way to cache these credentials in a web service?
MORE INFO: The reason why I need to cache the credentials in the Web Service is because I need them to access some back-end resources (i.e. SQL Server, etc.)
You don't typically cache things in a web service.
How are you prompting them to enter their credentials to begin with? That app / piece should cache the information.
It appears that Windows Identity Foundation provides a better mechanism to accomplish what I want. I'll be looking into that.
Assume system S owns a certificate C. The following quote suggests that if C is to be used by S's service apps to authenticate themselves to clients, then C should be stored in LCS. But if C is to be used by S's client apps to authenticate themselves to a service, then C should be stored inside CUS:
• The local computer store (LCS).
This contains the certificates
accessed by machine processes, such as
ASP.NET. Use this location to store
certificates that authenticate the
server to clients.
• The current user store (CUS). Interactive
applications typically place
certificates here for the computer's
current user. If you are creating a
client application, this is where you
typically place certificates that
authenticate a user to a service.
But next quote sort of negates the above, since it says if S's service is embedded in an application that runs under a user account, then certificate C should be stored inside CUS
Selecting where to store a certificate
depends how and when the service or
client runs. The following general
rules apply:
• If the service is a Windows service,
a service running in "server" mode
without any user interface under a
Network service account, use the local
machine store. Note that administrator
privileges are required to install
certificates into the local machine
store.
• If the service or client is embedded
in an application that runs under a
user account, then use the current
user store.
a) what is meant by service being embedded within an application? Is a WCF service running within Net. console application or within Asp.Net application considered to be embedded?
b) And why if app ( which embeds WCF service ) runs under the user account ( even if this account has admin priviliges ), should certificate be located in CUS? Does that mean if it is located within LCS, then S ( aka client app trying to send this certificate to the server ) won't be able to locate certificate?
thank you
a) A WCF service running within a .NET console application would be considered an "embedded" service according to that description. This is also referred to as a Self-hosted service.
If the service is running within an ASP.Net application, then it depends on what process is hosting the ASP.Net application, but normally that would be considered a service running in "server" mode.
b) In order for a service to authenticate itself to clients, the user under which the service process runs needs access to the private key corresponding to the certificate. The most convenient way to make this happen is to have the certificate (with private key) installed in the certificate store of the user that runs the process.
It is possible for an application running as any arbitrary user to access a certificate and private key stored in the local computer store as long as security permissions on them allow it.
It all boils down to the identity of the running process and whether it has permission to access the private key associated with the desired certificate.