SteveP495
asked on
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
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
ASKER
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
And how about iOS and Android ?
Hope this gives more context ?
Thanks.
Steve
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
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
http://windowsitpro.com/windows-81/managing-account-credentials-windows-and-web-credential-manager
ASKER
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
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/
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/
ASKER
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
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
Just few cents worth chipping in
ASKER
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,
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 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
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
ASKER
Not quite on the mark...
Please try having a look at the below link
http://stackoverflow.com/questions/319530/restful-authentication