Storing User Credentials

Hi,

I will have a desktop app and a mobile app and I intend for both of them to communicate with a web app by means of a REST API. My questions:

A. Where should the credentials be stored and in what format ? Encrypted ? For windows.
B. Same for a mobile app.

I am going along this route as I am reliably informed that ihterfacing into the application via api is the more robust and object oriented way to go about it ?

Thanks in advance,
Steve
SteveP495Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Kanti PrasadCommented:
Hi Steve

Please try having a look at the below link

http://stackoverflow.com/questions/319530/restful-authentication
SteveP495Author Commented:
Thanks for the response but my question is more about the storage of any data that is required for authentication - whatever form that data may take. For example storing a username in the registry on windows ? Does this make sense ?

And how about iOS and Android ?

Hope this gives more context ?

Thanks.
Steve
Kanti PrasadCommented:
Hi Steve

Thanks!

Please refer the credential storage section below for windows
https://technet.microsoft.com/en-us/library/hh994565.aspx

For Mobile
Do  not be stored credentials on the device. Hence use the AccountManger for storing credentials. You can also use an initial screen or dialog box to ask for credentials, but user need to re-enter their name/password often, so storing that info makes sense from a usability perspective so use a short-lived, service-specific authorization token.
Here is an example
http://developer.android.com/samples/index.html

If you want an alternative then persist credentials using Preference mechanism. Refer the below link
http://developer.android.com/guide/topics/data/data-storage.html

Here is some info that will help you understand.
http://nelenkov.blogspot.ie/2012/05/storing-application-secrets-in-androids.html

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Bootstrap 4: Exploring New Features

Learn how to use and navigate the new features included in Bootstrap 4, the most popular HTML, CSS, and JavaScript framework for developing responsive, mobile-first websites.

SteveP495Author Commented:
Hi,

Thanks again for the info.

Correct me if I'm wrong but the windows link you gave is for Server. I am talking about storing credentials to be used for api requests both on windows client and mobile client..

Steve
Kanti PrasadCommented:
SteveP495Author Commented:
Hi,

Again thanks for the info but this does not fit the bill. In my original question, I made mention that I needed to store and use credentials for REST API interface on both Windows and mobile devices (clients). Therefore, the code that forms the actual API request needs to have access to them.

It appears what you have supplied is a 'user centric' way of managing passwords but I need a systematic way that is considered relatively secure so that I can pull credentials and use them in API requests - on both mobile and windows clients. The 4 obvious examples of the clients would be:

1. A Windows .exe client to communicate with a web app via REST
2. Some Excel code to communicate in the same way
3. An Android mobile app
4. An iOS based mobile app

Hope this makes the requirement clearer. Thanks,

Steve
Kanti PrasadCommented:
Hi Steve

Here is a saleforce.com example which shows where the credentials are given for REST. Please see if this will give you an idea

https://developer.salesforce.com/page/Consuming_Force.com_SOAP_and_REST_Web_Services_from_.NET_Applications

https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/
SteveP495Author Commented:
Hi,

Thanks for the links but part of the first link is what this question is about:

"First, create variables to hold the various values needed to authenticate to the service. In reality, it makes the most sense to retrieve these values from a (secure) repository and NOT hardcode them into your client application."

Where / what type of storage is considered secure ?? This is what my question has been about all along..

Thanks in advance,

Steve
btanExec ConsultantCommented:
I do suggest consider a separate server holding that secret data (including credentials, api keys etc). The client OS and client mobile apps access that secure server (proxy) to retrieve and process it.. see this example (http://java.dzone.com/articles/how-keep-rest-api-credentials), the caveat is that it is in the "cloud". The whole idea it is always to have a trusted party separated from the client storing sensitive info and only upon authentication and authorisation to be granted access. If it is specific to user then use of second factor like OTP or out of band is preferred.

Just few cents worth chipping in
SteveP495Author Commented:
Hi,

Thanks for the comment but in your example of retrieving credentials from another server, how does the client identify / auth to that server ?

That is the very crux of the problem at yhe heart of my question.

Thanks,
Shalom CarmelCTOCommented:
It is a chicken and egg issue. You have to trust but you cannot trust but you have to trust ad infinitum...

The practical way is to manipulate the secret in some way and store the manipulated result where it is  convenient for your application.

The manipulation can be some sort of obfuscation, like XOR with underscore, rot13, base64, combinations and variations.
The manipulation can be a bit more challenging, for example encrypting with a secret that is embedded into your code.
The last option secures the secrets while at rest, but anyone savvy to disassemble your code will find it.
The most secure way is to have a secure hardware dongle with usb storage, but I have a feeling that it is an overkill.

So the question is what is the risk profile here, and who are you protecting: the client or yourself.
btanExec ConsultantCommented:
the identity store is helmed by the identity provider which is yet another org own identity store like AD or LDAP directory. The whole use case lies within federated identity and use of SAML (SSO, Authn) and Oauth (Authz). It is tough to go for bits and pieces and intent to have a secure systems with apps accessing it. The suggested 3rd party acts as the neutral that is supposedly to be trusted by both party that needs to talk to each other ..

I know that you have both wanting to talk to each other securely so unless there is trusted central identity store, it is tough to avoid having the need to share some preshared known secret on the device which is not what I advocate no matter how much encryption you have or ACL enforced in it via the OS running. Regardless, if there is some preshared, I do encourage using certificate based (RSA private/pub cert for auth) and Diffie Hellmen for key session exchange in each session comm channel established btw parties...the secure comms will be non-trivial
SteveP495Author Commented:
Not quite on the mark...
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
iPhone

From novice to tech pro — start learning today.