Password Strength Requirements

15 Apr 2009 - 1:22pm
5 years ago
19 replies
5859 reads
Alan Cox
2009

Does anyone have any evidence, anecdotal or formal, about how
different password strength requirements impact the usability of a
web-based application?

There's a spectrum of different strength requirements. I've seen
sites that don't have any requirements, other than the password
exists. I've seen others that require the password to be at least
10 characters, with at least 1 lower case, 1 upper case, 1 digit, 1
"special" character (like #$@!), and then require the password to
be updated regularly while preventing reuse of old passwords.

Our security purists here want "really strong" passwords, though
not as strong as my second example above. I'm looking to see if
there's any knowledge out there about how different points on the
strength-spectrum impact usability. Is there a watershed spot where
if we make it more complicated than X, usability really suffers, but
all points less complicated than X are equally easy?

Thanks
Alan

Comments

16 Apr 2009 - 2:08am
Jabari Simmons
2009

Alan:

Start with the links in this thread:
http://www.ixda.org/discuss.php?post=33174.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41287

16 Apr 2009 - 2:56am
Yohan Creemers
2008

Hi Allan,

An approach could be, to advise users about choosing a strong
password, rather than forcing certain requirements.

In combination with this advise, you can show users the password
strength (poor, average, strong) of the password they are creating.
(I've an working example available if you want.)

- Yohan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41287

16 Apr 2009 - 2:59am
Michael Stiso
2006

I thoroughly dislike the ever-more bizarre combinations of
alphanumerics that are being required for passwords, even for sites
as simple as a forum. I found the article below after getting in a
heated discussion about the matter with the IT department of a
particular site. (It was the first hit on a google search of
"usability" and "passwords".)

http://www.baekdal.com/articles/Usability/password-security-usability/

Basically, the author discusses how passwords can be both more secure
and more usable by using a string of 2-3 common words rather than a
single word containing random alphanumerics.

I'm not sure it deals directly with your question regarding a
usability threshhold in password strength, but you may find it useful
for an alternative perspective on the issue.

Mike

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41287

16 Apr 2009 - 4:06am
Anonymous

The easiest way to deal with passwords is to allow them to be simple
so the user can remember them, and then apply other techniques - like
limit the number of successive attempts (to 3 or something), protect
the login with captcha etc. Complex passwords and/or forcing changes
regularly will just force the user to record the password somewhere
which is the greatest risk of all.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41287

16 Apr 2009 - 5:18am
Caroline Jarrett
2007

Alan Cox
>
> Does anyone have any evidence, anecdotal or formal,
> about how different password strength requirements
> impact the usability of a web-based application?
<snip>
>
> Our security purists here want "really strong" passwords
<snip>

At its heart, a request for a password is just another question on the form.
Your users' willingness to tangle with the question will depend on:

1. Who "you" are - how much they trust you, what the organisation is
offering etc
2. What users want to do - its importance to them, whether they can choose
to go elsewhere etc

If you look back at the previous thread, you'll see a protest that the
password process for a bank site was too easy - that's typical. It's also
typical for users to treat password processes with annoyance, contempt, and
bailouts if they think that they are inappropriate in the context of who is
asking for a password and what they want to do.

There isn't a 'sweet spot' that works for everything.

There may be a 'sweet spot' that works for your particular type of
application, your target users, and your organisation. To find out:

- Go and find other similar applications and organisations. Find out what
they do. Use that as inspiration for your design.
- Usability test and test again. Your users may be different, your offering
with certainly be slightly different (or very different), and the test
results will certainly help you in your discussions with the security
people.

Best
Caroline Jarrett
www.formsthatwork.com
"Forms that work: Designing web forms for usability" foreword by Steve Krug

16 Apr 2009 - 5:19am
dirtandrust
2008

We discussed this very issue in my department recently.

We decided that it's a balance between security and usability. What
typical user wants to have a password 10chars long with a capital
and a special character? A short list:

1. Someone going to their banking site
2. Someone accessing tax and other sensitive, identity theft prone
info
3. Someone checking their credit card balance

Etc.

Cases where password strength is less important:

1. Forums
2. Blogs
3. Non-sensitive, non personal information sites/areas

So you just have to weigh the situation objectively; how sensitive is
the information vs. how many times do you want users requesting their
forgotten password? :)

I agree that visual feedback for the password as it's entered is a
fantastic way to ease a user's frustration:

http://ui-patterns.com/pattern/PasswordStrengthMeter

P.S. Your Dev team should worry more about sql injection attacks and
denial of service rather than having super-secure passwords.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41287

16 Apr 2009 - 6:35am
Roundand
2009

You don't mention whether this is for an internal or external site - how
much choice do the users have to use an alternative with simpler
registration requirements?
If it is for an external site, have you considered using OpenID (
http://en.wikipedia.org/wiki/Openid)?

Francis.
--
"Tigers walk behind me, they're there to remind me - I'm lost but I'm not
afraid" David Byrne and Brian Eno: Life is long

16 Apr 2009 - 7:52am
Sean Phelan
2008

The more complex the password rules are the more likely people are to
get it wrong. As Yohan says some sort of visual feedback seems to be
the best solution to me, with a link to tips if the user is struggling
to understand your rules. The other think you may wish to consider is
how important is the data the user is giving you. I understand that
the bank password needs to be complex but does a record of the music
I have listened to need to be a secure?

Anyway example of Yohan and my suggestion...
https://www.google.com/accounts/NewAccount?continue=https://www.google.com/accounts/ManageAccount

Also the Open ID seems a good idea.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41287

16 Apr 2009 - 8:35am
Yohan Creemers
2008

The article on baekdal.com referred to by Michael is really worth
reading!

Here is another example of feedback on password strength
http://www.ylab.nl/lab/password/

- Yohan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41287

16 Apr 2009 - 10:07am
jet
2008

Alan Cox wrote:
> Does anyone have any evidence, anecdotal or formal, about how
> different password strength requirements impact the usability of a
> web-based application?

Tangental, but here's a great article by Bruce Scheneier on "Choosing
Secure Passwords" based on how people actually attack passwords:

<http://www.schneier.com/blog/archives/2007/01/choosing_secure.html>

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?

--
J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09

design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ
PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8

16 Apr 2009 - 12:38pm
Brian Forte
2004

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:bforte at betweenborders.com>
<http://betweenborders.com/>

16 Apr 2009 - 12:54pm
Katie Albers
2005

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
katie at firstthought.com

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:bforte at betweenborders.com>
> <http://betweenborders.com/>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

16 Apr 2009 - 11:31am
viki pandit
2009

I completely agree with Bruce here. Complex passwords and regular
expirations forces the user to record the password elsewhere which is
much greatest risk. Quite a few websites have sprung up who provide
password saving functionality, but I wouldnt be able to sleep
peacefully knowing that all my sensetive passwords are stored away on
a website, that may be open to exploitation.

I generally use a set of passwords across all my accounts. They
comprise of 3 levels of strength for different kinds of sites. The
strongest ones are for my email/bank accounts(which are different
variations for each). The second level are for most social networking
sites that are trustworthy. And a third password for sites that I dont
think are very dependable. The reason for this is that in a situation
a weak site compromises with your password it wouldnt affect my
important online accounts. This way its also easier to remember my
passwords and not have to run to my Keepass time and again everytime
i need to login.

Another thing I would like to share I would like to share here is how
I use my browser. Since its almost an OS for me now, I use the
portable versions of Firefox and Opera wherever I go. At home or
Office I am able to save my bookmarks and passwords on my encrypted
USB without leaving behind any trace or exploitable data.

vicki pandit | User Interface
merlinvicki at gmail.com | www.merlinvicki.in
http://twitter.com/merlinvicki

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41287

17 Apr 2009 - 8:19am
jet
2008

Katie Albers wrote:

> 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.

Completely agree. Requiring me to use a strong password for a critical
asset: good; preventing me from using a strong password: bad.

However, requiring appropriately strong passwords isn't worth anything
if you save my password in the clear and email it to me after I've
registered.

I think this is why it's important for design people to dip their toe
into the security pool just as "security purists" need to step back a
bit and think about usability.

--
J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09

design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ
PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8

17 Apr 2009 - 9:32am
Roland Studer
2008

Just some anectodal stuff from me:

You could mean Credit Card Companies would encourage strong passwords, but I
have encountered cases, where I couldn't enter my randomly generated
password, which was 20-32 characters long, as the maximum length was 16 :-)

I think a lot of password strength meters are flawed, as they might rate *
PASSword_1234* better than something like *if1vev7ryuc4mat7i8ov4cha5hia5hodd
*, just because mine wouldn't use a special character and uppercase letters,
so enforcing strict rules like what you stated doesn't necessarily ensure
strong passwords.

Have a good weekend!

--
avertas gmbh - user experience consultant

Ich helfe Ihnen Ihnen:
- Ihre Software/Website benutzerfreundlich zu gestalten
- Ihren Kunden ein "Wow" zu entlocken

mobile +41 79 746 48 59

On Wed, Apr 15, 2009 at 1:22 PM, Alan Cox <alan.cox at icontact.com> wrote:

> Does anyone have any evidence, anecdotal or formal, about how
> different password strength requirements impact the usability of a
> web-based application?
>
> There's a spectrum of different strength requirements. I've seen
> sites that don't have any requirements, other than the password
> exists. I've seen others that require the password to be at least
> 10 characters, with at least 1 lower case, 1 upper case, 1 digit, 1
> "special" character (like #$@!), and then require the password to
> be updated regularly while preventing reuse of old passwords.
>
> Our security purists here want "really strong" passwords, though
> not as strong as my second example above. I'm looking to see if
> there's any knowledge out there about how different points on the
> strength-spectrum impact usability. Is there a watershed spot where
> if we make it more complicated than X, usability really suffers, but
> all points less complicated than X are equally easy?
>
> Thanks
> Alan
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

18 Apr 2009 - 1:17am
Chris Novell
2009

I have read the prior replies and looked at the recommended links with
interest and have learned a lot - thanks, all!
I would like to suggest that a user could select a relatively strong
password and write down something close to the password. They would
then need to remember only what the modification is.
For example, a user could write down
milkanddairy when the password really is

milkanddairy& or
$milkanddairy or
milk&and&dairy or
MILK&AND&DAIRY or
zilkandzairy

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41287

18 Apr 2009 - 11:47am
Katie Albers
2005

I really don't think that's a good idea. I've never tested it, but my
gut says that:

1) if you use it so seldom you don't remember it, then you use it so
seldom you don't remember the modification (which of those variations
you proposed did I use? I should write it down)

2) if you use the unmodified version on sites that won't accept strong
passwords and it's cracked, or if someone finds your written down
password, then cracking the modified version is relatively simple

Anything where writing down a part of a password forms part of the
privacy solution is a bad idea. There are ways to make strong
passwords memorable; people should know what they are (and that
requires a fair amount of education on our part) and use them (which
requires consistently enabling strong passwords on our part). I
believe that our goal and the goal of the data security community
should be that everyone has a maximum of 3 strong passwords (to allow
for periodic switching) that can be used in all instances. But that's
beyond the scope of this question.

kt

Katie Albers
Founder & Principal Consultant
FirstThought
User Experience Strategy & Project Management
310 356 7550
katie at firstthought.com

On Apr 17, 2009, at 11:17 PM, Chris Novell wrote:

> I have read the prior replies and looked at the recommended links with
> interest and have learned a lot - thanks, all!
> I would like to suggest that a user could select a relatively strong
> password and write down something close to the password. They would
> then need to remember only what the modification is.
> For example, a user could write down
> milkanddairy when the password really is
>
> milkanddairy& or
> $milkanddairy or
> milk&and&dairy or
> MILK&AND&DAIRY or
> zilkandzairy
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=41287
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

18 Apr 2009 - 1:47pm
jet
2008

Lost in this discussion of password strength is, "how do we handle
multiple failed logins, forgotten passwords, and compromised passwords"?
If your overall design (is this where we get into service design?) is
put together correctly, a compromised password (or an attack on an
account) isn't the end of the world.

I worked at a US federal gov't site where the root/admin passwords were
printed out for the admins in a mutated form. They were then told an
algorithm that would un-mutate the password into something usable. If
the wrong password was used three times as root/admin on any system, the
system was locked down and security was notified. The passwords were
immediately rotated and new base/mutation pairs generated.

The goal was to give root/admin access to a large number of people
without sharing passwords across systems, and it ended up working pretty
well.

--
J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09

design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ
PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8

18 Apr 2009 - 2:44pm
Angel Marquez
2008

Sounds like encryption <http://en.wikipedia.org/wiki/Password_cracking> to
me like wep <http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy> on my
wireless network at home.
The systems in place have trained the way I choose passwords. I have a
standardized way. I can recall 4 systems at the moment, phone PW, OS login
platform1, OS login platform 2, web service.

1. For phone systems I just use numbers, alpha numeric...oh wait is that the
way it always is.

2 & 3. OS login I had to standardize my user name for personal use & am
often confused when an organization issues you one. OS password I have this
3 sets of 4 thing going or 4 sets of 2 depending on how many attempts locks
me out, just in case I forget, then I can try the variation without getting
the boot. I also use the same passwords for linux systems with a GUI and
just use caps lock to mask the password, so I don't even really know what it
is.

4. Web service, my favorite. Multiple email user names for multiple
services. Email as your username is the most efficient for any kind of error
recovery. You can be identified, traced, studied. I like it when I forget my
password and can just enter my email and am even more pleased if the new
password is not in the email confirmation but I am provided with a link that
opens up a web form that allows me to just pick a new password and verify
it. I think I use the same password method and have a secret internal
algorithm of when I use different sets and variations depending on the type
of site.

HOST un & pw...Entirely different story; but, totally organized convention
where encryption makes it strong for permissions, departments, business
units etc..

On Sat, Apr 18, 2009 at 11:47 AM, j. eric townsend <jet at flatline.net> wrote:

>
> Lost in this discussion of password strength is, "how do we handle multiple
> failed logins, forgotten passwords, and compromised passwords"? If your
> overall design (is this where we get into service design?) is put together
> correctly, a compromised password (or an attack on an account) isn't the end
> of the world.
>
> I worked at a US federal gov't site where the root/admin passwords were
> printed out for the admins in a mutated form. They were then told an
> algorithm that would un-mutate the password into something usable. If the
> wrong password was used three times as root/admin on any system, the system
> was locked down and security was notified. The passwords were immediately
> rotated and new base/mutation pairs generated.
>
> The goal was to give root/admin access to a large number of people without
> sharing passwords across systems, and it ended up working pretty well.
>
> --
> J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09
>
> design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ
> PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

Syndicate content Get the feed