Serg Nvns - Fotolia
Facebook introduced a new feature to improve password recovery that is designed to do away with security questions and email verifications. The protocol is called Delegated Recovery, and it somehow relies on other verification systems for third-party accounts. How does Facebook Delegated Recovery work, and could something like it be beneficial to enterprises?
Knowledge-based authentication is a challenge-response method of verifying somebody's identity based on an agreed-upon set of shared secrets. A knowledge-based authentication (KBA) system is commonly used for self-service password recovery when a user forgets their password for an online service. KBA is popular because it's easy and cheap to implement; using KBA as a secondary means of authentication to enable users to reset their own passwords saves IT support a lot of time and money.
However, the assumption that somebody's identity can be confirmed if they know the correct answer to a secret question is flawed. A lot of the answers to users' shared secrets are common knowledge or can be easily obtained, and 99% of the answers can be found in a dictionary, and are far more guessable than an alphanumeric password.
Recovery emails and text messages are other common alternatives used to recover access to an online account, but they don't provide a sufficiently secure level of two-factor authentication. So what is the best way for a user to regain access to their account if they should lose their password, smartphone or security key?
Facebook is proposing that applications delegate account recovery permissions to third-party accounts controlled by the same user. Its new Delegated Recovery protocol is being trialed on the collaborative software development platform GitHub.
GitHub offers various two-factor authentication methods for account login. Previously, if a user lost access to their phone, physical token or key they used as a second factor of authentication, they could use a preregistered secondary mobile phone number or recovery code that they were responsible for keeping secure and accessible.
With Delegated Recovery, users can now use a digital token stored on Facebook as a possession factor to confirm their identity as part of the recovery process at GitHub. The token is encrypted and does not become valid until it's used in a recovery. This helps limit the impact of database dumps and SQL injection attacks. If the user needs to recover access to their GitHub account, they reauthenticate to Facebook, which will then send the token back to GitHub with a time-stamped counter-signature. This assertion from Facebook that the person attempting to recover the account is the same as the person who saved the token is sufficient to unlock the account. Facebook doesn't share any personal data with GitHub as part of this process.
Facebook initially deployed Delegated Recovery at GitHub to get feedback from the security community, including participants in their bug bounty programs. Facebook has also published open source reference implementations of the protocol in various programming languages to enable others to use it to build more secure account recovery processes.
From a user's perspective, it's essential to be able to choose a trusted recovery provider with strong security practices because if an account with them were to be compromised, the attacker would be able to use any digital token to obtain access to other accounts belonging to the user. For this reason, it may be necessary in the future to access multiple recovery providers to prove your identity during the account recovery process.
Web administrators should certainly look at replacing KBA if they use it, and once Facebook is confident it has a secure protocol, then Delegated Recovery may well be an option, particularly for those who do not have the resources or information to build a secure account recovery process. Delegating the function to network services that can offer high levels of security is one way to achieve a level of identity assurance without relying on fallible KBA questions, password hints and emailed resets.
Find out if there are any compliance regulations on biometric authentication systems
Learn how the Google Authenticator app's two-step verification system works
Read how insecure mobile app OAuth implementations could lead to attacks on user accounts
Dig Deeper on Web authentication and access control
Related Q&A from Michael Cobb
Sending sensitive information in attachments is inherently unsafe, and the main way to secure them -- encryption -- can be implemented inconsistently... Continue Reading
Spyware can steal mundane information, track a user's every move and everything in between. Read up on the types of spyware and how to best fix ... Continue Reading
Explore the differences between symmetric vs. asymmetric encryption algorithms, including common uses and examples of both, as well as their pros and... Continue Reading