Main Nav

Hello All:

     We are currently updating our password policies to be more ISO complaint and I seem to be hitting a snag.  There seems to be little to no guidance on what “not vulnerable to dictionary attacks” really means. From what I can gather, there seem to be 3 different styles of dictionary checkers out there.  The lowest style seems to check if the password contains whole words: $password. Kind of a medium style strips all special/numeric characters and checks the remainder against the dictionary: pa$ss$wo$rd. The strongest seems to do a reverse l33t on the password to see if it was dictionary based: p@$$w0rd.  All of these are technically dictionary checkers and have obvious security vs. user supportability problems, but out of everyone out there, which style have you implemented?  Did you implement it across your entire organization or selected communities (Fac/Staff vs. Students for example).

 

Feel free to respond to me directly if you don’t wish to expose your inner workings.

 

Todd Dergenski

Old Dominion University

Senior Security Administrator

4700 Elkhorn Ave - Room 4300

Norfolk, Va, 23529 USA

 

(757) 683-4301

tdergens@odu.edu

Comments

Message from joel_avery@yahoo.ca

Hi Todd,

I've been in the IDM field a long time. Password dictionary checking has been around a long time - since the days of running "crack" on Unix. A lot of water has gone under the bridge since, but we still talk about defending this attack even though the dictionary we use is now far more complex.

In the past, I have used an IDM system where policies can be defined to restrict the maximum length of a sequence of characters. Say you set this part of the policy to be five and also require a password length of eight. Passwords now require the use of special characters and numbers to "break up" the password at character six. Technically, this will defeat the most simple dictionary attack since there are no obvious words of length eight in the English dictionary that contain both numbers and punctuation (at least, none come to mind) and I have had clients agree that this was sufficient.

Of course, this does not eliminate P@ssw0rd and neither does it answer your question.

As we all know, there are basic substitutions that are quite popular. From an entropy perspective, I believe it is better to have longer passwords with fewer rules as opposed to allowing short passwords with a complex series of rules which account for all the basic substitutions. I would suspect that once you tell people that a password is easier to remember when they use a sentence of minimum of 20 characters as a password and tell your ISO auditor that it is secure (as you have eliminated all words of less than 20 characters regardless of the common substitutions from the dictionary), everyone might be good with it. 

Where you want to be is that running a cracking tool will take longer to determine the password than your password expiry duration. 

Again, I am not answering your question - I am more proposing a means of eliminating a dictionary attack from being effective which is really what the ISO auditor should want.

For an example of what I mean where I have not checked the math, see http://xkcd.com/936/.

One caveat - if you are using password synchronization, you will most likely be limited on the length of a password by one of your systems. You might not be able to use a 20 character password - some system might have an upper bound of 12 (or less). 

As well, I have never been able to convince a client to go for a simple, but longer password. Every organization seems to have a policy requiring complexity put in place to defend dictionary attacks and no one wants to challenge the current wisdom of that somewhat dated approach.

Joel Avery

Providing Strategic Technology Planning for your Enterprise
http://www.linkedin.com/in/joelavery

From: "Dergenski, Todd A." <TDergens@ODU.EDU>
To: IDM@LISTSERV.EDUCAUSE.EDU
Sent: Monday, February 20, 2012 1:24:49 PM
Subject: [IDM] Internal Password Dictionary Check Guidelines

Hello All:
     We are currently updating our password policies to be more ISO complaint and I seem to be hitting a snag.  There seems to be little to no guidance on what “not vulnerable to dictionary attacks” really means. From what I can gather, there seem to be 3 different styles of dictionary checkers out there.  The lowest style seems to check if the password contains whole words: $password. Kind of a medium style strips all special/numeric characters and checks the remainder against the dictionary: pa$ss$wo$rd. The strongest seems to do a reverse l33t on the password to see if it was dictionary based: p@$$w0rd.  All of these are technically dictionary checkers and have obvious security vs. user supportability problems, but out of everyone out there, which style have you implemented?  Did you implement it across your entire organization or selected communities (Fac/Staff vs. Students for example).
 
Feel free to respond to me directly if you don’t wish to expose your inner workings.
 
Todd Dergenski
Old Dominion University
Senior Security Administrator
4700 Elkhorn Ave - Room 4300
Norfolk, Va, 23529 USA
 
(757) 683-4301


Message from bdavids1@gmu.edu

Todd, We have a website that is used by everyone for password changes, and we use CrackLib (http://sourceforge.net/projects/cracklib/) to check for dictionary words. It falls into the third category you mentioned. We're also using a huge dictionary that contains many "words" that you would never find in a traditional dictionary. The only policy difference for communities is password length. The papers I've managed to find on the subject suggest that "password" is the most commonly used password, and "Password1" is the most commonly *strong* password. IMO there's not much difference between not doing password checks, and doing them with a system that doesn't catch "Password1". The idea behind dictionary checks is to remove the low hanging fruit so that an attacker must perform an exhaustive brute force search that can't be as easily assisted by probabilistic attacks. A bigger problem is that the bad guys can just ask users for their password, and in far too many cases it will be provided. There's no password policy setting I'm aware of that fixes that problem... Brian Davidson George Mason University
Agreed on all points. With phishing scams getting even more sophisticated, password strength as the sole protection simply doesn't work. Some form of second factor has become one of the only ways to gain any type of assurance of the person on the other end. But, this does not change the ISO requirement to ensure your passwords are not vulnerable to dictionary attempts. As far as communities go, we are looking to localize the pain to users that have access to sensitive data. As you gain access to sensitive data, your complexity goes up on all. So, students will have the password1 type check while sensitive folks will have a P!!assword1 type check. We are building our checker to have even more capability (reverse l33t, previous password variation, personal blacklists, multi-language dictionaries) if the need arises. Todd Dergenski Old Dominion University Senior Security Administrator 4700 Elkhorn Ave - Room 4300 Norfolk, Va, 23529 USA (757) 683-4301 tdergens@odu.edu
ISO 27001 and 27002 reference password controls. Copies of the specifications are not freely available. 27002 section 11.3.1 discusses password use. Point d-3 of this section states that ...users should be advised to select quality passwords with sufficient minimum length which are: ...not vulnerable to dictionary attacks (i.e. do not consist of words included in dictionaries);... The current, relevant, ISO specifications do not mandate anti-dictionary checking to be implemented on the server side. Please note these specifications are currently being revised. New drafts were recently sent to reviewers this quarter. Current estimates are that final versions may appear 4th quarter 2012 or 1st quarter 2013. If you'd like more details, drop me a private note and I can tell you about my new job :) Paul (formerly an MIT employee) On 2/27/2012 10:58 AM, Tom Scavo wrote: >
Its buried in ISO's usual vagueness under 11.3.1: "not vulnerable to dictionary attacks (i.e. do not consist of words included in dictionaries);" There seems to be more implementations than discussions on what a dictionary checker should actually do. This is one of the few times ISO calls out a specific requirement. I've talked with a few auditors and other institutions about what "consist" means. $P@$$w0rd arguably consists of a dictionary word, P!!assword even more so, but it seems most implementations only really check for $Password. Is this sufficient for ISO and various other standards (InCommon Silver/Bronze)? Todd Dergenski Old Dominion University Senior Security Administrator 4700 Elkhorn Ave - Room 4300 Norfolk, Va, 23529 USA (757) 683-4301 tdergens@odu.edu -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tom Scavo Sent: Monday, February 27, 2012 10:59 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Internal Password Dictionary Check Guidelines
Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2015 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.