My company is building a RESTful API that will return moderately sensitive information (i.e. financial information, but not account numbers). I have control over the RESTful API code/server and also am building the Android app. I've setup the API to use OAuth 2 with authorization code grant flow (with client ID and secret), and I auto-approve users without them having to approve the client since we own both client and provider. We use CAS for SSO and I am using this for the Authorization server as part of the OAuth 2 process when the user logs in to retrieve the token.
I am contemplating various ways to secure the data on the Android app. I've concluded that storing the client id and secret on the device is definitely not going to happen, but am thinking that storing the auth token might work, since it is only risk to the individual user (and really only if they happen to have a rooted phone).
Here are two options I have thought of. They both require me to have a sort of proxy server that is CAS protected, does the dance with the API server, and returns the auth token. This gets rid of the need for storing the client id and secret in the app code.
Here are what I've come up with:
1) Require the user to enter their password to access data each time they startup the App. This is definitely the most foolproof method. If this were done, I'd probably want to save the userID for convenience, but in that case couldn't use the CAS login (since it's web-based). I might be able to use a headless browser on the backend to log the user into CAS and retrieve the token based on what they enter in the Android form, but this seems hacky. Saving the userID is similar to what the Chase app does (if you happen to use this one) - it saves the userID but not your password between sessions.
2) Store the auth token on the Android device. This is a little less secure, but almost foolproof. When the user starts the app for the first time, open the webpage to the CAS login of the proxy server that returns the token (similar to https://developers.google.com/accounts/docs/MobileApps). After the user logs in and the token is returned to the app, encrypt it and store it private to the application. Also, use ProGuard to obfuscate the code, making the encryption algorithm more difficult to reverse engineer. I could also work in a token refresh, but I think this would be more of a false sense of security.
3) Don't use CAS but come up with another way to get an auth token for the service.
Any advice of how others have implemented similar scenarios (if it's been done)?
Thanks.
Well the reason why standards like OAuth are developed is that not everyone has to rethink the same attack vectors again and again. So most often it is your best choice to stick to something already available instead of baking your own thing.
The first problem with clients that are not capable of secretly storing data is that the user's data could be accessed by some attacker. As it is technically not possible to prevent this (code obfuscation won't help you against an expert attacker), the access token in OAuth 2 typically expires after short time and doesn't give an attacker full access (bounded by scope). Certainly you shouldn't store any refresh token on such a device.
The second problem is client impersonation. An attacker could steal your client secret and access your API in his own (maybe malicious) app. The user would still have to login there himself. The OAuth draft there requires the server to do everything it can to prevent this, but it is really hard.
The authorization server MUST authenticate the client whenever possible. If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization responses, and SHOULD utilize other means to protect resource owners from such potentially malicious clients. For example, the authorization server can engage the resource owner to assist in identifying the client and its origin.
I think Google are the first to try another approach to authenticate a client on such devices, by checking the signature of the application, but they are not yet ready for prime time. If you want more insight into that approach, see my answer here.
For now, your best bet is to stay on the OAuth way, i.e. having the access token, client ID and client secrect (when using the authorization code grant flow) on the device, and configure your server to do additional checks. If you feel more secure obfuscating these, just do it, but always think of it as if these values were publicly available.
Related
I have a website and my own server and database, I also have an native Android app. I need to allow users to be able to sign-in with their account from the website inside the app in order to sync information and other things they need to use. I've been stuck for a couple of days trying to figure out how to do that. I've found a lot of content regarding OAuth and AppAuth but they are focused on using an OAuth API to the job. Back on my server, I use Hybridauth for social login, but users can also register directly on the site. How would be the proper way to allow my users to sign-in to their website account through the Android app?
You're overthinking it. OAuth isn't meant for users to log in, it's meant to enable external services to access data on behalf of a user.
To make a user log in? Create a POST endpoint on your webservice named login. It should take two parameters- username and password. The body of the login service should salt and hash the password, then check if the hash equals the hash stored in the db for the same user. If so, you're logged in and you return a success packet with a unique token to authenticate you for later requests. If not, you return a failure. The Android app would ask the user for their data, then send a request to the endpoint. On success it saves the token and sends it in all future requests to authenticate yourself, either as a parameter or as a header.
This is of course the simplest possible version. More advanced features would include expiring of login tokens, refresh tokens, possible lockout if you have too many bad requests, etc. But the above is the basic idea. Although really I'd look for an open source solution you can take, as there's quite a lot of complexity when you get into all the stuff mentioned above, and its a place where a mistake that leads to a vulnerability is probably the most dangerous.
Background
We've developed a CMS in ASP.Net Core 2.2 a few years ago for company internal day-to-day stuff. It holds several hundreds of users and I'm considering adding an android app to it. The android app should mainly serve as a front end to existing logic in the ASP.Net controllers. The benefits of the Android app I expect to have are:
Better UX
User not having to type the password for each session (the ASP.Net page logs them out after 20 or 30 minutes of inactivity)
Push notifications etc.
Existing infrastructure
The CMS has already an API (JWT) which is used by several backend services and could easily be expanded to be used by every user through the android app. Unfortunately I'm not a professional developer in general and are quite new to Java especially, so please bare some patience with me as I'm asking for a general advise of how to handle the authentication in the android app (Java).
I read about curity.id and stuff like this, but IMO this would be kind of overkill to the whole project and would also require major changes to the already working fine ASP.Net website.
Now my question is whether the following would be an acceptable practice to do:
When the user opens the app for the first time, I ask him for his username and password (and optionally 2nd factor).
I make an http request to the API of the CMS in order to authenticate the user and get back the JWT token on successful authentication.
The JWT token gets stored in some way (e.g. SQLite DB) and is being used for subsequent requests being made to the API.
Since the the lifetime of the JWT token is also limited to a few hours and the goal is to keep the app running without prompting the user for his credentials all the time, I need to store the password also in some way in the app or a DB on the android device. This is actually the part which confuses me the most and I have no clue how I would store the password in a safe way, so it may be used again for authentication requests down the road. (I'm aware that if the user uses 2nd factor there is no way around but to ask for the 2nd factor every time the token expires or to exclude the device or so, but this should not be within the scope of this question)
So I would be grateful to get some judgements about this approach, if it is acceptable in general and what would be the best way to do about point #4.
Thanks a lot
Do not store password
If store (and frequently send) passwords you defeat the entire purpose of a token. The token itself exists as a disposable means to substitute the primary authentication (yet is cryptographically sufficiently strong to replace it without reducing system security).
SIMPLE: Use a long token
Create a new authentication API (or add some parameters to the existing one) to enable the mobile APP to require a long-lasting token (for example 6 months). If you then store this token in the SecureStorage of the device you can be quite confident it can not be extracted from there.
Remember that with this solution, you lose control over the authentication. This is not the best practice but is the easiest solution to adopt in the case of existing JWT infrastructures that use only one token.
RECCOMENDED: Create a renew token system
Once you issued a token you cannot revoke it. Hence the main issue introduced by the 'long token' solution is that if a device gets lost it can not be de-authenticated. This can be solved by a renew token:
You create an authentication API that after the confirmed authentication it creates a unique sessionId, stores it in the DB, and issues a special token that contains the sessionId among other information. This is called the renew token. This special token can be used only for the exchange API
You then create an exchange API, that expects a renew token in exchange for a normal token (that can have the same properties your current token has). This API will always check if the sessionId present in the renew token is still marked as active in the DB otherwise will not issue the normal token.
This approach allows you to have very long expiring tokens but still have control to remotely log out the app (by masking the sessionId as deactivated in the DB) and even monitor how frequently the app is used.
I logged in as Scott who only has read permission. The oauth2 server(JAVA based) gave me a token. Then I asked my teammate to send me his non-expired token. I updated my Angular application and hardcoded the token that was given to me. I tried to make changes to the api and I was able to make some change.
How can backend api prevent this?
You've successfully implemented a session hijack. This happens because sessions are based on tokens stored in the web page or cookies rather than IP addresses or something. This makes sense because IP addresses can be spoofed while a cryptographically secure session token is practically impossible to spoof.
While you could add strategies to make this more difficult (eg: some kind of hardware token that is involved in cryptographically signing every message), why do you feel you need to? All but the most secure sites rely on this mechanism.
What is the value of using a authentication token when using a REST webservice instead of sending a username, password over HTTPS/Encryption each time you make a request?
I understand that for instance OAUTH has some benefits cause you don't need to give away your password to 3rd parties, you can pass a token to trusted 3rd parties whom you dont want to share the username/password..etc
But other than this special benefits above which I certainly dont need in my case, why would I use tokens instead of sending username/password everytime.
This might be to make life easy for client, and it does not have to send the username/password everytime. Well ok but then now client has to remember my token and send me the token on every request. So instead of remembering/sending username/password now it will do the same for tokens! So client implementation code does not get any less.
So what is the real value here?
It really depends on the scenario - it's hard to tell without knowing more about the API - but usage of "authentication tokens" is far from universal, you're right that many APIs don't need (and don't use) them. Many APIs simply require an API key to be sent with every request (often via HTTPS to prevent it from being intercepted), or require an API key to identify the user and also a digital signature with a "secret key" to prove the user's identity (see When working with most APIs, why do they require two types of authentication, namely a key and a secret? ).
Usernames/passwords are not often used in public APIs because they're not flexible enough and do not provide enough "separation" between the user identity and the application identity. E.g. you register as a developer to use the Flickr API and create an iPhone app that uses that API - would you really want your developer username/password to be built into the app? What if you change your password later? What if you want to develop 5 apps and track usage for them separately and be able to shut off any app at any time without affecting the others?
However, for cases where you truly want to identify a human user only, not an appplication (e.g. a private API back-end that will only serve your own applications, not a public API), in most scenarios I don't see anything wrong with what you suggested, i.e. username/password over HTTPS with every request. Oh, by the way, auth tokens have the added advantage of being "restrictable" (can expire at a certain time, can be restricted to certain actions only, etc), but obviously this is only useful in very specific scenarios.
ALSO: As user "Dan" pointed out above, when designing an API that requires sending the username/password with every request (or with any request really, even if it's just the login request), be careful how you do it. If you're using a technique which browsers support by default (e.g. HTTP Basic Auth), you're preventing yourself from ever exposing the API safely to cross-domain users (i.e. most likely your API can never be safely called directly from the browser, i.e. from AJAX / Flash / Silverlight code).
This is a complex topic which can't be explained fully here, but just remember that if your API is relying on any security credentials that the browser can remember and then "silently" inject in every request (e.g. HTTP Basic Auth, cookies), then it's NOT safe to enable cross-domain access to that API using any cross-domain technique (CORS, JSONP, crossdomain.xml, etc).
The best way I can answer this is to point you to this page describing REST security. It belongs to the restlet wiki, not to Jersey, but it can be applied to Jersey as well as they are both REST implementations.
This is extracted from the link I provided:
"For the most resistance, the server can present the client with an application level authorization token, an opaque value that the server can verify belongs to the right authenticated user.
Such a token should be be difficult for a third party to calculate, e.g. a server-salted MD5 or SHA1 hash of the user's identification credential.
To defeat XSRF, this application-level token needs to be transmitted by means that the user-agent does not automatically return with each request. For example, it can be sent in the HTML of a form as a hidden field, and returned via POST in the encoded form entity."
Here's the problem: I'm developing a desktop application to interface with a server, and the client has to log in. Something like with Skype or IM applications. I want to give the client the option of being logged in automatically, ie. no need to type in their credentials every time the applications loads.
How can I achieve this, while protecting the client's information?
Thank you, I've been pondering this problem for days now and I can't seem to come up with a solution. Any help or guidance would be gold at this stage.
If you are using a secure communication channel to the server (like using SSL, for instance) then you could send the username and a hash of the password (using a cryptographically secure hash function like SHA-512 - there's no known feasible collision or preimage attacks).
What you save locally is the username and the hash of the password. Given that the communication channel to the server is secure nobody else will see the information sent (no replay attack possible). And using a cryptographically secure hash function means that it's a one-way function, no "going back" to the original input.
Another way would be to get a token of authentication from the server upon successful login. Then the protocol could accept authentication of user combined with the token within a certain duration of time. Then you don't have to store the hash of the password locally, only the username and the token. Thus if somebody gets the token it will expire at some point. But bear in mind that the token should not be reissued using another token, only with a correct username/password combination. Additionally, the user should not be able to change/see the password if logged in using a token either. If you want to go even further then you could also restrict the token to only work from certain IP address(es).