Storing User Credentials

Hi Steve

Please try having a look at the below link

http://stackoverflow.com/questions/319530/restful-authentication

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

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

you can store in credential manager on the client

http://windowsitpro.com/windows-81/managing-account-credentials-windows-and-web-credential-manager

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

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/

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

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

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,

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.

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

Not quite on the mark...