The password-reset paradox

Debra L Cook dcook at cs.columbia.edu
Sun Feb 22 17:00:35 EST 2009



On Fri, 20 Feb 2009, Jerry Leichter wrote:

> On Feb 19, 2009, at 8:36 AM, Peter Gutmann wrote:
>
>> There are a variety of password cost-estimation surveys floating around 
>> that
>> put the cost of password resets at $100-200 per user per year, depending on
>> which survey you use (Gartner says so, it must be true).
>> 
>> 
>> You can get OTP tokens as little as $5.  Barely anyone uses them.
>> 
>> Can anyone explain why, if the cost of password resets is so high, banks 
>> and
>> the like don't want to spend $5 (plus one-off background infrastructure 
>> costs
>> and whatnot) on a token like this?
>> 
>> (My guess is that the password-reset cost estimates are coming from the 
>> same
>> place as software and music piracy figures, but I'd still be interested in 
>> any
>> information anyone can provide).
> I suspect some very biased analysis.  For example, people who really need 
> their passwords reset regularly will probably lose their tokens just as 
> regularly.  The cost of replacing one of those is high - not for the token 
> itself, but for the administrative costs, which *must* be higher than for a 
> password reset since they include all the work in a password reset (properly 
> authenticating user/identifying account probably contribute the largest 
> costs), plus all the costs of physically obtaining, registering, and 
> distributing a replacement token - plus any implied costs due to the delays 
> needed to physically deliver the token versus the potential for an 
> instantaneous reset.
>
> I suppose the $100-$200 estimate might make sense for an organization that 
> actually does password resets in a secure, carefully managed fashion. 
> Frankly ... I, personally, have never seen such an organization.  Password 
> resets these days are mainly automated, with authentication and 
> identification based on very weak secondary security questions.  Even 
> organizations you'd expect to be secure "authenticate" password reset 
> requests based entirely on public information (e.g., if you know the name and 
> badge number of an employee and the right help desk to call, you can get the 
> password reset).  New passwords are typically delivered by unsecured email. 
> All too many organizations reset to a fixed, known value.
>
> It's quite true that organizations have found the costs of password resets to 
> be too high.  What they've generally done is saved money on the reset process 
> itself, pushing the cost out into whatever budgets will get hit as by the 
> resulting security breaches.
>                                                       -- Jerry
>
>> 
>> Peter.
>>

There is nothing technical in the following, but I wanted to reply because 
the cost issue isn't the only reason. The format of the token and user
interface are just as important. Think of a user with multiple accounts and
how to have the tokens on a single device with a single user interface 
when the banks don't use the same token vendor.

For large banks, cost was cited as a reason - both for deployment and 
synchronizations/replacements. Another issue is that even with banks and
brokerage firms in the US that offer tokens to customers, the bank thinks in
term of the customer having a token for one bank (itself) and not the 
inconvenience that a token per bank places on a customer. Also, in a 
consumer scenario as opposed to a work scenario, the consumer wants to be able to 
log into his/her bank account regardless of physical location and PC/laptop.

In a study I did last year with middle-age, well-educated adults, the average number of bank and brokerage accounts accessed online was 6. 
One person had 20. No one wanted to carry around multiple hardware tokens 
in case they need to access an account from someplace other than home. No one wanted a cup 
full of hardware tokens next to their PC at home. For banks that require 
certain customers (such as those with an account below some minimum 
balance) pay for their token, no one wants to pay $15-$25 every couple years for a single token when they don't 
understand what it provides over a static password.
Without commenting on security of software implementations, software-based 
tokens offered for browsers and cell phones get rid of the hardware issue 
for users. Broswer-based tokens don't solve the problem of users wanting 
to log in from anywhere. Tokens on cell phones are more promising in 
terms of human factors if the user is not required to install a different application for every bank account and has a standard
interface to all the tokens, and has a way of migrating tokens to a new 
cell phone. However, what I've seen so far are vendors charging a small
licensing fee per token per a specific number of years. Thus the bank 
either needs to cover the cost or a user pays a fee for every token every 
couple of years. To deploy tokens, the bank will need to either install 
and start the tokens on the cell phone for the customer or expect a large 
percentage of calls to a help desk. An alternative of having an OTP 
delivered to the user's cell phone on an as needed basis and 
eliminating the user from possessing a token isn't acceptable to users 
because a user doesn't always have cell phone connectivity - there are 
users in somewhat dense surburban areas who don't have reliable cell phone 
service at home because they didn't want cell phone towers in their town.


In the study, participants were given a cell phone that ran 10 software 
based tokens on it (using OATH's HOTP) and a menu to access a list 
of the tokens. The participants were asked to register for online access then log into a 
mock bank account using each of 5 different methods. 4 methods were 
replications of existing methods used by US banks, of which two used 
ad-hoc methods in addition to the password. The fifth method used a 
pin+OTP from the token. The registration for the token method required the user 
enter a login name, a pin of their choosing and 8 character value into a 
web page then enter the 8 digits into the token on the cell phone to seed 
it. This was to see if users could complete a series of simple steps to initialize a token.
Each participant was walked through the instructions (which also appeared on the web pages they were using to register and log in) then left to
complete the 5 methods. In a set of participants with graduate degrees in 
math and cs, and who each uses a hardware token at work, 25% had to ask for help with the 
token. It was worse with a general population of adults.

- Debbie Cook

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list