I am working on a web application and security is one of our main concerns in this application. I was looking at different methods of API security (mentioned here on OWASP) and couldn't understand the difference between Mutual SSL auth and token-based auth. Here is a brief into of both before I move forward,
Mutual (or two-way) SSL authentication provides a combination of an encrypted data stream, mutual authentication of both server and client, and automatic sign-in convenience.
Source
Every single request will require the token. This token should be sent in the HTTP header so that we keep with the idea of stateless HTTP requests.
Source
From what I get, they both are probably alternatives of each other, so here are a few question that I have in mind and if you could answer them, I'd be so thankful.
In my opinion, both of these methods are alternatives of each other, is it so?
Yes? Then which one is better then the other and why?
No? Then should we use one of these or both? Also, whats the difference between them based on which you're saying that they are different.
In my opinion, both of these methods are alternatives of each other,
is it so?
Both of these method should be used based on your context. Two methods are used based on the need and security context.
No? Then should we use one of these or both? Also, whats the
difference between them based on which you're saying that they are
different.
Token-based auth (OAuth) usually used in a scenario where there is a need to establish a secure communication between mobile app/ web app and api server.Where password is not stored in the device.It store a temporary token to the device which expire over time.
Mutual SSL Mutual Authentication can be good candidate for establish a secured communication between two servers.
So it is the context which decide the choice!
Related
A client of mine has a bunch of APIs in CloudHub that communicate with two APIs on premise in their runtime. The question I get asked, to which I don't really know the answer, is how to secure the communication between the APIs on CloudHub and on premise without using API Manager (since the client preferred not to pay for it) ? I thought of a middleware (middleware inception) that hashes the messages from one end to another, is this a viable idea? What could the best answer be?
The server applications should implement some basic security best practices like authentication and encryption.
Having applications deployed in any cloud environment without security is a big security risk. I assume that there is a secure link between the CloudHub environment and their on premise environment, like a VPN, but even so this architecture would not probably pass a security audit.
They should implement authentication using HTTP Basic authentication or OAuth 2. These are the most common authentication schemas used for REST APIs. Note that credentials go in clear text so they should also implement encryption.
To encrypt the traffic the server applications should use TLS, ie HTTPS connections instead of plain HTTP.
Optionally you could also implement mutual TLS authentication, requiring the client to have a valid certificate that the HTTPS server validates.
Hashing message could be an additional level of security, but that implies changing the applications logic to implement some custom security. The effort should be better put into implementing standard security practices as mentioned. If after that you want to add it feel free to do so.
You have not shared details of the technology of the on prem applications. Mule applications can implement both the client and server side of any of these methods. Read the documentation for details:
https://docs.mulesoft.com/http-connector/1.7/http-authentication
https://docs.mulesoft.com/mule-runtime/4.4/tls-configuration
https://help.mulesoft.com/s/article/Tutorial-how-to-create-a-simple-Mule-4-http-basic-authentication-application
I am developing Restful API layer my app. The app would be used in premises where HTTPS support is not available. We need to support both web apps and mobile apps. We are using Node/Expressjs at the server side. My two concerns are:
Is there a way we could setup secure authentication without HTTPS?
Is there a way we could reuse the same authentication layer on both web app (backbonejs) and native mobile app (iOS)?
I think you are confusing authenticity and confidentiality. It's totally possible to create an API that securely validates the caller is who they say they are using a MAC; most often an HMAC. The assumption, though, is that you've securely established a shared secret—which you could do in person, but that's pretty inconvenient.
Amazon S3 is an example of an API that authenticates its requests without SSL/TLS. It does so by dictating a specific way in which the caller creates an HMAC based on the parts of the HTTP request. It then verifies that the requester is actually a person allowed to ask for that object. Amazon relies on SSL to initially establish your shared secret at registration time, but SSL is not needed to correctly perform an API call that can be securely authenticated as originating from an authorized individual—that can be plain old HTTP.
Now the downside to that approach is that all data passing in both directions is visible to anyone. While the authorization data sent will not allow an attacker to impersonate a valid user, the attacker can see anything that you transmit—thus the need for confidentiality in many cases.
One use case for publicly transmitted API responses with S3 includes websites whose code is hosted on one server, while its images and such are hosted in S3. Websites often use S3's Query String Authentication to allow browsers to request the images directly from S3 for a small window of time, while also ensuring that the website code is the only one that can authorize a browser to retrieve that image (and thus charge the owner for bandwidth).
Another example of an API authentication mechanism that allows the use of non-SSL requests is OAuth. It's obsolete 1.0 family used it exclusively (even if you used SSL), and OAuth 2.0 specification defines several access token types, including the OAuth2 HTTP MAC type whose main purpose is to simplify and improve HTTP authentication for services that are unwilling or unable to employ TLS for every request (though it does require SSL for initially establishing the secret). While the OAuth2 Bearer type requires SSL, and keeps things simpler (no normalization; the bane of all developers using all request signing APIs without well established & tested libraries).
To sum it up, if all you care about is securely establishing the authenticity of a request, that's possible. If you care about confidentiality during the transport of the response, you'll need some kind of transport security, and TLS is easier to get right in your app code (though other options may be feasible).
Is there a way we could setup secure authentication without HTTPS?
If you mean SSL, No. Whatever you send through your browser to the web server will be unencrypted, so third parties can listen. HTTPS is not authentication, its encyrption of the traffic between the client and server.
Is there a way we could reuse the same authentication layer on both web app (backbonejs) and native mobile app (iOS)?
Yes, as you say, it is layer, so it's interface will be independent from client, it will be HTTP and if the web-app is on same-origin with that layer, there will be no problem. (e.g. api.myapp.com accessed from myapp.com). Your native mobile can make HTTP requests, too.
In either case of SSL or not SSL, you can be secure if you use a private/public key scenario where you require the user to sign each request prior to sending. Once you receive the request, you then decrypt it with their private key (not sent over the wire) and match what was signed and what operation the user was requesting and make sure those two match. You base this on a timestamp of UTC and this also requires that all servers using this model be very accurate in their clock settings.
Amazon Web Services in particular uses this security method and it is secure enough to use without SSL although they do not recommend it.
I would seriously invest some small change to support SSL as it gives you more credibility in doing so. I personally would not think you to be a credible organization without one.
I'm receiving mixed signals on the web regarding preferred REST API authentication/authorization mechanisms, especially for mobile applications.
There is OAuth 1.0, but it's claimed to be more complicated than it needs to be and doesn't support native clients too well (callback URLs are very browser-centric). On the other hand, there is one major provider that supports it (Twitter).
Then there is OAuth 2.0, which is supposed to be an improvement over 1.0, and it gets rid of client-side crypto in it default incantation (replaced with bearer tokens), but some people are of the opinion that it's broken by design, and bearer tokens are no better than cookies. An SSL certificate from a sketchy provider can trick a mobile client more easily into believing that the endpoint is a trusted authority. However two major providers (Google and Facebook) support it.
And then there are people, who advocate sidestepping the whole mess and rolling your own.
So which is it?
This is going to sound like a hedge, but the answer is "whatever is appropriate for your application".
3rd-party authentication systems like OAuth and OpenID have their place, and they are perfect for some applications, especially for the kinds of systems that would allow clients to become API users without having to fork over their personal credentials to yet another server system.
However, you might be building a system that doesn't have that constraint or requirement, and it may be reasonable to ask your clients to simply create an account on your server. In that case, you can probably simplify things dramatically by using HTTPS and Basic Auth. Have the client pass their username/password in the appropriate header and ensure that your connection is SSL-protected. Or, have the client use a certificate for their credentials.
I would suggest you start by enumerating what "security" means to you, and work from the ground up. Consider every related facet like integrity guarantees, non-repudiation, replay protection, client impact, performance and API usability. From there, figure out if all you need is HTTPS/basic auth, or if you also need to add API keys, OAuth, OpenID, checksums, etc.
I'd recommend OAuth 2, but with additional certificate checks in the clients. If your certificate comes from Verisign, then invalidate all certificates from other CAs. Make sure to always get your certificates at the same CA though, unless you like distributing updates.
In the end, however, only a client can verify that the connection to the server is completely safe. Never forget that.
As part of strengthening session authentication security for a site that I am building, I am trying to compile a list of the best ways to register a user's computer as a second tier of validation - that is in addition to the standard username/password login, of course. Typical ways of registering a user's computer are by setting a cookie and or IP address validation. As prevalent as mobile computing is, IP mapping is less and less a reliable identifier. Security settings and internet security & system optimization software can make it difficult to keep a cookie in place for very long.
Are there any other methods that can be used for establishing a more reliable computer registration that doesn't require the user to add exceptions to the various cookie deleting software?
If you're looking to do device authentication, you may want to consider mutually authenticated SSL. Here, you'd deploy a client identity certificate to each endpoint you'd want to authenticate. Then, you set the server up to require client authentication, so that a client would need to present a valid identity certificate in order to form the SSL tunnel.
This, of course, is not a perfect solution. In reality, this presents much of the same weaknesses as other solutions (to various degrees) Once your client identity certificates go to your clients, they are out of your control; should a client give their certificate to anyone else, you lost the device authentication that you have based on it. SSL identity certificates are generally stored in a keystore on the client which is encrypted with a password or other credential needed to unlock them. While a client certificate could still be compromised, it's somewhat stronger that just a cookie or something like that (assuming you don't have a client that is trying to give away its credential). In addition, you'd want to come up with some validation routine that a client would need to go though in order to get a credential in the first place (how do I know that this is a client device that I want to remember/register?).
Remember, these types of approaches only do device authentication, not users. There are more in-depth schemes already developed for device authentication than what I've mentioned; for example, 802.1x is a network protocol where an endpoint needs to present a client-side certificate to the network switch to get on a LAN. This is out-of-scope for a web application scenario, like what you've described, but the idea is the same (put a cryptographic credential on the client and validate it to establish the connection).
This, like all other security matters really, is a risk decision. What are you trying to accomplish with such a countermeasure? What are the threats you're trying to prevent and what are the consequences if someone does log in on an unregistered device? Only your situation can answer those questions and let you see the real risk, if you need/should mitigate it, and, if so, how strong of a solution do you need to get the risk level down to an acceptable level?
the best ways to register a user's computer as a second tier of
validation
From my point of view this approach does not offer much in the aspect of authentication.
You are not authenticating a user and have no idea who is using the PC that you would accept as being registered.
The way you describe it, this step should be a configuration rule in the firewall to accept connections from specific IPs only.
IMO the filtering of the PCs is the responsibility of a firewall and it would be much better handled by the firewall than any application level filtering.
Just think that you would have the overhead in your application to examine each request and decide whether to accept it or not.
Better leave this preprocessing overhead to the firewall. That's why it is there.
Is there any reason why I shouldn't use cookies/sessions for native mobile applications, usually used by browsers, to authenticate with my server and for subsequent API calls?
Clarification: It seems the de-facto method of authentication on mobile clients is token based systems like OAuth/XAuth. Why don't traditional browser methods suffice?
This depends on your application (your threat scenario to be more exact).
Some of the most common threats are
- eavesdropping (-> should encrypt)
- man in the middle (-> must authenticate other party)
- ...what are yours? (how secure is your cookie store,....)
A cookie at first only holds a token as proof that sometime you have successfully made an authentication. If the cookie is valid long enough or transport not encrypted, there is a good chance that someone someday will find out...
In addition you must take into account what additional security measures are in place, at first and most important SSL.
What is your authentication method (what credential does a client need to logon)? Do you have the possibility to work with authentication based on PPK infrastructure or is the communication "ad-hoc"?
EDIT
Wrt. to OpenAuth: as far as i understood the protocol its main concern is authentication delegation. A scenario where you authorize an agent to do some very specific task on behalf of another identity. This way you dont scatter your credentials all over the web. If you have OpenAuth in place, a client can use the protocol directly, too. So why bother adding another. But OpenAuth explicitly states that with a direct client scenario you again run into security issues as now the token is available on the device and must be protected accordingly (as you must do with your cookie).