Re: petname implementation recommendation proposal

Regarding the password problem, it's even worse:  go look at a dozen 
sites which require passwords, and I guarantee you'll find conflicting 
password advice.  Some will require passwords contain punctuation, some 
will require that they do not contain any punctuation.  Some will 
require numbers, some prohibit numbers, etc.

So even if the user tried to make it easy to remember by using a few of 
the same passwords, this is often impossible due to conflicting 
guidelines.  So instead they end up forgetting passwords, and either 
give up on getting back into the website, are forced to reset the 
password every time, or they are forced to call customer service and 
cost the company lots of money.

serge

Stephen Farrell wrote:
> 
> 
> 
> Rachna Dhamija wrote:
>>
>>
>> On Tue, Mar 18, 2008 at 7:20 PM, Stephen Farrell 
>> <stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>> wrote:
>>
>>
>>     Just a side-question on this:
>>
>>     Rachna Dhamija wrote:
>>      > I would question the cognitive burden that it
>>      > places on users.  It requires the user to take extra effort in
>>     coming up
>>      > with a petname for a site, entering it, and then noticing and
>>      > recognizing it in the future.  This is not "cognitively scalable".
>>
>>     What does "cognitively scalable" mean? How well accepted is the
>>     term?
>>
>>
>> I've been using the term recently to refer to the burdens that 
>> authentication systems place on users.  We use "technical scalability" 
>> (e.g. bandwidth scalability) to refer to the ability for a system to 
>> grow or to expand in capacity.  
> 
> That's fine. I'd note though that with technical scalability, its
> also important to have systems/designs that can both scale up and
> scale down. (One of the lessons learned, e.g. with SSO systems is
> that they'll fail if there's just too much infrastructure needed
> before the 1st person logs in; DCE would be an example there.)
> 
>  > Similarly, we should think about our
>> users' cognitive capacity, whether it be the ability to recall 
>> information, visually notice indicators, recognize correct states, 
>> etc.  For example, passwords are usable if you consider a user 
>> interacting with one site at a time.  As you add websites that have 
>> different password policies, you increase the memory burden, but not 
>> the capacity of human memory to recall these passwords.  Users will 
>> either find a way to make systems work with their limited brain 
>> capacity (e.g. choose one password to reuse across sites), or they 
>> won't use them.  Similarly, Petnames requires a small amount of mental 
>> effort, and this work increases as you use it with more websites.  
>> Therefore, I would predict that users will only use it with a limited 
>> number of sites (which may be what is intended), or they won't use it.
> 
> Hmmm...Interesting. Would it make any sense to think in these
> terms about a user's understanding (or not understanding) of TLS?
> (Or OTP-tokens or other arcane authentication schemes?)
> 
> I guess I could be convinced that user's can get the idea that
> TLS sets up a secure pipe, that fewer users would understand
> what a certificate is about and very few would get the difference
> between different CAs.
> 
> On passwords, presumably complicated rules about password
> checks (mixed case, longer than N, no re-use) would also use up
> some calories.
> 
> So here's the question: could one form a metric from this as
> a way to compare different security schemes?
> 
> (Its ok to say that I'm being silly if that's the case.)
> 
>>     (Honestly, not being argumentative, but it feels like I could
>>     invent a different meaning for each beer offered;-)
>>
>> I'll try you at the next f2f :)
> 
> Unfortunately, it looks like I'll not be there (I've to go
> see some reindeer [1] that week:-)
> 
> Cheers,
> S.
> 
> [1] http://www.n4c.eu/wiki/index.php/Main_Page
> 
> 
> 

-- 
/*
PhD Candidate
Carnegie Mellon University

"Whoever said there's no such thing as a free lunch was never a grad 
student."

All views contained in this message, either expressed or implied, are 
the views of my employer, and not my own.
*/

Received on Wednesday, 19 March 2008 17:19:38 UTC