That cartoon also generated some interesting discussion at the SANS Internet Storm Center, including some good suggestions for strong-yet-memorable-and-typable passwords:
That SANS write-up also includes a link to another cartoon along the theme of the human being the weakest link in information security. No matter how good security technologies and IT people get at thwarting attacks, it is more and more important for people to use good judgement about giving up their credentials. A call from the "help desk" or an email from "Webmail Team" can be a pretty effective way to crack a password. People are getting better at smelling phish, but the phisers are getting better at cooking them, too. So we need to be thinking about something that can't be cracked, is useless if intercepted, doesn't impose unacceptable inconvenience or cost, and can't be revealed to a phisher.
On Aug 15, 2011, at 11:22 AM, Sam Hooker wrote:
> On 20110815 10:37 , David Houston wrote:
>> I saw the original Andrew posted a while back and I actually do have some
>> SAA type techie questions, as that "cartoon" challenged some of what I
>> thought I knew about passwords. Specifically: is a higher entropy a good
>> thing? And does such a phrase as is used there lead to that? I poked
> Higher entropy is a good thing inasmuch as "higher entropy", in this
> case, represents more randomness*, and we're playing a game of numbers,
> here. Whereas historical password-quality recommendations were designed
> only to minimize the chances that a human would guess the secret, modern
> secrets must be difficult for computers to "guess". This basically comes
> down to lowering the likelihood that a process (running on one or more
> computers) will match the secret as it iterates through some algorithm.
> In other words, we're not *preventing* an automated process from coming
> up with the secret, just rendering it as unlikely as possible.
> * Go ahead: Argue about what "randomness" means.
> So, basically, you pick a reasonable-seeming "guess rate" (Randall chose
> 1000/sec; arbitrary), assign an entropy value to each aspect of the
> password (between 0.6 and 1.5 bits per letter, a bit for each property
> like "capital or not", a bit for "four vs. A", a bit for the ordering of
> a tuple, three bits for "a random digit between 0 and 9, etc.), tot it
> all up, and do the math.
>> So, the SAA techie questions above, and, is a coupled, plain
>> english/letters phrase, a good idea or a bad idea?
> I'm in favor of anything that realistically helps each user maintain
> secrets with higher entropy. If that means passphrases rather than
> passwords, awesome.
>> And is there any online "entropy calculator" available?
> There appear to be several. Insert standard caution against inputting
> one's NetID password into foreign websites, here. ;-)
>  hate to go to Wikipedia, but there it is:
> Sam Hooker | [log in to unmask]
> Systems Architecture and Administration
> Enterprise Technology Services
> The University of Vermont
>> On Mon, 15 Aug 2011, Carol Caldwell-Edmonds intoned:
>> CC:regarding the PS Ben sent:
>> CC:from that paper:
>> CC:CONCLUSIONS AND A WAY FORWARD
>> CC:We have looked in detail at a snapshot of events for a
>> CC:sample of password users; but every minute taken in
>> CC:unnecessary password use needs to be multiplied by orders
>> CC:of magnitude to account for all the password uses even
>> CC:within one organisation. This is the true cost of unusable
>> CC:password policies. *Against the world-view that "if only
>> CC:[users] understood the dangers, they would behave
>> CC:differently" , we argue that "if only security managers
>> CC:understood the true costs for users and the organisation,
>> CC:they would set policies differently". We conclude with
>> CC:some suggestions for how this might be achieved.*
>> CC:Towards Holistic Password Policies
>> CC:The vision of a holistic approach for security policies is not
>> CC:new; Sasse et al.  outlined what such a policy should
>> CC:contain. In moving to a holistic approach, there is no single
>> CC:ideal policy, as the ongoing debate about writing passwords
>> CC:down [12, 17] indicate.
>> CC:*Focussing on frequency of password changing, or password
>> CC:strength, without considering the user in their context of
>> CC:work, is clearly not holistic.*..
>> CC:So, there's the research, and if we take a data-informed-decision-making
>> CC:process seriously, then the role of client services in IT changes from being
>> CC:merely the fire rescue team, into the far more professional role of
>> CC:intermediary/translator/data collector between the two groups in the
>> CC:conclusion: the system administrators, and the users.
>> CC:Oh, sorry, I'm awake again...it was a nice dream, anyway. Back to the fire
>> CC:Carol Caldwell-Edmonds, IT Professional Senior
>> CC:Enterprise Technology Services: Client Services
>> CC:Helpline and Computer Depot Clinic Coordinator
>> CC:University of Vermont
>> CC:[log in to unmask]
>> CC:avatar by Shannon Edmonds
>> CC:never take yourself TOO seriously...
>> CC:artwork by Shannon Edmonds
>> CC:On 8/15/2011 10:14 AM, Benjamin Coddington wrote:
>> CC:> For the record, I think Scott Adams is the /real/ prophet:
>> CC:> http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/1000/700/1782/1782.strip.gif
>> CC:> Ben
>> CC:> PS
>> CC:> Here's a source study for True Cost:
>> CC:> http://www.cl.cam.ac.uk/~rja14/shb10/
>> CC:> http://www.cl.cam.ac.uk/~rja14/shb10/angela2.pdf
>> CC:> On Aug 15, 2011, at 9:56 AM, Andrew Hendrickson wrote:
>> CC:> > Unless the math is faulty, this comic, sent to me by an unnamed
>> CC:> > colleague, makes an interesting point regarding passwords:
>> CC:> >
>> CC:> > http://www.xkcd.com/936/
>> CC:> >
>> CC:> > Discuss amongst yourselves, I'll get coffee . . .
>> CC:> >
>> CC:> > Andrew Hendrickson
>> CC:> > CAS, IT Administrator
>> CC:> > UVM, College of Arts& Sciences
>> CC:> > 438 College Street #402
>> CC:> > Burlington, VT
>> CC:> > 05405
>> CC:> >
>> CC:> > 802-656-7971
>> CC:> > 802-656-4529 (fax)
>> CC:> >
>> CC:> > [log in to unmask]
>> CC:> >
>> CC:> > To submit a request for service please use:
>> CC:> > http://footprints.uvm.edu/ashelp.html