Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

It's clear there there is no consistent set of features among any of the popular authentication providers.

Below is an attempt to aggregate the similarities and differences I've noticed, but I would appreciate your advice on what additional features that are missing, and what are the important features to consider when looking at an outsourced provider.

Authentication

  • 2 Factor Authentication Per Session (Google, Verisign , MyOpenID)
    • Blackberry, Android, iPhone, application (Verisign, Google)
    • Text (MyOpenID , Google )
    • Voice (MyOpenID via PhoneFactor, Google)
    • Browser Certificates, and Physical Token (Verisign)
  • 2 Factor Authentication Per computer: Facebook
  • Beta (features subject to change) Yahoo 2/22/13
  • Force Password Change (LiveID every 72 days)

Privacy

  • Email Address Hidden/Not Shared (LiveID, ClickPass)
  • Offers a unique ID per website (ClickPass )
  • Information Sharing Controls (Yahoo, Facebook, Google, LiveID, LiveIDServices)

Forgot Password Feature

  • Most Secure (Google has Phone, OTP, and a difficult survey to fill out)

Delegation Support

  • Verisign
  • ClickPass
  • (many others)

SignIn Seal / SiteKey

View Authentication History

  • Full Logging of date, action, and target MyOpenID
  • Good logging but inefficient for auditing access Facebook
  • Limited to Grant and remove authentication Google, Yahoo

Active Session Summary

End user features

Supports Connected Accounts

Token Replay Protection

Connection Security

Question

Did I miss any important application features?
Are there some features I shouldn't pay attention to when comparing providers?

Some examples of additional information that is missing in this list include encryption specifics, ISO/SAS70 certification, or if the providers are using DNSSec. I could use help in gathering this information, and prioritizing what's important and not.

Please share additional info, or correct mistakes as you see fit.

share|improve this question
add comment

2 Answers

The right answer will clearly depend on your application.

For example, you've listed:

Option for "difficult" sign in process to improve security (Verisign), also see this related question

Using a provider like this would be a terrible choice for a site with low login security requirements and a strong desire for low barriers to entry in order to gain user base -- say a stackexchange or twitter. On the other hand it would be a benefit to a site that needs to perform financial transactions.

To some extent it will also depend on the combination of your users' preferences combined with the reputation of the provider. If you force users to use, say, Facebook, in order to sign up then you may lose users who have shunned Facebook. Or google -- they already have enough data about me, why would I want them to know every time I log in to your, say, dating site?

Lastly, I think one "feature" you are missing is the history of actual (versus promised) security. If a given provider has had a series of failures, it's likely they will continue to have failures. This is not to say that a provider with no known vulnerabilities will not have some exposed in the future.

share|improve this answer
add comment

A key issue when using an outsourced identity provider (IdP) is a position of trust. Do you trust them? The trust factor will take many forms and it is imperative that you walk your business sponsors through the advantages and disadvantages of federated trust models before going for it.

  1. Do you have an explicit or implied contract with the IdP? This is important because if your business relies on a third party IdP then you must ensure that the commercials are fully understood about what you can and can't do with the trusted identities and whether the IdP can pull the service without notice etc.
  2. You don't say whether the users are the general public or staff. If they are staff then you must consider the JML (joiners, leavers, movers) process and ensure that you have the associated processes in place to manage who is authorised to view what. Federation neatly solves a lot of the authentication - but none of the privileges and authorisation.
  3. You have listed some great federated mechanisms that are useful in public websites. If you are also federating with staff users (i.e. with your own identities) then you may need a SAML connector. You mention ADFS; which has had it's limitations in the past in terms of SAMLv2 compliance but is great if you use Active Directory as your IdP tool. The industry has a few major players such as Shibboleth (OSS) and Ping with their "Federate" tool. They also have a Ping Connect solution that's a bit cheaper. However, these are only needed if you are the IdP and using a third party service provider (SP). Ping, IBM and CA have federation tools but are at the more expensive end of the spectrum.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.