First things first: Facebook asked some users to provide the passwords to their email accounts when they were signing up for a new Facebook account in order to verify the users were using their own email addresses. When questioned about it, Facebook acknowledged this wasn’t ideal, and has promised to stop the practice.
“A very small group of people have the option of entering their email password to verify their account when they sign up for Facebook for the first time,” a Facebook spokesperson said. “That said, we understand the password verification option isn't the best way to go about this, so we are going to stop offering it.”
The fact that Facebook was prompting users for their email address goes against what gets taught in Security Training 101: Never, ever, enter your password anywhere other than the site/application it belongs to. Facebook said it wasn’t storing the passwords—“These passwords are not stored by Facebook,” said the spokesperson—but could not explain why it asked for the password in the first place.
What Facebook was doing, or hoped to accomplish, is perplexing and the fact that no one seems to have considered this may raise some alarms is downright mystifying.
The initial idea—validating email addresses—is a good one. When users create accounts online, they are generally asked to verify the email address to confirm they entered it correctly (and also to confirm it’s their address). The process is frequently a link sent to the user’s email, or in some cases, a numeric code that needs to be copied from the message and into the online service’s confirmation form. Confirming email addresses is good account management, and the social media giant appears to be trying to streamline the process so that users didn't have to switch back and forth between Facebook and email.
The implementation is where good intentions seem to have gone awry.
Multiple Workflows
One side appears to be well-thought out. For users signing up with Gmail, Facebook showed a prompt explaining the email needed to be validated, and then encouraged users to login to Gmail. The workflow here is appropriate, because Facebook passed control of the login process to Google. There was no question of Facebook seeing the Gmail password.
So if the email provider supported OAuth, then Facebook let the email provider take over. That's practical, and good security.
What's not immediately obvious is that the user still got an validation email, so there is still an option to go back to the email instead of logging in here.
This process just saved the user the extra step of opening up a separate browser tab/window to log into email. It's not a huge difference in time and effort, but from the company's perspective, the sooner the user is on the site and engaging, the better.
In the case of a Gmail account, Facebook let Google handle the authentication process. If the email provider supported OAuth, then the provider controlled the process.
The scenario where the provider does not support OAuth is where things really start unraveling. Twitter user e-Sushi originally saw the modal window asking for the email password. This was because the email provider didn't support OAuth. It isn't very clear from this screen there was an alternate method—that the site had sent a traditional "verify your account" link to the email address—nor is it obvious that just clicking on the username on the top of the screen dismisses the password prompt entirely and gets users to the site.
Enterprise security teams tell users, "Don't give any site your password!" Facebook's message, on the other hand, is, "If you want to use our site, you have to give us your email password." One lesson is going to stick better, and it might not be the correct one. What's even worse, if Facebook doesn't store the passwords, it doesn't actually need the string. If the site wasn't validating the string by logging the user in to the email account, then it really didn't matter what the user entered in that box.
The Facebook spokesperson said "a very small group" saw this prompt, and it appears to be true because continued testing showed a third validation path. Other users with email providers that didn't support OAuth saw a prompt to enter the code that had been emailed to them. This prompt handled the separation between the social media site and email accounts properly.
Fixing What Isn't Broken
Facebook, to its credit, has already turned off the password prompt and now asks users to enter the code sent to the email address. This action shouldn't have been necessary, as this exercise is a good example of why there is no need to tweak a process that wasn't broken. Email verification is a widely used and familiar process, so trying to streamline it seems unnecessary.
Users didn't see clear messages explaining what was happening and what problem was being solved. If the problem was that users weren't verifying their email addresses promptly, forcing them into the workflow is ham-handed. Reminders at the top of the user's page work just as well for other tasks, such as providing a phone number and updating the profile information, so it's curious that a different process had to be developed.
If there is one lesson from all of this, it's don't undermine the security training that users are getting to protect themselves from phishing and other threats. The harm is more widespread than any incremental benefit in user experience on a single site.
If the email provider didn't support OAuth, there was a different path for validating email. The password prompt has now been disabled and all users now see the prompt for the code.