By using a password, you actually give up security control and risk your users' data. Stop asking for one now. http://t.co/JUuLMcENBu— Markos Charatzas (@qnoid) February 22, 2014
Turns out if you buy a new iPhone, you are required to answer your security questions before making any purchases on the App Store with your Apple ID (Sunday, 22 December 2013 10:52). The password that you have already set up is not enough to verify your identity in this scenario.
Because this is the first time making a purchase on this device, you must verify your identity by answering the following questions before you can complete your purchase. If you have forgotten your answers, contact Customer Support
Not sure why Apple believes a password might have been compromised with the new device. Usually security questions are used as means to reset a password in case you have forgotten it. It's an alternative way to identify who you are. Unfortunately not as convenient as the password.
Security questions are usually more than one (personally have seen up to 8!) and the user rarely gets to choose what they are. Since their purpose is to identify the user, they are naturally "trying" to touch on personal, private data (i.e. favourite actor, personal hero, childhood nickname). Effectively the user is coerced into answering them, all too often choosing arbitrary answers via association or totally random characters. Because they are created at the same time the account is set up and rarely used the chances of forgetting them increases with every day passing by. In this case that was about 2 years ago.
So what if you do not answer?
You did not provide the correct answer to one or both of your security questions. If you continue to provide incorrect answers, your Apple ID will be locked and you will be unable to make any purchases while it remains locked.
If you have forgotten your answers, contact Customer Support.
If you fail to recall your security questions, then a combination of things like your date of birth, address, and 4 last digits of your credit card as entered in your profile is enough to prove who you are.
By the way, the account to this date has not been used to make a purchase on the App Store.
Have you forgotten your password?
Another way of identifying a user is via an email. The idea being that the user who set an email for her account, has secure and sole access to her email.
Let's see how that looks. An anonymous user requests to identify via email in order to access her account. That is a single prompt for her email address.
The assumption is that the user owns the email of her account, hence plausible to identify her.
The user enters her email,
the email contains a link that the user needs to follow to identify herself,
since the user has identified, can also create a new password to secure her account,
and access it.
Take a look at your stats and see how many of your users are using the forgotten password link or the percentage of users calling in due to having forgotten their password.
The truth is, no matter how secure a password can be, your users are most likely reusing them. As a result, security is no longer under your control.
Back in October 2013, Adobe's customers IDs and encrypted passwords were compromised. Less than 2 months later, Adobe's database of passwords was used to hack Github. Essentially, Adobe's leak compromised Github. Oh, let's not forget plain text offenders.
Enter password policies
Password policies are a best effort to keep passwords secure and as a side effect protect against compromises like Adobe's. However, a password policy can't guarantee that the password will be unique to your service and passwords that use common character substitution are equally vulnerable. Also, enforcing a strong policy can potentially harm user acquisition and will likely increase the chances of a user forgetting her password.
You don't need a password
Let's look back to the "forgotten password" cycle.
- An anonymous user wants to access her account.
- User asks to identify via email (forgotten password).
- User enters her email.
- User receives a verification link.
- User authenticates by following that verification link.
- User creates password.
- User is logged in.
Since most services now use long lived sessions, the user will rarely have to enter her password again. Yet just by using a password your service is vulnerable to attacks like Github's.
Let's think of better ways to identify a user instead
Email isn't designed for user identification. Google just recently bought SlickLogin. SlickLogin uses a distinct sound to identify a user. Apple already uses a fingerprint to identify a user on an iPhone 5S.
On mobile, you can use residence based authentication.
Every second you keep a password database around, you are putting your data and others' at risk. Stop asking your users to create a password.
Focus your efforts on how to best identify a user.
Update: Some metrics provided by Luke Wroblewski on passwords back in January 2012 and statistics on top three passwords. Some highlights:
- 86% of U.S. companies use password authentication.
- 70% of people do not use a unique password for each Web site.
- Around 82% of people have forgotten a password used on a Web site.
- Password recovery is the number one request to help desks for intranets that don’t have single sign-on portal capabilities. 2/3 of people with leaked accounts at both Sony and Gawker reused their passwords on both sites.