Password Management… A New Kind!

Sometimes we have epiphanies by connecting two things together.

While setting up my girlfriend's iPad, I remembered that with Exchange support, you have to change the password on the iPad at the same time as in the Windows session. That's the downside of the upside of Windows SSO.

It made me realize that the notion of changing passwords is only used in companies. Few "cloud" services force this kind of change on a regular basis. Imagine if Google required you to change your password every 60 days, as some companies do. There would be an outcry and people would gradually abandon Google's service. Surprise, surprise, people don't like managing passwords.

Back to my girlfriend's iPad: it would be possible to avoid the forced change if the iPad supported certificate authentication… That way, it's the device that handles authentication and not the person. In that case, it's essential to require the user to change the passcode on their iDevice at regular intervals. I've already talked about mitigating the risk associated with iDevices and I'll surely talk about it again in other posts. Note that Windows Mobile supports certificate authentication and that BlackBerry also relies on this approach to spare its users from the password change tied to the Windows password change… But they have to change their BlackBerry password at an equivalent interval. The net effect is basically zero.

Maybe it's worth going back to the reason why we change passwords. It's to ensure that if the password is discovered by chance or by brute force, its lifetime is limited according to the value of the information being protected.

Yet there are plenty of other ways to achieve the same thing without scratching users. For example, you could require password rotation every 120 days or 365 days. However, every failed authentication attempt cuts the remaining time by 30 days. A normal user will get it wrong once or twice now and then. So in the 120-day scenario, if I get it wrong twice, the time will be cut by 60 days. An attacker will have a very narrow window to find the right password, while the user will have to change their password sooner to counter an attack attempt, successful or not.

In enterprise systems, it's easy to access security events and spot attack attempts on an account. Even though it's not done regularly, inspecting event logs could greatly reduce a hostile user's ability to break network security. In cloud systems, since we don't have access to that information, operators would need to put measures in place to reduce the likelihood of someone forcing an account's security, while giving users the option to be notified when there are failed attempts.

The benefit of notifying users is that attacks will stop being hidden by cloud operators, and users will have an effective way of knowing when it's time to change their password. It's a form of awareness, as long as it isn't overdone.

The flip side, and because I don't know what goes on at cloud operators, is that the volume of information could be astronomical, flood the user and desensitize them to protecting their account.

With the growing use of these services, it's strongly recommended to put certain tools in users' hands to make this management easier. It would be even better if it were possible to have a single authentication source for a large portfolio of services.