One thing I'd like to reiterate and emphasize here is:
In my (and others) experience, people tend not to differentiate
between high and low value assets.
For most people, one password is hard enough: multiple passwords are
impossible to remember.
Consequently, rather than use separate passwords for their cheque
account and their wunderground.com settings, they use one easily
cracked password for all their logins, no matter how important or
trivial.
This tendency is, for me at least, the key virtue behind requiring
strong passwords even for apparently trivial logins. If your
wunderground.com password is cracked it's not that big a deal, but,
for many and perhaps most people, that same string enables access to
the parts of their life they really do care about.
This is true. Which is why password fields that you *can't* make
strong are evil. All password fields should at the very least *accept*
all typeable characters. To go to the trouble of entering a strong
password and then be told that you can only use upper and lower case
letters, or letters and numbers, or whatever, is just plain non-
sensical.
Pet peeve number 376...
kt
Katie Albers
Founder & Principal Consultant
FirstThought
User Experience Strategy & Project Management
310 356 7550
[email protected]
On Apr 16, 2009, at 10:38 AM, Brian Forte wrote:
Gentlefolk,
J Eric Townsend wrote:
I think that your security purists (love that phrase) need to
define the value of what you're protecting and determine an
appropriate set of password rules. Are you protecting my checking
account or my preferences at wunderground.com?
In my (and others) experience, people tend not to differentiate
between high and low value assets.
For most people, one password is hard enough: multiple passwords are
impossible to remember.
Consequently, rather than use separate passwords for their cheque
account and their wunderground.com settings, they use one easily
cracked password for all their logins, no matter how important or
trivial.
This tendency is, for me at least, the key virtue behind requiring
strong passwords even for apparently trivial logins. If your
wunderground.com password is cracked it's not that big a deal, but,
for many and perhaps most people, that same string enables access to
the parts of their life they really do care about.
I don't have a simple solution for this, BTW, but I keep hoping
keychains will both catch on and be better implemented.
A keychain (I'm using Apple's term here) is a central, encrypted
repository of passwords and usernames.
Mac OS X's Keychain is only barely OK but is at least a standard
part of the OS. Windows doesn't, so far as I'm aware, have an
equivalent (I don't count KeePass because it's not built-in) and the
situation on Linux is the usual 'choice is the ultimate value' mess.
There's the Gnome Keyring daemon plus the Seahorse front-end for
Gnome fans; KWallet for KDE aficianados; and KeePassX (KeePass re-
implemented with Qt) for folks who want to move their password
repositories from Linux to Windows and back again.
That said, I believe guaranteed-to-be-there keychains (a la the Mac
OS X Keychain) with better UIs would go some way to reducing user
hostility to strong passwords and might even make the job of
teaching their worth a little easier.
I use FIPS 181-compliant strings for my usernames and long (23+
characters wherever possible) quasi-random strings with punctuation
marks and the like for my passwords. And I use different strings for
username and password for every login I have, no matter how trivial.
This way, if one account is compromised, it doesn't affect any
other. (Also, while I appreciate the usability impulse, I get
vaguely irritated at systems that insist on using my e-mail address
for a username: even for security conscious me it's too much of a
pain to go back to running my own mail-server so I can easily
generate multiple e-mail addresses for use with such systems.)
Thanks to the Mac OS X keychain, this multitude of usernames and
passwords isn't difficult to remember, because I don't have to
remember them. I remember one (also long and strong) password and my
computer remembers the rest for me.
And this 'not having to remember because the computer remembers for
you' is key. Using that as my initial pitch, I've been able to sell
my family and a few friends, at least, on the virtues of this
approach. I know they don't take it as far as I do, but my wife (who
hates trying to remember random strings) did recently strengthen all
her 'important to me' passwords and even went to the trouble of
using a quasi-random password generator to make these half-dozen
strings different from each other.
That said, she had to use multiple UIs to do this (mostly multiple
web-sites), and only went to the trouble because she had one-on-one
interaction with someone (me) who convinced her the benefit
outweighed the hassle.
Sticking with Mac OS X for a moment, the tool she used to generate
the new passwords is the nifty, but absurdly difficult to get at,
Password Assistant, which is built-in to the OS.
Password Assistant is available via two applications that I'm aware
of: the Account PreferencePane and Keychain Access.app. For example:
Apple Menu > System Preference > Accounts, click Change Password...
then click the key next to the New Password text field to generate
the Password Assistant window. See <http://macosxhints.com/article.php?story=20050323104042259
> for a screenshot.
There's no public call available, however, although Adam Knight has
produced a little OSS app (it looks like a BSD-style license) that
uses private calls to call the window up: <http://codepoetry.net/products/passwordassistant
>. (I installed this app and put it in her dock, BTW, and yes, I'm
well aware this particular approach doesn't scale.)
You can't rely on a private call, of course. But making that little
windoid available via a public call would make it possible for
application developers to integrate the tool into password creation
and, by automatic extension, into the keychain. Get browser
developers to use this hypothetical public call and even web-based
logins could, potentially at least, call up the assistant.
All this is very Mac OS X-specific, of course, which raises the
whole 'platform-specific' vs 'cross-platform' problem, not to
mention its younger cousin: local vs remote storage and execution.
But something like the above -- getting the computer to store,
encrypt and recall your passwords as needed so you only have to
remember one strong password plus an integrated Password Assistant
equivalent that's part of password generation -- would be a better
UI than the current 'put text you'll have to remember later into
these fields' approach.
BTW, that one password you must remember is, by default, your login
password on Mac OS X. That's also the password used by default with
Keyring/Seahorse and KWallet. The practical upshot of which is that
logging in to your account unlocks your keychain/keyring/wallet. So
you don't even have to remember the password during an active
session. Cloud computing fans* would need to unlock a remote
keychain via an equivalent 'signing on' action. (*I'm not one of
them BTW. I'm old enough and cranky enough to think 'gee the
mainframe's back, my data's at the far end of a dodgy cable once
again and I'm supposed to believe this is an improvement?'.)
None of this would make people love passwords any better. It would,
I believe, increase the liklihood people would use them more
effectively. And it might even make them resent passwords a little
less.
Regards,
Brian Forte.
--
words, edits, type, layout, code
<mailto:[email protected]>
<http://betweenborders.com/>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [email protected]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [email protected]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
