Louise Ferguson's website
home
blog
 
       

photo of Louise Ferguson

contact

location: London, UK

email: louise.ferguson -at- gmail.com

mobile: +44 (0)7810 260 637




Grab my RSS feed:

rss feed

or subscribe with Bloglines:

Subscribe with Bloglines





archives



other blogs I contribute to

grumpy old people
south-west usability group
ideal government


odds and sods

London bloggers tube map
MP3 blogs aggregator
userati
UXnet

 
City of Bits Blog
Usability, user experience, technology, ethnography, design, the workplace, e-government and public policy, from a UK perspective


Tuesday, October 12, 2004  

Security, service providers and cognitive limitations

In recent weeks, I've once again come across research reporting that computer users indulge in bad behaviour like writing down their userIDs or passwords, thus exposing themselves to all manner of risks.

And just as I was starting to write this post, I called a colleague who then had trouble with his logon for getting into his electronic diary.

I'm always surprised to see people being surprised by 'writing down passwords'. "Don't write down your passwords" strikes me as a fairly loopy guideline.

I recently calculated that I have at least 100 current logons related just to public online services and websites. There are a whole lot more related to various work projects. And just to gain access to one company network or email system may entail entering ten separate data items.

There are of course no standard ways of formatting logons, and most service or site providers consider only their own needs when setting their own paramenters. Hence, some insist on an email address as a user ID while others prohibit this, some issue a user ID that cannot be changed - such as customer number, staff number, a specific email address, your name including space - and some create arbitrary rules, such as no spaces, cannot be your name, no caps, mixed case, alpha only, numeric only, no symbols, certain symbols allowed.

When we get to passwords, even more rules rear their head: must be fewer than 7 characters, must be more than 8 characters, must contain numbers, must contain numerics in certain positions, must contain a mix of alpha and numeric, cannot be a proper name, cannot be a dictionary word, cannot be a postcode, is case sensitive, is not case sensitive, must contain a mix of upper and lower case, must be changed every x days/weeks/months, must be changed on a certain day.

The trouble is, there are no logons that will serve for more than a small proportion of the many required. And when the user is forced to change one password, this inevitably does not coincide with all the other password cycles. Meanwhile, company mergers, new clients, short-term projects, and my own decisions to move or add services create even more enforced changes and additions, often on a daily basis.

The result is that logons breed faster than the proverbial rabbits. I start with three or four, and before I know it I have 100 or 120.

But as I get older, my memory for long and meaningless strings is inevitably in decline. In any case, do I really want to hold all this dross in my head? So I now have a paper file, a ready reference of services, logons and instructions, that serves for all systems and all locations (even those where I'm not permitted to take my own computer equipment). Bad practice? Maybe. But I could not function without it.

My problem, as a user, is that each and every service/system provider thinks only of themselves when designing their system. I, on the other hand, have to deal with an ever-expanding variety of system/service providers, all doing their own thing. They perhaps believe we have nothing to do but remember their logons.

The most unsafe practices I've seen are in public workspaces, such as in healthcare, where passwords are handed around or even permanently stuck to unattended computer monitors in public spaces such as hospital wards. Which makes the UK NHS plan to put so much patient data on central or networked systems a little scary.

1:00 PM| link to this item | 0 comments
0 Comments:

Post a Comment

 
© louise ferguson 1999-2004