When a user uses a client like Twitter Client to update their status message, they have to provide their username and password. The server then authenticates the user and updates status message.
My question is how to ensure the security of such sensitive information over the internet.
Is JSSE the correct way to go about it?
What points are to be kept in mind when writing such a client?
Kindly help.
From the JSSE Reference Guide:
Once the client and the server are comfortable with each other's identity, SSL provides privacy and data integrity through the encryption algorithms it uses. This allows sensitive information, such as credit card numbers, to be transmitted securely over the Internet.
So yes, JSSE is a good way.
For Twitter specifically, they have a whole page dedicated to security best practices. A lot of those things apply to applications generally, so it's worth a read. In a nutshell, they highly recommend a protocol called OAuth to handle the password safely, and it's going to be mandatory soon. The actual programming environment you use is much less important than the process you use.
For twitter use OAuth instead of basic authentication. Its much more secure way to authenticate users in your case. Some info could be found here:
https://dev.twitter.com/docs/auth/using-oauth
Related
Is there any way to connect from java application to IMAP server without storing password?? Though i explored and couldn't find any way. So I am encrypting the password with a key and decided to divide key in parts and store in different place- database and some session. Any other way?
What authentication functions can be used depends on the server. The client has to use what the server provides.
By default the authentication mechanism that every IMAP server supports in plain authentication using username/password which of course means that you have to store the password.
There are other authentication mechanisms like Kerberos - see RFC1731 but as far as I know most servers do not support this.
On the other had there are servers that support OAuth2 authentication via IMAP, but I am not sure if this is really something standardized. As far as I know it is for example used by Microsoft and Google. Yahoo even seems to require oAuth for IMAP but I wasn't able to find a link to Yahoo describing this.
In my app, I need to pass client_id and client_secret to make my API calls.
What is the most secure way of storing client_id and client_secret's on the android app?
I have read about SharedPreferences and I am sure they are not secure. Also read about Keystore but not sure if that is the right approach. Can you please suggest what would be the most secure way of storing such information?
Thanks
R
The best approach is to use Android's Keystore. It will handle the key generation, storage for you. Your app will be communicating through KeyChain API which offers the following advantages:
It performs all the cryptography for you
Hard to extract from device
Each app can only access their own keys (enforced by Keystore)
Securing the user's secrets in a keychain
Mobile OAuth Authorization flow
In my app, I need to pass client_id and client_secret to make my API calls.
It seems to me that you are not using the correct OAuth authorization flow in your mobile app because the one you are using now requires the client_secret. I think you may be trying to use the flow meant for m2m(machine to machine) authorization.
The correct flow to use for a mobile app is the Authorization Code Flow with Proof Key for Code Exchange (PKCE).
From auth0.com/docs:
The PKCE-enhanced Authorization Code Flow introduces a secret created by the calling application that can be verified by the authorization server; this secret is called the Code Verifier. Additionally, the calling app creates a transform value of the Code Verifier called the Code Challenge and sends this value over HTTPS to retrieve an Authorization Code. This way, a malicious attacker can only intercept the Authorization Code, and they cannot exchange it for a token without the Code Verifier.
You can read that this is the recommended approach in the OAuth 2.0 RFC8252 for Native Apps, that is about the best practices for mobile apps:
Abstract
OAuth 2.0 authorization requests from native apps should only be made
through external user-agents, primarily the user's browser. This
specification details the security and usability reasons why this is
the case and how native apps and authorization servers can implement
this best practice.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8252.
Securely storing secrets in the mobile app
What is the most secure way of storing client_id and client_secret's on the android app?
Also read about Keystore but not sure if that is the right approach. Can you please suggest what would be the most secure way of storing such information?
Yes, the Android Keystore is the correct way to go. You can use it from the Android Security Library to store your secrets but bear in mind that an attacker can use an instrumentation framework to hook at runtime into the code that uses the client_id and client_secret already decrypted and extract them for use outside of your mobile app. A popular instrumentation framework used for this propose is Frida:
Inject your own scripts into black-box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
I invite you to read my answer to the question Store Client Certificate and key (.pem) in Android securely to see more details about using the Android Keystore with the security library, and the answer includes some code examples.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation:
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
I know it is very basic question but I need a solid answer to clear my thoughts on it.
I am sending user credentials, key etc in header part in POST method,
Is it a good way? if not then why?
It's a bad way of doing things like these since if somebody could intercept your request - they would get your credentials easily. Better to avoid or at least encrypt this kind of requests.
One of the most popular solutions nowadays is to use OAuth 2.0 (or even better - OpenID Connect). They will bring some complexity to your system but the cool thing about it is that your application doesn't have to deal with passwords at all. Everything is delegated to Authority Server. And there are a lot of the authorization servers ready to use, for instance Keycloak (we have been using it and it and it was really good experience for us)
I am currently in the early stages of creating a web application (HTML5, JS, etc.) that uses a REST API on the backend (Java, specifically Jersey v1.18). The nature of the data that will be stored is highly sensitive, so security is something that I’ve started looking at, even though the application is only in the early stages. The eventual goal will be to have native mobile applications as well, and to potentially provide access to the data for external clients via the same API.
In my research thus far, I have identified a variety of authentication methods, including HTTP Basic, token-based, session cookie, OAuth, HMAC, etc. The key component here is that the REST API will be primarily accessed by users, rather than other applications or backends. Thus, having a “login/logout” equivalent is important, and this boils down to user level authentication.
So far, HMAC authentication looks to be the most promising, as we have no plans to integrate with any OAuth provider at this moment.
I have already read through dozens of SO posts, as well as articles such as:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
http://www.errant.me.uk/blog/2013/04/authenticating-restful-web-applications/ (note: this is clearly bad, as salting with the username is not recommended)
Ideally, HMAC seems like the way to go, but I have yet to see a recommended approach to handling the shared secret. The idea of using a resource to validate credentials, which then provides a token/nonce to be used with the HMAC scheme, seems to be an option, but I’m questioning the advantages over just using this token/nonce strictly as a token.
I know that HMAC authentication for a REST API has been discussed at length, but when used in conjunction with the authentication details that users have come to expect (username, email, password, etc.), is there any recommended approach that doesn’t require a pre-shared secret key?
This is primarily an opinion-based question, but I'll offer my two cents: just go for a session cookie.
If your primary audience is humans, and you don't need to integrate with third parties, don't bother with OAuth. Just make sure your API is only available over HTTPS, and issue a session token that the server can revoke after login. Strictly speaking it doesn't need to be a cookie; I've seen APIs that stash the token in HTML5 session storage and provide it in the Authorization header or as a query param.
If you have SSL set up properly, your users will get the expected padlock in the browser, and you'll be safe from anyone in between you and the client. If the client is compromised, you're screwed anyways. And since the client can't keep a secret, there aren't a lot of advantages to more complex HMAC schemes.
I am designing my first GAE app and obviously need to use HTTPS for the login functionality (can't be sending my User's UIDs and passwords in cleartext!).
But I'm confused/nervous about how to handle requests after the initial login. The way I see it, I have 2 strategies:
Use HTTPS for everything
Switch back from HTTPS (for login) to plain ole' HTTP
The first option is more secure, but might introduce performance overhead (?) and possibly send my service bill through the roof. The second option is quicker and easier, but less secure.
The other factor here is that this would be a "single-page app" (using GWT), and certain sections of the UI will be able to accept payment and will require the secure transmission of financial data. So some AJAX requests could be HTTP, but others must be HTTPS.
So I ask:
GAE has a nifty table explaining incoming/outgoing bandwidth resources, but never concretely defines how much I/O bandwidth can be dedicated for HTTPS. Does anybody know the restrictions here? I'm planning on using "Billing Enabled" and paying a little bit for the app (and for higher resource limits).
Is it possible to have a GWT/single-page app where some portions of the UI use HTTP while others utilize HTTPS? Or is it "all or nothing"?
Is there any real performance overheard to utilizing an all-HTTPS strategy?
Understanding these will help me decide between a HTTP/S hybrid solution, or a pure HTTPS solution. Thanks in advance!
If you start mixing http and https request you are as secure as you would be using http, because any http request can be intercepted and can introduce possible XSS attacks.
If you are serious about your security read up on it, assuming that you only require https for sensible data and transmitting the rest with http will bring you in a lot of trouble.
You pay for http and https the same for incoming bandwidth and you should see any difference in instances hours. The only difference is the one time pay (per month) that you need to pay for SNI or VIP