I am looking for the best practice for storing user credentials in a windows 7 phone app. I am writing an app for a web service that requires authentication. Thankfully it is only basic authentication at this point. What is the best way to store those credentials?
The best way to store credentials in your case would be encrypting them and storing in the application-specific isolated storage - basically, it cannot be accessed by any other application, so that gives another protection layer.
In terms of security, the best practice would be to avoid storing user credentials if possible. MSDN states:
Applications often ask users to
provide a username and password that
is used as credentials to authenticate
the user with a web service or
website, yet if they do so each time
the application is run, users can
become annoyed.
It is strongly recommended that your
application prompt for usernames and
passwords each time your application
needs them from the user; if you
attempt to save the credentials on the
phone you risk exposure of those
credentials to a malicious application
if the Windows Phone is lost or
stolen.
Actually, in the data encryption tutorial mentioned in the other answer, Rob Tiffany makes a similar disclaimer:
The OS Does Not include framework
support for storing your passwords and
salt values securely nor does it come
with any kind of built-in key
management. This means the only way
to ensure your encrypted data is
actually secure is to never store
your password, salt value or keys on
the phone.
...
If you see an app in the Windows
Phone Marketplace that allows you to
cache your credentials or keys locally
for convenience, be aware that these
are Not Secure solutions because
everything a hacker needs to get at
your data is right there in the code
or in Isolated Storage.
Encryption is good for raising the bar, but this would not really protect the credentials from a knowledegable hacker. Usability sometimes trumps security, but you should take this decision knowing that encryption will not solve the core issue in this case (and maybe let the user be aware of this risk).
A good explanation by Rob Tiffany of how to encrypt your data in isolated storage can be found here:
Don’t forget to Encrypt your Windows Phone 7 Data
I haven't tried out the code myself, so can't vouch for it's correctness (sorry Rob :-) - should serve as a good starting point though, I would imagine.
I also second Dennis' point about application-specific isolated storage giving you an additional/basic layer of protection in addition to encryption, as theoretically at least, other applications cannot access your applications isolated store.
You should use the ProtectedData class to store securely various bits of confidential information.
Learn more at How to: Encrypt Data in a Windows Phone Application
Related
I want to use the Direct Mail SDK(Java) directly within client application which is distributed across. The way to authenticate users within the application, I need to provide access keys as below,
IClientProfile profile = DefaultProfile.getProfile("cn-hangzhou", "<your accessKey>", "<your accessSecret>");
How can I prevent user to know the Access Keys and still prevent the need of third-party API? Is it possible?
First, it is bad practice to code an application that requires secrets that runs on the client. You should manage everything on the server and provide an API that the client software interfaces with.
Second, there is no way to hide those credentials once passed to the client. You could encrypt the credentials but at some point the client application will need to decrypt them. Even amateur programmers can figure out how you are processing your credentials.
Ignoring the above advice, Alibaba Cloud supports STS which provides temporary access keys. Using your Alibaba credentials, you would call AssumeRole which creates temporary access keys giving the user permission call DirectMail. You can limit the time that the credentials are valid. The range is 900 to 3600 seconds. After that duration the keys become invalid.
Keep in mind that 900 seconds is a long time. A bad actor getting access to those keys could send thousands of emails using your account. Therefore implement strong user authentication, STS and temporary access keys.
If you think that just keeping your interface secret is enough, don't. There are millions of script kiddies on the Internet poking at every IP address. Launch a new ECS instance and you will see attacks within hours.
As you said since it is a Java Web Application(assuming), currently I think of something using similar to JBOSS Vault to store the access keys securely.
If it is some standalone client application still you can use some encryption methodologies to store the data. But this will only prevent easy access to the data/keys. But it is not impossible. The best bet would be creating another third-party API
Getting a bit lost in the diverse documentation endpoints (here, here, to name a few…)
This one is pretty usable for a given account by providing a json key as an environment variable.
The thing is, I just don't see how commands can be run on the behalf of a user authenticated via oauth — practically speaking, where do you specify the oauth user token ?
Thanks for sharing this insight
Best
google-cloud-ruby (which you linked in your question) is designed to provide access via service account credentials, as you noted. For help with "lower-level" access in which you managing your own OAuth tokens, you might consider google-auth-library-ruby. However, if you can use a service account instead of a user account to use the higher-level access provided by google-cloud-ruby, I believe it's probably the best approach, as recommended in Google Cloud Storage Authentication:
Due to the complexity of managing and refreshing access tokens and the security risk when dealing directly with cryptographic applications, we strongly encourage you to use a verified client library.
I want to send info between a desktop/laptop/tablet app and Windows Phone. One possibility is to send data to the SkyDrive account and have the other end pick it up from there. Is this feasible? What I have in mind is the "Windows 8" app running on the desktop, laptop, or tablet allowing the Windows Phone app[s] to send data to its account. Is this possible, such as by providing the Windows Phone app with the Skydrive login info, or...???
From all the other questions you've posted around this query, it sounds like you want to put a mechanism in place to communicate between a Windows 8 app and a windows phone app. I would recommend you look at building a service to handle the communication instead of trying to leverage mechanisms that weren't designed for what you want to achieve.
In direct answer to the this question, though, you can probably achieve it in this manner, but what happens if the user deletes the file you create?
So, SkyDrive is unique to a user, not a device. This means if your application is running on more than one device you can use SkyDrive as a shared, unified storage option. Not just for files but also for application settings. There's an SDK for every platform, not just MS.
Here's what you need to consider.
The roaming API in Windows 8 puts information in a protected area of SkyDrive. As a result, the user cannot delete or screw up the files stored there. To that end, using SkyDrive as a shared location (like you are asking) doesn't have this benefit. The user can screw with your files or delete them - and wreck your app. There is no such thing as protecting your app files in SkyDrive (at this time).
Specifically, to your question:
The authorization model for SkyDrive requires a token that cannot be practically cached for any app. Also, you cannot cache credentials because you never get the credentials in the first place - you only get the resulting token. Listen, you would violate every possible best practice if you //asked// the user for their username and password and stored them. Please do not do this.
The final answer is this: an app on multiple devices can use SkyDrive as a shared storage solution for files and settings (like XML files) - but the developer needs to understand the risk and mitigate that (mitigation might be easy for your app). The user, on every device, would need to sign in and grant each application access to it folders. And, that's it.
Is there a way to protect some cryptographic data from applications other than my own in Windows? I'm not concerned about protecting it from the user - this is obviously impossible - but, rather, from non-elevated applications other than my own.
I'm aware that I could simply run the application's core code as a service, with the data accessible only to system accounts, but I would prefer if I could keep the application running under a token not much more permissive than the user's normal token.
Additionally, I would prefer not to have a dependency on .NET if possible.
CryptProtectData
can do per-user encryption (it is per-user if you do not pass CRYPTPROTECT_LOCAL_MACHINE flag). However if you opt for per-user encryption, other users including elevated admins won't decrypt it.
We are working on a service that will have website access for stats and other tasks, but the majority of use will be through a client gem and rake tasks. What is the best way to handle authentication for both pieces.
It looks like fiveruns_tuneup, getexceptional, New Relic and others have websites with username and pass, but use API keys stored in ./config/serviceName.yml Any reasons it is better to have API keys opposed to user/pass in the config (do they use keys because often the key is checked into SCM and used across the project, where ours would not be checked in and would be a per user setting)
GitHub has you put your public key on the github servers and uses that, but I think git supports public/private key by default.
Would it be preferred to keep a ./config/serviceName.yml or since we have to create a subdirectory with other information have ./serviceName/config.yml? (does the per user, not stored in SCM mean it is better to keep it all in one excluded directory?)
Just looking for some thoughts and ideas on best practices before starting implementation.
I recommend that you use username/password combos for website accounts, and API keys for any web services. Here are the advantages of this technique:
By linking API keys to an account, you could have many API keys for the same user. Perhaps this could be used for many remote web servers that consume this data service, or to perform unique tracking.
Attaching API keys to an account also lets you keep the user's username and password uncompromised since an API key will not contain them. Many users use the same username and password on many services, so you are helping to protect them.
You could limit access to portions of functionality for each API key, but give their username access to everything their account should have access to. Additionally, you can even give them the ability to limit how much access an API key might have.
Most of the major services (Yahoo! API, Flickr, Google API, etc) use accounts with a username and password to login to the web account, and API keys for integration points.
Never use user/pass when you can help it. The security issues are horrible. If the user/pass leaks out, you have to change your password or they get access to your whole account.
API keys are better because they're easier to change and can be limited to only the part you need access to with the APIs (ie, if someone has your password they can change your password. They can't if they just have an API key).
Different API key per client or secure token exchange (such as OAuth) is the best solution if you'll have more than just your client on the API.
The github approach is bootstrapping on top of existing git practices, however it's not a bad idea since presumably each user will have their own private key to match a published public one in the central authority. Since key-agent's already furnish a means of safe authentication this seems like a very safe approach. Public/private keys are a well thought out authentication scheme, which has unfortunately been reinvented many times to limited success.
The problem with the API key is that anyone who gets a copy of the API key can do whatever that authorizes. Storing the API key somewhere in the project begs the users to share a key. If you are associating public keys with a user, it is possible to grant rights to the client on a per user basis, and a proper key-agent approach suggests that those will not be stored in an SCM anywhere.
I'm not sure I follow what the distinction between config/serviceName.yml, or serviceName/config.yml is. It doesn't seem as if it would be pertinent if you have public/private keys as an authentication method for the client.