Returning security back to the user
I am not a fan of apps encouraging users to sign up using their social network credentials. The other popular alternative is creating individual accounts on each service, but it has its own pitfalls. There are emerging techniques like password-less authenticators that help simplify and secure the process. This post reviews some of them.
You can use Google or another social network as an authenticator across as many of the apps one uses as a convenience. In this case, a breached social account means a quick path for the attacker to all of your other accounts. The solution to this is enabling multi-factor authentication, if available.
It just so happens that both Google and Facebook offer multi-factor authentication. While I believe they should be making it mandatory for all users, it is nevertheless a step in the right direction.
As a general rule, if your service provider is giving you an opportunity to enable multi-factor authentication, please do so!
Even with multi-factor enabled, you are risking a privacy breach. Any app authenticated against your social network account can potentially access data you don't want it to access via the social network's API. Even less nefarious situations can likely be treacherous: would you use a job seeker app using your Facebook credentials knowing that your employer could use Facebook API to examine your private life?
As unlikely as it may seem, a security breach at your social network provider can potentially allow an attacker to hijack all of your other accounts. This type of breach has already happened at Facebook:
Using social networks for single sign-on is very convenient, but I would discourage my readers from doing so. I would also advise app authors and companies against encouraging users from sign-in up for their services using social network authentication.
Users should be configuring a different set of credentials for each service. If an application offers you to log on using your social network account -- don't do it. Create a separate username, password, and the rest of the identity just for that service. This is a little bit better than using social authentication as single sign-on. The attacker may guess your password with one app, but they don't necessarily know of all the other services you may use.
The problem with this approach, however, is that unsophisticated users end up either using the same password or some derivation of it across all of their accounts. If one account is breached, the others are at risk as well. There are ways to mitigate this risk, however.
At the very least, users should rely on tools like iCloud KeyChain to generate and manage different random passwords for all accounts. In my household, we use 1Password for everything related to credential management, including secret questions the banks require. We also use 1Password for all multi-factor authentications.
Tools like 1Password create their own single sign-on mechanism but in a vastly more secure fashion that social networks. Explaining how it works is beyond the scope of this article -- it will be a whole other blog post. Suffice it to say, 1Password is well worth the cost -- it helps protect you and your family against online identity theft.
There is no perfect way to balance the convenience of single sign-on against social networks with the security of different passwords for each service. This is why some applications employ a password-less authentication model:
Ultimately, I think smartphone manufacturers like Apple should build a secure authenticator feature into the iOS -- while letting users override it. The iPhone can already use a biometric scan to identify the person, followed by a random token generated by the authenticator acting as a second factor.
1Password already partially works this way -- a user can unlock password vault using biometric, and then use a token generator to authenticate. This technology is likely to evolve in the coming years.
Using social networks as authenticators
You can use Google or another social network as an authenticator across as many of the apps one uses as a convenience. In this case, a breached social account means a quick path for the attacker to all of your other accounts. The solution to this is enabling multi-factor authentication, if available.
It just so happens that both Google and Facebook offer multi-factor authentication. While I believe they should be making it mandatory for all users, it is nevertheless a step in the right direction.
As a general rule, if your service provider is giving you an opportunity to enable multi-factor authentication, please do so!
Even with multi-factor enabled, you are risking a privacy breach. Any app authenticated against your social network account can potentially access data you don't want it to access via the social network's API. Even less nefarious situations can likely be treacherous: would you use a job seeker app using your Facebook credentials knowing that your employer could use Facebook API to examine your private life?
As unlikely as it may seem, a security breach at your social network provider can potentially allow an attacker to hijack all of your other accounts. This type of breach has already happened at Facebook:
Through this vulnerability, attackers were able to steal Facebook access tokens. An access token is a credential that can be used by an application to access an API. Its main purpose is to inform the API that the bearer of this token has been authorized to access the API and perform specific actions. In this case, an attacker could have used the Facebook access tokens to take over accounts.
Using social networks for single sign-on is very convenient, but I would discourage my readers from doing so. I would also advise app authors and companies against encouraging users from sign-in up for their services using social network authentication.
Creating a separate set of credentials on each service
Users should be configuring a different set of credentials for each service. If an application offers you to log on using your social network account -- don't do it. Create a separate username, password, and the rest of the identity just for that service. This is a little bit better than using social authentication as single sign-on. The attacker may guess your password with one app, but they don't necessarily know of all the other services you may use.
The problem with this approach, however, is that unsophisticated users end up either using the same password or some derivation of it across all of their accounts. If one account is breached, the others are at risk as well. There are ways to mitigate this risk, however.
At the very least, users should rely on tools like iCloud KeyChain to generate and manage different random passwords for all accounts. In my household, we use 1Password for everything related to credential management, including secret questions the banks require. We also use 1Password for all multi-factor authentications.
Tools like 1Password create their own single sign-on mechanism but in a vastly more secure fashion that social networks. Explaining how it works is beyond the scope of this article -- it will be a whole other blog post. Suffice it to say, 1Password is well worth the cost -- it helps protect you and your family against online identity theft.
Password-less authentication model
There is no perfect way to balance the convenience of single sign-on against social networks with the security of different passwords for each service. This is why some applications employ a password-less authentication model:
- Using email: instead of asking the user for a password, ask the user for email and then send them a one time code. The user then enters the token and is allowed into your application. As long as their email account is secure, this mechanism is no less reliable than the existing password reset flows. Email is notoriously insecure, however: just ask Hillary Clinton.
- Using SMS: the user uses their mobile phone number to sign up. The application sends a one time token to the phone using SMS, and when the user enters it, they are allowed into the app, similar to using email. Typically, the user would have to provide a secondary channel such as email in case they don't have access to their phone. SMS is an outdated protocol, however, and phone companies are authorized to log all messages being sent in plain text with questionable security. Furthermore, if a user is traveling and does not have roaming coverage SMS will either not work or cost $$$ to the end-user.
- Using a trusted authenticator app: the user is asked to install some trusted authenticator app. The user would have to sign up for your service using this authenticator app so it is registered with your system, which may involve creating a username and password one time. Your application can then use a secure channel to sync one-time tokens with this authenticator app and present them to the user. Such an approach is significantly more secure than both SMS and email. Ideally, the user is allowed to pick their own trusted authenticator app such as Google Authenticator or 1Password.
- Password-less authentication for signed in users: this is a hybrid approach in which a user is logged on to the application using one device and is trying to sign-on using another. In this case, a one time token is pushed to the existing session, and the user is asked to enter it in the new session.
Giving the user control over the credentials: smartphone as an authenticator
Ultimately, I think smartphone manufacturers like Apple should build a secure authenticator feature into the iOS -- while letting users override it. The iPhone can already use a biometric scan to identify the person, followed by a random token generated by the authenticator acting as a second factor.
1Password already partially works this way -- a user can unlock password vault using biometric, and then use a token generator to authenticate. This technology is likely to evolve in the coming years.