I'd like to know if it is possible to have a secure single sign-on across two webservices of which 1 is more secure than the other. To be more specific, less secure would be vbulletin forum and the more secure one a webservice, where real money is earned, withdrawn etc. For the sake of convenience for the users I would like to implement a secure single sign-on, but looking at the vbulletin's security track record, especially xss vulnerabilities, even sql injection, then I'm not sure if sso will be a viable option if it would degrades security of the more secure service.
It may be permissible to use a high-assurance credential to authenticate to a low-assurance system provided that long-term shared authentication secrets are not revealed to the low-assurance system (see, e.g., NIST Special Publication 800-63, Level-2 and above). This generally requires an assertion (e.g., SAML) from the Credential Service Provider to the Relying Party. The CSP, which is trusted, accepts the credential and asserts its authenticity, and possibly other attributes associated with the Subscriber, to the relying party (the application), which is not trusted. Since secret tokens associated with the credential (e.g., a password) are never sent to the relying party, a breach in that service would not provide an attacker with useful knowledge to attack the high-assurance system. There are a number of industry standards, such as OpenID and OATH, for credential federation in this manner.
Stop inventing your own sign-on systems. Use OpenID like StackOverflow itself does. That will solve your problem neatly and your users will be hugely pleased with you for not forcing them to remember yet another password.
Related
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.
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).
We're developing a REST API to be consumed by a couple of mobile applications. It's important that we're able to trust the identities of these mobile applications. In our current design, each API call is authenticated with an "API Key" parameter and secured with HTTPS.
My concern is that the API Key is embedded within each copy of the mobile app, which means there's no way we can keep it secret. It will be on thousands of phones, and theoretically any hacker with a binary editor or HTTP Traffic analyzer could extract the API key and then 'pose as' one of the applications, sending us requests that we'd have no choice but to trust. Client certificates would appear to have the same risk.
Is there an architecture that solves this problem?
It is being discussed from time to time in different places including StackOverflow. In brief - whatever you put to user's possession is not yours anymore. You can obfuscate the private key, of course, yet I see at least three ways to bypass your security measures.
The only way to solve a problem could be to employ cryptographic device (smartcard or USB cryptotoken) which keeps private and secret keys and doesn't let them out, however with handhelds use of such devices is quite complicated (if not impossible) from both technical and usability points of view.
Also you might want to reconsider your approach and let any client software use the service given that they pay for it. And your server will authenticate users and not software. Then the topic of keeping login data secret will be users' task.
Is this something that can be used for highly secure information or should it be bypassed for a single site authentication system? This may be a stupid question (as it does not sound secure) but I would like some advice.
OpenID itself is no less secure than the traditional username+password login.
Obviously, you're entrusting a large part of the security to the provider - e.g. brute force prevention, password size policy, etc.
Wouldn't use it for online banking for example, not while the OpenID protocol itself is insecure, but due to the use case.
highly secure information
Financial info? DoD Top Secret? Really secure information isn't available via the internet, only on the local network or through a VPN, which is moving a chunk of the security to the network level. Really really secure information is on a computer with no network connection...
There is the theory that the user, having just one password to use for their OpenID account, has the possibility to choose a decent strength password, less likely when they have to remember x passwords.
OpenID is technically sound, but can be baffling for some users. I recommend browsing through the responses to this question. For very private information I would be cautious about using OpenID because:
Since the login is being used so widely and so frequently there are more opportunities for the password to be accidentally disclosed. A particular worry would be if another OpenID-enabled site which the user is registered on one day asks them for their actual password...some users might enter it without thinking, not realizing that they are circumventing the OpenId security model.
If you have doubts about the security of OpenID, users might also have these doubts. From a business point of view, is it worth the risk of being perceived as insecure? (Of course, this is at least better than the other way around -- bad security being perceived as safe!)
There is a trend towards offering OpenID login on social networking sites and such, but I doubt we will see it being adopted very much for protecting extremely sensitive data.
OpenID itself is secure, however due to its decentralised nature it often assumes that three servers are "trusted". If these servers are not trustworthy then your security is gone.
For instance, if you use your own website as an identifier but delegate authentication to a 3rd party provider, then if your website, or the identity provider, or the consumer server is penetrated, then the information is not secure.
If you want to use OpenID internally, and use only your own secure server as an OpenID provider, then you should be pretty secure. But if you want people to "bring their own OpenID account" then OpenID is not the right choice.
In general, it's not really any more o less secure than normal user/password authentication, but with one major difference (IMO). OpenID allows a user to login via multiple different methods (Google, AOL, Yahoo, etc..). If someone were to crack it, they'd have to go after each individual service. You have the option to not allow certain services to participate, in the event you found one of them to be less secure.
I'm proposing the use of SAML 1.1 as technology to prove Web SSO in a customer environment, and they asked me something interesting:
Which scenario Browser/POST profile is appropriate, and which scenarios Browser/Artifact profile of SAML is appropriate?
In fact, SAML 1.1 Specifications don´t talk about the best neither most appropriate scenario for both Browser profiles.
Maybe security threats of each one can be used to pick up the best. In my vision, both can be applyed equally in any scenario so far.
*Note: The solution uses Weblogic Server 10.0 and its support to SAML 1.1.
It seemed to me that both profiles offer similar levels of security. With the POST profile, the user has to explicitly initiate the POST. This might help to thwart something along the lines of a CSRF attack, but I don't know of any actual exploits. The Artifact profile, with its use of the GET method, can provide a more seamless experience for the user.
For me, the drawback to the Artifact profile is the complexity in opening the back channel. My application server dedicates a thread to handling the user request, and if that thread is blocked (waiting for the back-channel IO to complete) for very long, the app server begins to perform very poorly. So, the back-channel communication has to be performed very carefully to ensure that it times out after a defined period of time.
Even then, if the IdP is down having trouble, it's not as obvious to my users that the fault is at the IdP. With a POST profile, if the IdP is misbehaving, users are less likely to blame me.
In terms of security, the main difference is that, with POST profile, the SAML response (containing the assertion) travels via the end-user's browser, so it MUST be at least signed, and possibly encrypted, if there's anything you wouldn't want the end-user to be able to see.
With the artifact profile, you can use SSL to secure the back-channel and send an unsigned, unencrypted assertion, since it is passed directly from the IdP to the SP. You may still want to sign the assertion for non-repudiation, though.
As Erickson mentions, though, setting up the outbound 'back-channel' connection from the SP to the IdP comes with its own challenges. Most SAML deployments I've seen use POST for this reason.
BTW - any reason you're using SAML 1.1 rather than 2.0?