Stong Passowrds - NOT!
Lohkee
The security community repeatedly tells us that a strong password will be
much more difficult for an attacker to break than will a weak one, and
because of this, we should encourage the use of strong passwords in order to
protect our systems from those who would attempt to gain unauthorized access
by cracking passwords. The wisdom of this advice is continually reinforced
by an army of security consultants who are more than happy to demonstrate
the ease with which commonly available password cracking software can
recover so-called "weak" passwords, i.e., words taken from a dictionary,
common names, etc.
These same experts frequently recommend the use of special password filters
designed to systematically enforce password complexity by disallowing any
password that does not meet some predefined rule set, or the running of
password cracking software in conjunction with the appropriate feedback to
any user unfortunate enough to have their password "cracked" by the program.
Some experts even recommend using both techniques simultaneously (although
to do so is a rather bizarre contradiction when you stop and really think
about it). Regardless of the method chosen, the goal is essentially the
same, to reduce risk by enforcing the use of strong passwords.
Passwords are generally considered to be reasonably "strong" if they are six
or more characters in length and contain at least one character from each of
the following four sets: uppercase alpha, lowercase alpha, numeric, and
punctuation or other special characters. Passwords constructed using this
(or any similar) set of rules are inherently stronger than words chosen from
a dictionary because they are by design much more difficult to attack.
Looking at an example of each ("!3&cZ@" as opposed to "voodoo") we can
easily see why; and how running password crackers to identify and eliminate
weak passwords will improve the overall security of our systems. At least
this is what many security consultants would very much like you to believe.
Unfortunately, passwords that follow these commonly prescribed rules are
only "strong" in an absurd fantasy world where the only possible method of
cracking passwords is by a dictionary attack. In a world where more than
one method exists for the cracking of passwords, you may want to consider
the following: If you compare any two passwords of equal length you will
find, in many cases, that selecting what security professionals insist would
be a very strong password, as opposed to randomly choosing a word that might
be found in any dictionary, will actually result in choosing a password that
is provably much easier to crack! A brute force attack, for example, will
discover the password "!3&cZ@" long before it will ever find the password
"voodoo". The inherent "strength" of a password such as "!3&cZ@" is an
illusion. It appears to be stronger only because the sequence of characters
forms a pattern unfamiliar to the average human being; to a computer, it is
just another string of ones and zeros. In fact, at the binary level one
password appears pretty much the same as another.
01001100 01101111 01101000 01101011 01100101 01100101
01000000 01011110 01011000 01110001 00110011 00100001
Password content is an issue that is often raised (and taken out of
context). Conventional wisdom states that one should not use the name of a
spouse, pet, child, etc. for a password because it will make it easier for
an attacker who knows you to guess your password. This is obviously good
advice that just happens to illustrate an extremely important point. The
word "password" is not inherently weak because of its composition; it is
"weak" only because of its unique association within an extremely limited
context. There is a big difference in not choosing a password that is in
some way "connected" to yourself and choosing a password that may be found
in a dictionary but is in no way associated to you or your environment.
The truth is that passwords resistant to one method of attack may be
extremely susceptible to another, and prescribing rules that fail to
consider this basic fact, is a serious mistake. Cracking passwords really
demonstrates nothing at all other than perhaps the ease with which it is
possible to con people who do not know any better. Creating rules that have
a tendency to create provably weaker passwords is bad enough, but when you
start systematically enforcing those rules, things really start to go
downhill fast.
Like a credit card number, the strength of a password is derived solely from
there being a vast number of possibilities for any given account.
Predictably, the systematic enforcement of any rule that eliminates a
significant number of possibilities serves only to weaken the overall
mechanism because the attacker has fewer possibilities to try thus
increasing the probability of success. If too many possibilities are
eliminated, we incur the additional risk of inadvertently opening up avenues
of attack previously thought to be impractical. Many of the commonly
prescribed formulas for so-called "strong" passwords fall into both of these
traps.
Suppose, for example, we have a rule which states that all passwords must be
six or more characters in length and contain at least one character from
each of the following four sets: uppercase alpha, lowercase alpha, numeric,
and punctuation (or other special characters). Assuming a six-character
password, an analysis of this rule would yield the following: Without the
rule, a user's password can be from one to six characters in length, and may
use any one of ninety-five characters in each position. The total number of
passwords possible is (951 + 952 + 953 + 954 + 955 + 956) 742,912,017,120.
With the rule, the user's password must be a minimum of six characters in
length and include at least one character from each of the four sets. The
number of passwords possible is now only (952 x 262 x 10 x 33) or
2,013,297,000
By enforcing this rule, we have (in the name of hardening our system against
an attacker attempting to gain unauthorized access by cracking passwords)
just eliminated 99.7% of the possibilities that the attacker would otherwise
have had to of tried. In the process of eliminating a large percentage of
the possibilities, we have also managed to transform the simple brute force
attack from an impractical means to the preferred means of cracking
passwords. Since the rule has effectively eliminated 99.7% of the
possibilities for us, we no longer have to waste time testing them. On the
typical stand-alone system a brute force attack specifically designed to
test only those passwords meeting our criteria for a so-called "strong"
password would take less than a day to test all of the possibilities and
have a 100% success rate. Try that with a dictionary attack! It could be
argued that an outsider would have no way of knowing the rule, however, you
still have to take into consideration all of the insiders who do know the
rule.
We can prove mathematically that the fundamental strength of a password is
derived from the statistical improbability of being able to associate the
correct password for a given account when there are an enormous number of
possibilities and all are equally probable. We can also prove
(mathematically) that passwords which follow the generally accepted and
prescribed rules for so-called "strong" passwords are, in fact, a great deal
easier for the attacker to crack using methods other than a dictionary
attack. Rules designed to systematically enforce so-called strong
passwords, unless very carefully crafted, may actually perform contrary to
their intended purpose. There is a world of difference between simply
recommending that users choose a password containing a mix of characters and
systematically enforcing such a rule. In the first instance, all passwords
are still equally possible thus preserving the inherent strength of the
mechanism; in the second, a significant number of possibilities may be
eliminated thereby accomplishing exactly the opposite of the desired result.
The practical effect of any proposed rule should be fully understood and
carefully tested before implementation. Any rule that significantly reduces
the number of possibilities serves no purpose other than to weaken the
overall mechanism and should be flatly rejected.
Looking at the following table we can see that a rule requiring the user to
choose a password at least seven characters in length would not
significantly reduce the overall number of possibilities (about .01%), but
would still eliminate a large number of "easy" passwords, including a lot of
commonly used words, names, etc.
95 1 95
95 2 9,025
95 3 857,375
95 4 81,450,625
95 5 7,737,809,375
95 6 735,091,890,625
95 7 69,833,729,609,375
95 8 6,634,204,312,890,625
We could further strengthen this rule (without appreciably affecting the
overall number of possibilities) by filtering out some of the more "obvious"
passwords such as Password, PASSWORD, password, any password that is simply
a string of the same character repeated, User ID, machine name, company
name, the user's real first and last name, and words generally associated
with system accounts such as CISCO, router, etc.
In a sense, this whole discussion is pointless. It is a given that any
password up to eight characters in length is easily cracked by even a
marginally competent attacker. In a year or so, the same will also be true
for ten character passwords. Does this mean that passwords are outdated or
that we should force the user to remember even longer passwords? Not at
all, if we keep things in perspective. Running a password cracker against
the entire password file on a dedicated system at extremely high speeds is
one thing (essentially an unlimited number of attempts to identify a given
password). Attempting to identify the password for a particular user within
a very limited number of attempts (usually three) before the account is
automatically disabled, is quite another. Which three passwords, out of the
billions of possibilities, should be tried? Attempting to equate these two
very different scenarios is absurd (although security people are fond of
doing just that and thereby trying to justify the use of password crackers).
There are a number of other things we can do to further enhance our defense
against an individual gaining access by cracking passwords:
1. Set the number of attempts at entering a password to two, or at most,
three.
2. Set the days and hours that a user is allowed to access the system.
3. Specify the terminal/s that a given user is allowed to logon to.
4. Prohibit remote logons or direct remote access to the workstation unless
it is ABSOLUTELY necessary. Any user claiming to need such
access should be made to prepare a formal justification for management
review. All other avenues of satisfying the users needs should be
exhausted before granting this request. Any accounts having remote access
should be rigorously monitored.
In conjunction with a reasonable password rule, the above steps will make it
all but impossible for a remote user to gain access by guessing passwords.
It is also important to protect access to the password file. This will be
discussed at length later on.
Lohkee
John Smith
a little more.
"Lohkee" <Loh...@worldnet.att.net> wrote in message
news:fL587.8557$LP2.8...@bgtnsc06-news.ops.worldnet.att.net...
Miguel Cruz
> You sound like you don't know what you are talking about.. Educate yourself
> a little more.
He took the time to lay out his point in detail and with support for his
arguments. What's your basis for rebuttal?
miguel
Lohkee
And you sound like a moron unable to think of an intelligent response!
"John Smith" <som...@microsoft.com> wrote in message
news:tm1r2ca...@corp.supernews.com...
Patrick Lotti
I think some points are wrong, but agree to the rest.
> is provably much easier to crack! A brute force attack, for example, will
> discover the password "!3&cZ@" long before it will ever find the password
> "voodoo". The inherent "strength" of a password such as "!3&cZ@" is an
Never saw a cracker doing such brute force.
In the first step it's a dict, az, then az09 and then any character attack, only
if there's still no password found.
You can always use weak dict passwords that can be easyly cracked - but just
to catch crackers and to trigger an alarm!
Take passowrd length 1:
az hast just 26 possiblieties to try, az09 has 36, any has 256 - 10x more
> automatically disabled, is quite another. Which three passwords, out of the
> billions of possibilities, should be tried? Attempting to equate these two
> very different scenarios is absurd (although security people are fond of
> doing just that and thereby trying to justify the use of password crackers).
Comparing these two attacks doesn't work, you're right. But:
If an attacker could get the password file somehow then he will use this form
of attack, starting with the dict attack. Therefore it's adviceable to have
"strong" passwords for important accounts (and some weak to alert you).
Patrick
Quill
six
> or more characters in length and contain at least one character from each
of
> the following four sets: uppercase alpha, lowercase alpha, numeric, and
> punctuation or other special characters."
Wrong. A password can not be considered to be even moderately strong until
it is at least 8 random characters long, preferably much longer. All of my
serious stuff is protected with a passphrase that is at least 30 random
characters in length.
Mike
>Never saw a cracker doing such brute force.
With today's computing power it's not too difficult. I'll mention 2 Linux
tools, because I know them more than L0pthcrack:
Crack5 with NT extensions has networking features to build a "cracking
cluster".
John The Ripper can run on top of a Mosix Linux cluster (www.mosix.org) to
share the cracking process among a large number of CPUs.
In fact, brute force of not-too-long password is a common practice in the
cracking world.
OF COURSE dictionary attack is faster, so it's used in the first step.
IMHO, Mr. Lohkee point is right, but with looooong passwords, the time to
crack by brute force is still considerable, even enforcing rules like the
ones he mention.
Best regards
Mike
Unknown
Except that you can't remember a 30 character random string of
anything. Meaning you wrote it down. Meaning someone can find it.
You'd need it nearby, so it's either on your person or in proximity to
your system. You've actually narrowed my work range quite a bit.
Jeff
Unknown
>much more difficult for an attacker to break than will a weak one, and
>because of this, we should encourage the use of strong passwords in order to
>protect our systems from those who would attempt to gain unauthorized access
>by cracking passwords.
Actually, strong passwords are better than weak ones, but they're just
a single part of a complex problem. The analogy would be a door with
a deadbolt versus a standard lock. Both keep honest people honest.
The deadbolt keeps out the guy who would slip a screwdriver in to
press back the striker, but neither will protect against the guy
who'll kick the door in.
And when you leave the sliding glass door on the patio unlocked to
make it easier for your friends to come in and drink your beer or copy
your WaReZ then you're the kind of neighbor I'd like to have... :)
Jeff
Lohkee
"Patrick Lotti" <Patric...@ision.net> wrote in message
news:3B611978...@ision.net...
> hi
>
> I think some points are wrong, but agree to the rest.
>
> > is provably much easier to crack! A brute force attack, for example,
will
> > discover the password "!3&cZ@" long before it will ever find the
password
> > "voodoo". The inherent "strength" of a password such as "!3&cZ@" is an
> Never saw a cracker doing such brute force.
> In the first step it's a dict, az, then az09 and then any character
attack, only
> if there's still no password found.
> You can always use weak dict passwords that can be easyly cracked - but
just
> to catch crackers and to trigger an alarm!
> Take passowrd length 1:
> az hast just 26 possiblieties to try, az09 has 36, any has 256 - 10x more
>
Two of my main points were: passwords that look strong are not just because
they look that way, and eliminating a significant number of possibilities
weakens the mechanism mking other kinds of atttacks more effective.
>
> > automatically disabled, is quite another. Which three passwords, out of
the
> > billions of possibilities, should be tried? Attempting to equate these
two
> > very different scenarios is absurd (although security people are fond of
> > doing just that and thereby trying to justify the use of password
crackers).
> Comparing these two attacks doesn't work, you're right. But:
> If an attacker could get the password file somehow then he will use this
form
> of attack, starting with the dict attack. Therefore it's adviceable to
have
> "strong" passwords for important accounts (and some weak to alert you).
If an attacker gets the Pw file its all over with. A distributed attack
could work through the entire password space in a few days. We protect the
PW file and focus on the other scenario, password guessing.
>
> Patrick
Lohkee
"Quill" <qu...@thewell.org> wrote in message
news:w7b87.345$0w3....@newsread2.prod.itd.earthlink.net...
considered reasonably strong. Did you notice I put stong in quotation marks?
I do agree that long passwords are stronger; I'm not so sure that most of us
could memorize 30 RANDOM characters which could lead to other problems such
as users writing them down, etc. I believe that most passwords of 7 or more
characters COUPLED with the other protective measures I suggested are
adequate to prevent password guessing. Let's face it, if I can get to your
system physically it won't matter how long or complicated you password is.
Adrien de Beaupre
crack.
However, passwords are not a particularly good method of authentication.
There are:
1- something I know, passwords.
2- Something I have, tokens
3- Something I am, Biometrics.
Passwords are by far the weakest, and should be combined with one of the
other two.
For example, I must have my PKI based token and the passphrase in order to
access a VPN,
as well as the Win2K username and password combination to access resources.
If you must use only username password combinations for authentication
doesn't it make sense
to at least make it somewhat more difficult for the bad guys to crack them?
A sensible password
policy is only one very small part of a security program.
Adrien
Lohkee
<Jeff Cochran> wrote in message news:3b675fef...@news.supernews.com...
> >The security community repeatedly tells us that a strong password will be
> >much more difficult for an attacker to break than will a weak one, and
> >because of this, we should encourage the use of strong passwords in order
to
> >protect our systems from those who would attempt to gain unauthorized
access
> >by cracking passwords.
>
> Actually, strong passwords are better than weak ones, but they're just
> a single part of a complex problem. The analogy would be a door with
> a deadbolt versus a standard lock. Both keep honest people honest.
> The deadbolt keeps out the guy who would slip a screwdriver in to
> press back the striker, but neither will protect against the guy
> who'll kick the door in.
Strong passwords ARE better than weak ones. The problem is that passwords
constructions typically promoted as being strong are not (provably so). So
what is a strong password? I believe the answer to this is a password that
has at least 7 characters and is not an "obvious" one, i.e., password.
We say it is easy for someone who knows you to guess passwords. In
researching this topic I set up a test. Twenty five people who have worked
with me for ten or more years each had 5 tries to guess my password
(newcastle - my favorite beer) and no one got it (I even had a Newcastle
poster on the wall next to the workstation). You could say they were not
good at what they do - they are. My point is that some things SOUND good
but in practice, especially when you have a limited number of tries, it's a
different ball game. Much like those brain teasers. They are all simple
AFTER you know the answer. This is not to suggest that people should pick
passwords easily associated with themselves, only to suggest that security
people may be doing a disservice by running password crackers and enforcing
absurd formulas.
Lohkee
configured. Biometrics SOUND good, but they can be attacked via inductive
methods, not to mention leveraging the false positive tolerances. Smart
cards that generate a new password every second can also be cracked. These
ideas are good under certain circumstances, not so good in others. In many
cases they are no more than drastic overkill and unnecessary.
"Adrien de Beaupre" <adriendb@-nospam-magi.com> wrote in message
news:4he87.271591$Z2.32...@nnrp1.uunet.ca...
Lohkee
and the rule eliminates a large percentage of the possible passwords, then a
brute force would be more efficient than a worldlist.
"Mike" <your...@pharma.novartis.com> wrote in message
news:3b61...@guardhouse.chbs...
Martin
>Smart cards that generate a new password every second can also be cracked.
Have you any published papers on this? I'm sure RSA Security would disagree
with you. Admittedly, they change once a minute, I'm not sure I could read
and type in a number that changed once a second :)
I've always thought strong two-part authentication, using a SecureId token
and 6 digit PIN was pretty unbreakable. I'd like to see evidence that this
can be broken in anything like a reasonable time.
Quill
<Jeff Cochran> wrote in message news:3b665f63...@news.supernews.com...
> >>" Passwords are generally considered to be reasonably "strong" if they
are
> >six
> >> or more characters in length and contain at least one character from
each
> >of
> >> the following four sets: uppercase alpha, lowercase alpha, numeric, and
> >> punctuation or other special characters."
> >
> >Wrong. A password can not be considered to be even moderately strong
until
> >it is at least 8 random characters long, preferably much longer. All of
my
> >serious stuff is protected with a passphrase that is at least 30 random
> >characters in length.
>
> Except that you can't remember a 30 character random string of
> anything.
though.
> Meaning you wrote it down. Meaning someone can find it.
> You'd need it nearby, so it's either on your person or in proximity to
> your system. You've actually narrowed my work range quite a bit.
>
> Jeff
>
Lohkee
number generator only.
Tokens that generate a new password every second must be synchronized with
the host in some way. If you get the software, and anyone can buy it,
becomes a trivial task to discover the algorithm and data used. A
programmer can duplicate these on a laptop and essentially create their own
token. Proxy cards can be read by the attacker in much the same way that
one can read/reply car alarm codes. I'm not saying these devices are bad,
only that they are not "AS GOOD" as most would like to think they are.
Every thing has a weakness, it's just a matter of finding it. Oftentimes by
looking at it from a different perspective the weakness is apparent and
GLARING. A good example of this are those sliding doors often used in
computer rooms. The proxy system MAY be strong. The door may not be. Often,
just like elevators these doors have a sensor to prevent the door from
closing on a person. I have walked up to these kinds of doors a opened them
by simply sliding a credit card between the two door panels and breaking the
light beam! So much for the proxy card! This is why, in another thread, I
suggested that a security person needs to have a good background in
electronics to really understand the issues and why many CISSPs wouldn't
know a vulnerability if it came up and sat on them.
"Martin" <the....@ntlworld.com> wrote in message
news:fMe87.31687$SK6.3...@news6-win.server.ntlworld.com...
Alex Witt
Granted. However there are any number of methods for making brute force
guessing attacks impractical or impossible against a system. Typically,
if you don't have the password file, social engineering is a much more
efficient method for getting enough access to get the password file.
This seems to me to be the basis for choosing hard to guess (via
dictionary attack) passwords, rather than a statistically superior
password space.
Alex
Lohkee
"Alex Witt" <adwi...@SPAMFORMETODAYuu.net> wrote in message
news:3B6187A5...@SPAMFORMETODAYuu.net...
Dosen't this just re-enforce my argument? If we have the password file then
a statistically superior keyspace becomes cirtical in so far as at least
making it time consuming for the attacker. Social engineering only works on
poorly configured systems (which most are), but that is another issue
altogether and should not detract from the agrument. We can configure
systems to be very resistant to account snatching via social engineering.
Lohkee.
>
> Alex
Gorazd Bozic
>
> Unfortunately, passwords that follow these commonly prescribed rules are
> only "strong" in an absurd fantasy world where the only possible method of
> cracking passwords is by a dictionary attack. In a world where more than
I remember reading similar things a few years ago... Maybe you can check the
web and USENET archives.
> Suppose, for example, we have a rule which states that all passwords must be
> six or more characters in length and contain at least one character from
> each of the following four sets: uppercase alpha, lowercase alpha, numeric,
> and punctuation (or other special characters). Assuming a six-character
> password, an analysis of this rule would yield the following: Without the
> rule, a user's password can be from one to six characters in length, and may
> use any one of ninety-five characters in each position. The total number of
> passwords possible is (951 + 952 + 953 + 954 + 955 + 956) 742,912,017,120.
> With the rule, the user's password must be a minimum of six characters in
> length and include at least one character from each of the four sets. The
> number of passwords possible is now only (952 x 262 x 10 x 33) or
> 2,013,297,000
Are you sure you did your calculation correctly? If we assume that
lowercase: n(a) = 26
uppercase: n(A) = 26
numeric: n(0) = 10
punctuation: n(+) = 95-n(a)-n(A)-n(0) = 33
If we calculate the number of passwords where the first character is
lowercase letter, followed by an uppercase letter, a numeric and a
punctuation (let's denote it 'Aa0+'), we get
m(4) = n(a)*n(A)*n(0)*n(+) = 223,080
possible combinations. Then you have to do permutations on the placement of
these four categories to get other sets, for instance 'a+0A' where each set
holds another 223,080 possible passwords. What we get is
k(4) = 4!*m(4) = 5,353,920
which is the number of restricted four-letter passwords. Now if we then take
that the last two letters can *only* be lowercase characters, the number of
possible passwords climbs up to
l(6) = k(4)*n(a)^2 = 3,619,249,920
So even if you place another restriction - that the fifth and the sixth
letter can *only* be a lowercase character, you already have more than
2,013,297,000 possible combinations. If the last two characters can by
anything,
sum(n) = k(4)*95^(n-4)
sum(6) = k(4)*95^2 = 48,319,128,000
That means you still throw away 93,4% of the password space, but this number
is 24 times larger than the number you calculated for all possible passwords
with the mentioned restrictions.
> possibilities for us, we no longer have to waste time testing them. On the
> typical stand-alone system a brute force attack specifically designed to
> test only those passwords meeting our criteria for a so-called "strong"
> password would take less than a day to test all of the possibilities and
> have a 100% success rate. Try that with a dictionary attack! It could be
Let's assume for the sake of the argument that it will take exactly one day
(you can check 23,302 passwords in one second). It takes 24 days to wade
through sum(6) combinations and on average you'll find the password in half
that time, 12 days.
> Looking at the following table we can see that a rule requiring the user to
> choose a password at least seven characters in length would not
> significantly reduce the overall number of possibilities (about .01%), but
> would still eliminate a large number of "easy" passwords, including a lot of
> commonly used words, names, etc.
I calculated the sum(7)/95^7 and it still gives 93.4% unusable password
space.
sum(7) = 4,590,317,160,000
sum(7)/23,302 = 196,992,410.95 seconds = 2280 days > 6 years
So, 6 years to test all "restricted" passwords of length 7. Again, on
average you'll find it in 3 years. Of course, you can distribute crack
process among many systems and get better results.
> In a sense, this whole discussion is pointless. It is a given that any
> password up to eight characters in length is easily cracked by even a
> marginally competent attacker. In a year or so, the same will also be true
sum(8) = 436,080,130,200,000
If your goal is to crack a given password in six months and on average you
have to search half the restricted password space, you need to do
(sum(8)/2)/(186*86400) = 13,790,228 checks/second
Let's say you have at your disposal 10 machines that are 10 times stronger
than the one we used in the example. Assuming that processor power doubles
every year, you'll achieve the goal of breaking any 8-letter restricted
password in six months (on average) 2.5 years from now with 10 of then
available number crunchers. A poor script kiddy with one "lousy" PC will be
able to reach the goal in nine years.
It is of course a valid point that you bring up. However, if you assume that
99% of script kiddies do dictionary attacks on password files restricting
password space is a reasonable thing to do.
Based on numbers that I fiddled with here (if of course my calculations are
correct), my conclusion would be to avoid DES crypt and move to a different
hash (some PAM solutions are already available for various Unix systems).
Gorazd
Gorazd Bozic
>
> Strong Passwords
Another thing: the most appropriate newsgroup for detailed discussion on
this would probably be sci.crypt.
Gorazd
Richard Ballard
"Mike" <your...@pharma.novartis.com> writes:
>In fact, brute force of not-too-long password is a common
>practice in the cracking world.
>
>OF COURSE dictionary attack is faster, so it's used in
>the first step.
>
>IMHO, Mr. Lohkee point is right, but with looooong
>passwords, the time to crack by brute force is still
>considerable, even enforcing rules like the ones he
>mention.
The concepts of 'brute force attack' are relatively
straightforward. 'Dictionary attack' concepts are more
complex, but most MCSE's understand dictionary
attack adequately. Everyone avoids Post-its.
I believe the greatest password vulnerability is the user
(or friend) who looks over the MCSE's shoulder as the
MCSE logs in as Administrator. Perfectly harmless --
they want to observe what is happening on the CRT,
but the chance for password exposure exists. I
recommend the following steps to avoid exposure of
the Administrator password:
1) MCSE's should have separate User and Administrator
accounts, and should use the Administrator accounts
*only* when Administrator privileges are required.
2) Whenever possible send the User (or your friend) for a
cup of coffee while you perform your Administrative duties
(including login) uninterrupted.
3) Choose an Administrator password sequence that can
be typed without changing your hand position on the keyboard.
This choice allows Administrators to type faster (harder to
observe) and the unchanging hand position partially shields
the typed characters. MCSE's cannot afford to be "two-finger"
typists.
Selection of strong passwords is important, but "over-the-
shoulder" observation is much easier to implement than a
technical attack against an IT system. I recommend solving
the easier and more common problem first.
My opinions.
Richard Ballard MSEE CNA4 KD0AZ
--
Consultant specializing in computer networks, imaging, and security
Listed as rjballard in "Friends & Favorites" at www.amazon.com
Last book review: "Wicca For Men: A Handbook for Male Pagans ..."
Lohkee
or less characters. The technology is already here at very low cost and
will be here soon for longer passwords. This would obsolete all other kinds
of attack, as cracking any password would become a simple database query
that would always return the correct password in less than 1 second. In
this sense, there is no such thing as a strong password. Why bother to run
cracking software at all. It is pointless.
The ability to crack passwords is moot if you cannot get the password file.
It is also moot if the user can only logon to a given terminal, on given
days, between given hours, and has only two attempts to enter a correct
password (assuming the system is even available to remote users).
The emphasis (and resources) should be on proper system configuration, not
on pointless attempts to create the "ultimate" password, password cracking,
etc. Too many times I have seen so much effort put into enforcing "strong"
passwords while the directory and file permissions were wide open and gave
the attacker a "blank check" as it were. Nine times out of ten,
c:\winnt\repair is readable by the world. Many systems allow the user to
install software such as keystroke recorders (getting domain admin is a
snap).
More ramblings . . . . . . . . . .
Ken Dante
> A brute force attack, for example, will discover the password "!3&cZ@"
> long before it will ever find the password "voodoo".
Sure, "!3&cZ@" comes before "voodoo" in ASCII order, but your suggestion
that a brute force attack pays off faster than a dictionery attack is
almost never correct, not even in your example.
Let's say you started with " " (6 spaces), which is the lowest
6 character printable ASCII sequence, and worked your way up to "!3&cZ@"
in ASCII order.
How many passwords is that?: " xxxxx" where x is any of the printables,
is 95^5 combinations, plus "!yxxxx" where y is any of these 19 characters
space,!,",...0,1,2 is 19 * 95^4. So by the time you get to "!3&cZ@"
you would have tried more than 9,285,371,250 passwords.
A very big dictionery has about 500,000 words. Trying every word in
the dictionery would take you only 1/18000th of the time it takes
*just* to get to "!3&cZ@".
To phrase it another way, in the time it would take you to get to *only*
"!3&cZ@", you could have searched the dictionery 18,000 times already.
Ken
Unknown
>the host in some way. If you get the software, and anyone can buy it,
>becomes a trivial task to discover the algorithm and data used. A
>programmer can duplicate these on a laptop and essentially create their own
>token.
Uhhh.... You haven't actually tried this or known anyone that has,
have you? :)
I have yet to hear of anyone who has cracked one of the secure id
token systems. But then, there are always easier ways to get to it.
Jeff
wtshaw
> Except that you can't remember a 30 character random string of
> anything. Meaning you wrote it down. Meaning someone can find it.
> You'd need it nearby, so it's either on your person or in proximity to
> your system. You've actually narrowed my work range quite a bit.
>
It is really easy to have a perfectly rememberable quite long stentence
and hash it to the desired length.
--
Jimmy Carter is still my hero.
wtshaw
"Lohkee" <Loh...@worldnet.att.net> wrote:
> You can pick up dozens of books or white papers that tell you 6 char is
> considered reasonably strong. Did you notice I put stong in quotation marks?
> I do agree that long passwords are stronger; I'm not so sure that most of us
> could memorize 30 RANDOM characters which could lead to other problems such
> as users writing them down, etc. I believe that most passwords of 7 or more
> characters COUPLED with the other protective measures I suggested are
> adequate to prevent password guessing. Let's face it, if I can get to your
> system physically it won't matter how long or complicated you password is.
If you set out any rules other than to be suprising, you are making things
worse because people might actually do what you say.
Quite obviously you do not fully understand desirable crypto programming
practices nor secure architectures. Passwords/phrases are never to be
filed, recorded, swapped, or otherwise stored in a computer. The next
step of logic involves how you can do this. I don't think you are ready
to understand those refinements.
Lohkee
"wtshaw" <jgf...@vgrknf.arg> wrote in message
news:jgfunj-2707...@dial-245-243.itexas.net...
Bruce Barnett
> Some experts even recommend using both techniques simultaneously (although
> to do so is a rather bizarre contradiction when you stop and really think
> about it).
If the rules and dictionaries for proactive and reactive password
checking are identical - it is silly. But if they are different, then
it is valuable to check both times.
Example: a proactive tester that looks for three-letter combinations
that frequently occur in the English language.
Counter-example - A reactive checker that uses dictionary words,
changing "e" to "3", "i" to "1", "o" to "0", etc.
>A brute force attack, for example, will
> discover the password "!3&cZ@" long before it will ever find the password
> "voodoo".
This is a flawed argument.
If the password was "Z!3&c@" then "voodoo" would be discolved long before.
...assuming you are doing a straight ascending sequence.
And it is also a 1000 times more likely that "voodoo" was chosen than "Z!3&c@"
And a good one-way hash algorithm suggests that it is almost
impossible to find two words that generate the same hash. And since
the search space of the entire character universe is larger than the
search space using rules and dictionaries, then password crackers
are useful. See Gorazd's reply.
> The truth is that passwords resistant to one method of attack may be
> extremely susceptible to another, and prescribing rules that fail to
> consider this basic fact, is a serious mistake.
Using reusable passwords is even more serious.
> Cracking passwords really
> demonstrates nothing at all other than perhaps the ease with which it is
_______
> possible to con people who do not know any better.
Incorrect. Counter-example:
It demonstrates to people that thinking "No one would ever guess my
password is really 'Debbie1" is flawed - because it can be guessed.
> Creating rules that have
> a tendency to create provably weaker passwords is bad enough,
Your "proof" is flawed. See above.
--
Bruce <barnett at crd. ge. com> (speaking as myself, and not a GE employee)
Harald Ums
NT uses only 14 characters for the passwords.
"Quill" <qu...@thewell.org> wrote in message
news:w7b87.345$0w3....@newsread2.prod.itd.earthlink.net...
Lohkee
news:3B61A20C...@nowhere.com...
> "Lohkee" <Loh...@worldnet.att.net> writes:
> > A brute force attack, for example, will discover the password "!3&cZ@"
> > long before it will ever find the password "voodoo".
>
> Sure, "!3&cZ@" comes before "voodoo" in ASCII order, but your suggestion
> that a brute force attack pays off faster than a dictionery attack is
> almost never correct, not even in your example.
If, and only if, you assume that voodoo is in the dictionary being used,
which is one of my points. Dictionaries can be effective BUT they are, by
nature, haphazzard.
>
> Let's say you started with " " (6 spaces), which is the lowest
> 6 character printable ASCII sequence, and worked your way up to "!3&cZ@"
> in ASCII order.
>
> How many passwords is that?: " xxxxx" where x is any of the printables,
> is 95^5 combinations, plus "!yxxxx" where y is any of these 19 characters
> space,!,",...0,1,2 is 19 * 95^4. So by the time you get to "!3&cZ@"
> you would have tried more than 9,285,371,250 passwords.
Depends on how you approach the problem. 9 billion is nothing!
>
> A very big dictionery has about 500,000 words. Trying every word in
> the dictionery would take you only 1/18000th of the time it takes
> *just* to get to "!3&cZ@".
>
See above.
> To phrase it another way, in the time it would take you to get to *only*
> "!3&cZ@", you could have searched the dictionery 18,000 times already.
Pointles if the password is not in the dictionary!
>
> Ken
Lohkee
<Jeff Cochran> wrote in message news:3b63a5dc...@news.supernews.com...
Because it has not been published does not mean that it has not or cannot be
accomplished. In this case its the sync. mechanism that provides a
potential way in. Both the host and the token must have the same password
during the same time frame. Since there is no communication between the two,
there must be a way to sync. both devices. Time is the key. Some devices I
have tested use DES to encrypt the time and thereby create a short lived
password. If you use the same algorithm, with the same input, you will
create the same password as that displayed on the token.
>
> Jeff
Lohkee
"Bruce Barnett" <see.my.add...@domain.com> wrote in message
news:yeku1zy...@grymoire.crd.ge.com...
> "Lohkee" <Loh...@worldnet.att.net> writes:
>
> > Some experts even recommend using both techniques simultaneously
(although
> > to do so is a rather bizarre contradiction when you stop and really
think
> > about it).
>
> If the rules and dictionaries for proactive and reactive password
> checking are identical - it is silly. But if they are different, then
> it is valuable to check both times.
Why not just have the rule enforce it in the first place? Where did you say
the value was?
>
> Example: a proactive tester that looks for three-letter combinations
> that frequently occur in the English language.
>
> Counter-example - A reactive checker that uses dictionary words,
> changing "e" to "3", "i" to "1", "o" to "0", etc.
>
> >A brute force attack, for example, will
> > discover the password "!3&cZ@" long before it will ever find the
password
> > "voodoo".
>
> This is a flawed argument.
How so?
>
> If the password was "Z!3&c@" then "voodoo" would be discolved long before.
> ...assuming you are doing a straight ascending sequence.
Now you agree????????
>
> And it is also a 1000 times more likely that "voodoo" was chosen than
"Z!3&c@"
Based on what scientific evidence or proof??????
>
> And a good one-way hash algorithm suggests that it is almost
> impossible to find two words that generate the same hash. And since
> the search space of the entire character universe is larger than the
> search space using rules and dictionaries, then password crackers
> are useful. See Gorazd's reply.
>
>
> > The truth is that passwords resistant to one method of attack may be
> > extremely susceptible to another, and prescribing rules that fail to
> > consider this basic fact, is a serious mistake.
>
>
> Using reusable passwords is even more serious.
Agreed, but I have never suggested such a thing.
>
>
> > Cracking passwords really
> > demonstrates nothing at all other than perhaps the ease with which it is
> _______
> > possible to con people who do not know any better.
>
>
> Incorrect. Counter-example:
>
> It demonstrates to people that thinking "No one would ever guess my
> password is really 'Debbie1" is flawed - because it can be guessed.
>
You can't be serious!
>
> > Creating rules that have
> > a tendency to create provably weaker passwords is bad enough,
>
> Your "proof" is flawed. See above.
>
>
Only if Debbie is associated with the user.
Bruce Barnett
> Two of my main points were: passwords that look strong are not just because
> they look that way,
Heck, I know lots of people who say "There is no way you could have
guessed my password" as I show it to them.
Lohkee
"Bruce Barnett" <see.my.add...@domain.com> wrote in message
news:yeklmla...@grymoire.crd.ge.com...
Gareth Jones
>If you design the brute force to not try passwords eliminated by the rule,
>and the rule eliminates a large percentage of the possible passwords, then a
>brute force would be more efficient than a worldlist.
What are your figures for that? An average dictionary attack would use
somewhere in the order of 100k words. This is much smaller than any
brute force attack I can envisage unless your password selecting rules
are extremely onerous and stupid.
Very rough calculation:
assume a dictionary of 100k words less than 6 letters - time for
attack is 100k.
assume a brute force attack only trying lower case passwords of 6
letters - time for attack 308,000k.
Now choose some really stupid password rules, that eliminate 95% of
the potential passwords. 308,000k is reduced to 15,000k.
So even choosing a really stereotyped set of circumstances, the
dictionary attack is much faster.
Gareth
Gareth Jones
>Tokens that generate a new password every second must be synchronized with
>the host in some way. If you get the software, and anyone can buy it,
>becomes a trivial task to discover the algorithm and data used. A
>programmer can duplicate these on a laptop and essentially create their own
>token.
Ok, I'm afraid this reveals that you really don't know what you are
talking about. If you do, I'll start reading your posts again when you
start a thread entitled "this is how to break SecureID".
clue: systems like this can be constructed by designing pseudorandom
number generators. You enter a seed value into the program, from which
it generates a series of numbers. You do this on the authenticating
host, and on the card - using the same seed number. If the generator
is good, it is computationally unfeasible to generate the seed from a
series of the random numbers. Knowing the algorithm doesn't help.
Gareth
Gareth Jones
>
><Jeff Cochran> wrote in message news:3b63a5dc...@news.supernews.com...
>> >Tokens that generate a new password every second must be synchronized
>with
>> >the host in some way. If you get the software, and anyone can buy it,
>> >becomes a trivial task to discover the algorithm and data used. A
>> >programmer can duplicate these on a laptop and essentially create their
>own
>> >token.
>>
>> Uhhh.... You haven't actually tried this or known anyone that has,
>> have you? :)
>>
>> I have yet to hear of anyone who has cracked one of the secure id
>> token systems. But then, there are always easier ways to get to it.
>
>
>Because it has not been published does not mean that it has not or cannot be
>accomplished.
So do it. You said it was trivial. You'll get a good deal of respect
from the worldwide security industry, and will probably make a
fortune.
> In this case its the sync. mechanism that provides a
>potential way in. Both the host and the token must have the same password
>during the same time frame. Since there is no communication between the two,
>there must be a way to sync. both devices. Time is the key. Some devices I
>have tested use DES to encrypt the time and thereby create a short lived
>password. If you use the same algorithm, with the same input, you will
>create the same password as that displayed on the token.
Well of course. But that is like saying you can defeat a password
system by entering the same password that the user know. It's true,
but it doesn't help. The input to the algorithm is the secret. If it
becomes known, the system is compomised.
I'd suggest you have a bit of a read......Bruce Schneier's Applied
Cryptography is good.
Gareth
Gareth Jones
>>" Passwords are generally considered to be reasonably "strong" if they are
>six
>> or more characters in length and contain at least one character from each
>of
>> the following four sets: uppercase alpha, lowercase alpha, numeric, and
>> punctuation or other special characters."
>
>Wrong. A password can not be considered to be even moderately strong until
>it is at least 8 random characters long, preferably much longer.
Absolute statements like this are relatively meaningless....a password
is strong if it can resist the expected attacks for the length of time
required.
> All of my
>serious stuff is protected with a passphrase that is at least 30 random
>characters in length.
Meaning what? If your encryption algorithm involves repeatedly XORing
with bits from your passphrase, then you can use that passphrase to
securely encrypt a 30 byte file. Once.
Gareth
Gareth Jones
>Suppose you have a database of all possible "pre-cracked" passwords of ten
>or less characters. The technology is already here at very low cost and
>will be here soon for longer passwords. This would obsolete all other kinds
>of attack, as cracking any password would become a simple database query
>that would always return the correct password in less than 1 second. In
>this sense, there is no such thing as a strong password. Why bother to run
>cracking software at all. It is pointless.
Good grief, do some research.
You could only do something like this for a very limited set of
systems. You could do it for NT4 for example, but not for Linux.
Keyword here is *salt*.
>The ability to crack passwords is moot if you cannot get the password file.
>It is also moot if the user can only logon to a given terminal, on given
>days, between given hours, and has only two attempts to enter a correct
>password (assuming the system is even available to remote users).
>The emphasis (and resources) should be on proper system configuration, not
>on pointless attempts to create the "ultimate" password, password cracking,
>etc. Too many times I have seen so much effort put into enforcing "strong"
>passwords while the directory and file permissions were wide open and gave
>the attacker a "blank check" as it were. Nine times out of ten,
>c:\winnt\repair is readable by the world. Many systems allow the user to
>install software such as keystroke recorders (getting domain admin is a
>snap).
No, you are wrong. The effort required to enforce strong passwords is
pretty small. On NT you install a replacement GINA, and away you go.
You can get a free one from MS, and there are better ones available
commercially. This requires considerably less work, and has
considerably less impact on users than only letting people logging
onto one machine, restricting their hours etc.
Gareth
Unknown
>with
>> >the host in some way. If you get the software, and anyone can buy it,
>> >becomes a trivial task to discover the algorithm and data used. A
>> >programmer can duplicate these on a laptop and essentially create their
>own
>> >token.
>>
>> Uhhh.... You haven't actually tried this or known anyone that has,
>> have you? :)
>>
>> I have yet to hear of anyone who has cracked one of the secure id
>> token systems. But then, there are always easier ways to get to it.
>Because it has not been published does not mean that it has not or cannot be
>accomplished.
Believe me, if this had been accomplished it would be published. Very
quickly.
>In this case its the sync. mechanism that provides a
>potential way in. Both the host and the token must have the same password
>during the same time frame. Since there is no communication between the two,
>there must be a way to sync. both devices. Time is the key. Some devices I
>have tested use DES to encrypt the time and thereby create a short lived
>password. If you use the same algorithm, with the same input, you will
>create the same password as that displayed on the token.
And if you use my ATM card and the same PIN number to access my meager
bank account, you can withdraw my cash. The problem comes in getting
the PIN as well as the card. So far, nobody's done that to me either.
(Possibly because eight bucks and change isn't enough incentive...)
Jeff
Alex Witt
the system still comes down to a 64 bit shared secret between the server
and token. Duplicating the token would mean compromising that secret.
Though probably possible, I have not seen a method for deriving that
secret from a series of tokencodes. In order to implement a brute force
attack, you would also need to take into account the time offset
(another > 8 bit secret shared only by the token and server). Even if a
duplicate token were produced, access is still protected by the users
pin, which is likely as strong as any other static password. So, while
nothing is invulnerable, it is significantly harder to defeat that a
static password.
While most security systems are not "as good" as some may claim, they
are generally not "as bad" as others claim. For example, while "strong"
password rules may make the password space smaller and therefore more
vulnerable to a brute force attack, lack of "strong" password rules is
likely to make you more vulnerable to a dictionary attack. And, while
having no "strong password" rules may increase the password space, it
neglects the reality that users will not take advantage of this
increased password space (hence dictionary attacks).
It seems to me that "strong" password rules are in reality simply
substituting a set of artificial rules for the rules of natural language
and human nature. While the artificial rules produce a smaller and
predictable password space, they are designed specifically to avoid the
weakness of the natural rules employed by users. They came into
existence largely to defeat a set of tools which had been created to
exploit the weaknesses of natural user passwords.
Ultimately, I agree with you. "Strong" password rules may protect you
from traditional dictionary attacks, but make you vulnerable to a
different type of dictionary attack (brute force guided by the password
creation rules). In the end, any system protected by static passwords
(any system really) will need to employ a number of other mechanisms to
protect against password guessing/theft. Given the administration costs
of implementing and maintaining a "strong" password policy, you are
probably better off using those resources on implementing other security
measures.
Bruce Barnett
> Why not just have the rule enforce it in the first place? Where did you say
> the value was?
There is no guarantee that the cracker (who uses reactive password checking) will use the same rules and dictionaries that you do (who uses pro-active password checking).
Therefore It is possible that the user can pick a password that
can be guessed.
> > And it is also a 1000 times more likely that "voodoo" was chosen than
> "Z!3&c@"
>
> Based on what scientific evidence or proof??????
Based on the hundreds of papers of password cracking - that indicate many people pick bad passwords. We KNOW they pick bad passwords.
> > > The truth is that passwords resistant to one method of attack may be
> > > extremely susceptible to another, and prescribing rules that fail to
> > > consider this basic fact, is a serious mistake.
> >
> >
> > Using reusable passwords is even more serious.
>
> Agreed, but I have never suggested such a thing.
You are arguing for a partial solution which only fixes a small set of
problems.
I am arguing for a solution which fixes all of your problems, and more.
Don't fix the small problem., Fix the big problem.
You are more concerned about proving those people who use password
cracking that their technique is wrong, and you are missing the BIG
PICTURE.
> > > Cracking passwords really
> > > demonstrates nothing at all other than perhaps the ease with which it is
> > > possible to con people who do not know any better.
> >
> >
> > Incorrect. Counter-example:
>You can't be serious!
How can I take you seriously when you tend to make absolute statements
without thinking?
Lohkee
news:0dh3mt4tei8dif8lg...@4ax.com...
Each authenticator has a unique 64-bit symmetric key that is combined with a
powerful algorithm to generate a new code every 60 seconds. Only the RSA
ACE/Server knows which number is valid at that moment in time for that
user/authenticator combination. Because the number is unpredictable and
dynamic, it is virtually impossible for a hacker to guess the correct number
at any given time. Patented technology ***time*** synchronizes each
authenticator with the security server, ensuring a high level of security.
Additionally, both the hardware and software versions are engineered to
resist tampering.
> Gareth
Lohkee
Each authenticator has a unique 64-bit symmetric key that is combined with a
powerful algorithm to generate a new code every 60 seconds. Only the RSA
ACE/Server knows which number is valid at that moment in time for that
user/authenticator combination. Because the number is unpredictable and
dynamic, it is virtually impossible for a hacker to guess the correct number
at any given time. Patented technology ****time synchronizes**** each
Lohkee
> "Lohkee" <Loh...@worldnet.att.net> wrote:
>
> >
> ><Jeff Cochran> wrote in message
news:3b63a5dc...@news.supernews.com...
> >> >Tokens that generate a new password every second must be synchronized
> >with
> >> >the host in some way. If you get the software, and anyone can buy it,
> >> >becomes a trivial task to discover the algorithm and data used. A
> >> >programmer can duplicate these on a laptop and essentially create
their
> >own
> >> >token.
> >>
> >> Uhhh.... You haven't actually tried this or known anyone that has,
> >> have you? :)
> >>
> >> I have yet to hear of anyone who has cracked one of the secure id
> >> token systems. But then, there are always easier ways to get to it.
> >
> >
> >Because it has not been published does not mean that it has not or cannot
be
> >accomplished.
>
> So do it. You said it was trivial. You'll get a good deal of respect
> from the worldwide security industry, and will probably make a
> fortune.
I need no validation and there is no money to be made. Becasue something
can be broken, doe snot necessarily mean that it is not good. My point was
simply that often times things are not what they appear to be if you look at
them from a different perspective. That is all.
Lohkee
> "Lohkee" <Loh...@worldnet.att.net> wrote:
>
> >Suppose you have a database of all possible "pre-cracked" passwords of
ten
> >or less characters. The technology is already here at very low cost and
> >will be here soon for longer passwords. This would obsolete all other
kinds
> >of attack, as cracking any password would become a simple database query
> >that would always return the correct password in less than 1 second. In
> >this sense, there is no such thing as a strong password. Why bother to
run
> >cracking software at all. It is pointless.
>
> Good grief, do some research.
>
> You could only do something like this for a very limited set of
> systems. You could do it for NT4 for example, but not for Linux.
> Keyword here is *salt*.
>
Since *nix has such a small market share compared to win I think that maybe
you may want to consider doing some research.
I will agree that win could have done it better. I would have loved to see a
user configurable parameter that would confuse the hashing algorithm while
making it unique to the owning organization..
> >The ability to crack passwords is moot if you cannot get the password
file.
> >It is also moot if the user can only logon to a given terminal, on given
> >days, between given hours, and has only two attempts to enter a correct
> >password (assuming the system is even available to remote users).
>
> >The emphasis (and resources) should be on proper system configuration,
not
> >on pointless attempts to create the "ultimate" password, password
cracking,
> >etc. Too many times I have seen so much effort put into enforcing
"strong"
> >passwords while the directory and file permissions were wide open and
gave
> >the attacker a "blank check" as it were. Nine times out of ten,
> >c:\winnt\repair is readable by the world. Many systems allow the user to
> >install software such as keystroke recorders (getting domain admin is a
> >snap).
>
> No, you are wrong. The effort required to enforce strong passwords is
> pretty small. On NT you install a replacement GINA, and away you go.
> You can get a free one from MS, and there are better ones available
> commercially. This requires considerably less work, and has
> considerably less impact on users than only letting people logging
> onto one machine, restricting their hours etc.
Are you enforcing strong passwords or passwords that only appear to be
strong? The other restrictions are a good practice for secure environments
regardless of the password issue (something about a fundamental principal of
least privilege).
>
> Gareth
san...@the.seaside
wrote:
I agree. As a Sysop I had the job of trying to crack an ex employees
file in Word2000. I had no idea how long his password/phrase was. I
bought a cracker program (2 actually) and found that it took less than
2 seconds to do the dictionary attack. So quick I kept repeating it,
thinking it hadn't started. Unfortunately, he had not used a single
word, so I had to try a brute force. I took a gamble and limited it
to lowercase only, but luckily left in figures, but excluded
punctuation.
It took a few seconds to try out all 3 letter combos, about another
minute to do all 4 then slowed up. It took 7 hours to find a 5
character password. I was really thankful he had not used 8 or 9
characters or it would still be running. True, it was only a dual
Pentium running at 450 Mhz. But it pointed up the truth that longer
is stronger and much longer is very, very much stronger, exponentially
so.
Of course, it depends on the threat model. If we were discussing
state security, forget it. Those spooks will just monitor your
keystrokes. No way are they going to waste precious resources on a
brute force attack on your ultra long 30 character randomn passphrase.
Maybe rubber hose cryptography is even easier - for them anyway.
Lohkee
"Alex Witt" <adwi...@SPAMFORMETODAYuu.net> wrote in message
news:3B61D005...@SPAMFORMETODAYuu.net...
> While the RSA tokenalgorithm has been reverse engineered and published,
> the system still comes down to a 64 bit shared secret between the server
> and token. Duplicating the token would mean compromising that secret.
> Though probably possible, I have not seen a method for deriving that
> secret from a series of tokencodes. In order to implement a brute force
> attack, you would also need to take into account the time offset
> (another > 8 bit secret shared only by the token and server). Even if a
> duplicate token were produced, access is still protected by the users
> pin, which is likely as strong as any other static password. So, while
> nothing is invulnerable, it is significantly harder to defeat that a
> static password.
>
Agreed.
> While most security systems are not "as good" as some may claim, they
> are generally not "as bad" as others claim. For example, while "strong"
> password rules may make the password space smaller and therefore more
> vulnerable to a brute force attack, lack of "strong" password rules is
> likely to make you more vulnerable to a dictionary attack. And, while
> having no "strong password" rules may increase the password space, it
> neglects the reality that users will not take advantage of this
> increased password space (hence dictionary attacks).
>
I am not against enforcing "strong" password rules, per se. I am against
creating rules that significantly weaken the mechanism.
> It seems to me that "strong" password rules are in reality simply
> substituting a set of artificial rules for the rules of natural language
> and human nature. While the artificial rules produce a smaller and
> predictable password space, they are designed specifically to avoid the
> weakness of the natural rules employed by users. They came into
> existence largely to defeat a set of tools which had been created to
> exploit the weaknesses of natural user passwords.
Agreed.
>
> Ultimately, I agree with you. "Strong" password rules may protect you
> from traditional dictionary attacks, but make you vulnerable to a
> different type of dictionary attack (brute force guided by the password
> creation rules). In the end, any system protected by static passwords
> (any system really) will need to employ a number of other mechanisms to
> protect against password guessing/theft. Given the administration costs
> of implementing and maintaining a "strong" password policy, you are
> probably better off using those resources on implementing other security
> measures.
>
And that is all I was saying! Put your money to the best use possible. I do
not think PW cracking and enforcing rules that weaken a mechanism are the
best use of those scarce resources.
Lohkee
> "Lohkee" <Loh...@worldnet.att.net> writes:
>
> > Why not just have the rule enforce it in the first place? Where did you
say
> > the value was?
>
> There is no guarantee that the cracker (who uses reactive password
checking) will use the same rules and dictionaries that you do (who uses
pro-active password checking).
>
The the rule is acceptable to the organization, and the password is
acceptable to the rule, never mind!
>
> Therefore It is possible that the user can pick a password that
> can be guessed.
>
>
>
> > > And it is also a 1000 times more likely that "voodoo" was chosen than
> > "Z!3&c@"
> >
> > Based on what scientific evidence or proof??????
>
> Based on the hundreds of papers of password cracking - that indicate many
people pick bad passwords. We KNOW they pick bad passwords.
>
>
Please, point me to a paper that offers a formula to accurately predict this
probability! We do know that people will pick bad passwords, however, this
does not mean that the alternative is stronger by default. In many cases it
can be proven not to be!
> > > > The truth is that passwords resistant to one method of attack may be
> > > > extremely susceptible to another, and prescribing rules that fail to
> > > > consider this basic fact, is a serious mistake.
> > >
> > >
> > > Using reusable passwords is even more serious.
> >
> > Agreed, but I have never suggested such a thing.
>
> You are arguing for a partial solution which only fixes a small set of
> problems.
> I am arguing for a solution which fixes all of your problems, and more.
>
> Don't fix the small problem., Fix the big problem.
>
> You are more concerned about proving those people who use password
> cracking that their technique is wrong, and you are missing the BIG
> PICTURE.
Perhaps it is because of my concern for the big picture that I have taken
the time to write about these things. You, like many others, seem
determined to practice "security by superstition" as opposed to "security
through science" and this scares me. People just like you are protecting our
national infrastructure and they are failing miserably. Look at the all the
money spent by the government on security, in spite of which, they seem
incapable of keeping bored 16 y.o. kids out of their systems. Imagine what a
team of real professionals could do to our country! I have spent 20 years
specializing in penetration testing and I have yet to see a system that was
worth a damn. Hold on to your voodoo if you like. I prefer to get people
thinking about these things in a meaningful way. Great things can happen
when you question the status quo. Nothing will happen if you embrace it.
Lohkee
The problem is that a brute force is 100% effective. The dictionary attack
is not! Why use a sub-standard method when the rule has created a situation
that makes the brute force attack more attractive?
"Gareth Jones" <gar...@uberdog.net> wrote in message
news:8sg3mto2uu0414v8v...@4ax.com...
> "Lohkee" <Loh...@worldnet.att.net> wrote:
>
> >If you design the brute force to not try passwords eliminated by the
rule,
> >and the rule eliminates a large percentage of the possible passwords,
then a
> >brute force would be more efficient than a worldlist.
>
At cracking passwords. Bf would still take longer but if the time it takes
is acceptable and it has a 100% success rate then the issue is moot thus
making the attack more efficient (and desirable) AT CRACKING PASSWORDS!
Martin
> can be broken, doe snot necessarily mean that it is not good. My point
was
> simply that often times things are not what they appear to be if you look
at
> them from a different perspective. That is all.
True
But you did claim that the RSA SecureId system could be broken without too
much trouble.
I still think you should point to papers as to how this can be done without
actually stealing the token. Even knowing the time and a whole bunch of
sequences I'm pretty confident that the codes cannot be broken. I'd really
like you to show how this can be done, or a reasonable plan of attack that
could reproduce the codes.
In any crypto system, it has to be assumed that the algorithm is known, and
the 'secret' is in the keys.
Of course one could steel a token, and make 9 randon guesses at the PIN over
a 3 minute period before the token is shut down. With a 6 digit PIN, this is
hard. Even assuming the theft of the token goes unnoticed, I'd certanly
notice my car-keys disapearing and me not being able ot log onto my server.
Miguel Cruz
> Since *nix has such a small market share compared to win I think that maybe
> you may want to consider doing some research.
I doubt the number of password file entries in the world's unix systems is
much (if any) smaller than the number of passwords in the world's NT
systems. Unix is more likely to be used on larger installations where there
is more at stake.
miguel
Lyalc
Individually, strong password are a good idea.
In a company or other organisation of people, there will always be a number
of passwords that can be guessed/cracked easily.
The organisation is always at risk from exploitation of passwords ( or any
othre authenticaiton technology).
Maybe the best meaure is to actually do more about controlling individual
permissions, rights and audit trails that keep trying to build stronger
'doors' in the form of passwords.
No original ideas, but my view on a recent article by Peter Tippett.
Lyal
"Bruce Barnett" <see.my.add...@domain.com> wrote in message
news:yeklmla...@grymoire.crd.ge.com...
Lyalc
for which a one-time SecureID token is valid.
Lyalc
Lyal
<Jeff Cochran> wrote in message news:3b64d04c...@news.supernews.com...
Bernd Felsche
><Jeff Cochran> wrote in message news:3b675fef...@news.supernews.com...
>> >The security community repeatedly tells us that a strong
>> >password will be much more difficult for an attacker to break
>> >than will a weak one, and because of this, we should encourage
>> >the use of strong passwords in order to protect our systems from
>> >those who would attempt to gain unauthorized access by cracking
>> >passwords.
>> Actually, strong passwords are better than weak ones, but they're just
>> a single part of a complex problem. The analogy would be a door with
>> a deadbolt versus a standard lock. Both keep honest people honest.
>> The deadbolt keeps out the guy who would slip a screwdriver in to
>> press back the striker, but neither will protect against the guy
>> who'll kick the door in.
>Strong passwords ARE better than weak ones. The problem is that passwords
>constructions typically promoted as being strong are not (provably so). So
>what is a strong password? I believe the answer to this is a password that
>has at least 7 characters and is not an "obvious" one, i.e., password.
>We say it is easy for someone who knows you to guess passwords. In
>researching this topic I set up a test. Twenty five people who have worked
>with me for ten or more years each had 5 tries to guess my password
>(newcastle - my favorite beer) and no one got it (I even had a Newcastle
>poster on the wall next to the workstation). You could say they were not
>good at what they do - they are. My point is that some things SOUND good
>but in practice, especially when you have a limited number of tries, it's a
>different ball game. Much like those brain teasers. They are all simple
>AFTER you know the answer. This is not to suggest that people should pick
>passwords easily associated with themselves, only to suggest that security
>people may be doing a disservice by running password crackers and enforcing
>absurd formulas.
Enforcing absurd formulae, if such enforcement is know a priori,
makes the remaining password space more susceptible to cracking.
After all; one doesn't have to _try_ the possible combination
that don't fit the formulae.
--
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ / ASCII ribbon campaign | I'm a .signature virus! |
X against HTML mail | Copy me into your ~/.signature|
/ \ and postings | to help me spread! |
Truman
number of users? If I know the rules for password construction, and the
usernames, I could try the same password with each username, avoiding the
lockout. If there are 10,000 passwords and 100,000 users, I should get
at least 10 valid combinations...
In article <Ime87.22349$gj1.2...@bgtnsc05-news.ops.worldnet.att.net>,
Loh...@worldnet.att.net says...
> > And when you leave the sliding glass door on the patio unlocked to
> > make it easier for your friends to come in and drink your beer or copy
> > your WaReZ then you're the kind of neighbor I'd like to have... :)
> >
> > Jeff
>
>
>
wtshaw
"Lohkee" <Loh...@worldnet.att.net> wrote:
> You have GOT to learn how to read!
You did write:
> Let's face it, if I can get to
> your
> > > system physically it won't matter how long or complicated you password
> is.
>
This is an over-confident statement.
--
Jimmy Carter is still my hero.
Jerry Leslie
This is a pretty large installation with a lot at stake, using WNT/W2K:
http://www.gcn.com/vol19_no27/dod/2868-1.html
Navy carrier to run Win 2000
IMO, Wintel systems are NOT suitable for such mission-critical applications,
but the PHBs think otherwise.
--Jerry Leslie (my opinions are strictly my own)
Miguel Cruz
> Isn't another consideration the ratio between the password space and the
> number of users? If I know the rules for password construction, and the
> usernames, I could try the same password with each username, avoiding the
> lockout. If there are 10,000 passwords and 100,000 users, I should get
> at least 10 valid combinations...
One would hope you wouldn't bother trying to brute-force the same ciphertext
multiple times.
miguel
Gareth Jones
Wow, you can cut and paste. Is this your way of admitting you were
wrong, and that breaking it isn't trivial?
Gareth
Gareth Jones
>Since *nix has such a small market share compared to win I think that maybe
>you may want to consider doing some research.
>I will agree that win could have done it better. I would have loved to see a
>user configurable parameter that would confuse the hashing algorithm while
>making it unique to the owning organization..
You miss the point again......
It is currently not feasible for most attackers to maintain a database
of password hashes for a brute force attack*. Were it to become
feasible, there are very simple techniques that can be used to defeat
such a measure, and MS would doubtless implement them.
*You claim it is feasible, but I disagree. For 10 char passwords using
only the lower case, assuming the hash is the same length as the
password (it is not - for Windows it is longer), you would need 26**10
bytes of storage. That is 128,000 terabytes. i.e. not feasible for
most attackers.
Gareth
Lohkee
boot around it. You could also put the hard drive into another moachine as
the secondary drive and access it that way.
"wtshaw" <jgf...@vgrknf.arg> wrote in message
news:jgfunj-2707...@dial-245-166.itexas.net...
Lohkee
> "Lohkee" <Loh...@worldnet.att.net> wrote:
>
> >Since *nix has such a small market share compared to win I think that
maybe
> >you may want to consider doing some research.
> >I will agree that win could have done it better. I would have loved to
see a
> >user configurable parameter that would confuse the hashing algorithm
while
> >making it unique to the owning organization..
>
> You miss the point again......
>
> It is currently not feasible for most attackers to maintain a database
> of password hashes for a brute force attack*. Were it to become
> feasible, there are very simple techniques that can be used to defeat
> such a measure, and MS would doubtless implement them.
>
MS being trusted to do the right thing?
Depends on who "most" attackers are and how the system is put together. The
storage requirements are not as large as you think (using data piggybacking
and compression techniques). Rules that significantly reduce the number of
possibilities also play an important role in reducing the problem. What
about distributed databases? How much disk space is available for free to
anyone on the Internet? The point I was making is that technology has a way
of obsoleting "truths." The difference between most good guys is that good
guys follow the rules, bad guys do not. A bad guy sees this problem as a
challenge and looks for a way to make it happen by thinking out of the box,
a good guy does the math, sees the numbers, and gives up! This is why (in my
opinion) the bad guys keep winning and the good guys keep trying.
Peter Larsen
Ken Dante wrote:
> "Lohkee" <Loh...@worldnet.att.net> writes:
> > A brute force attack, for example, will discover the password "!3&cZ@"
> > long before it will ever find the password "voodoo".
> Sure, "!3&cZ@" comes before "voodoo" in ASCII order, but your suggestion
> that a brute force attack pays off faster than a dictionery attack is
> almost never correct, not even in your example.
The usual sequence is - as per security advice I got from someone doing
that stuff (security consultant) for a living - a dictionary attack
first, and a brute force attack if the dictionary attack fails. And just
that is what makes a passphrase cost-efficient in case a long string is
required.
Kind regards
Peter Larsen
--
*************************************************************
* This posting handcrafted by Peter Larsen, MCSE *
* My default email address is: muyio...@yahoo.com *
* My site is at: http://www.muyiovatki.dk *
*************************************************************
Peter Larsen
Bernd Felsche wrote:
> Enforcing absurd formulae, if such enforcement is know a priori,
> makes the remaining password space more susceptible to cracking.
> After all; one doesn't have to _try_ the possible combination
> that don't fit the formulae.
Simple math will show that an amazing amount of combinations will be
removed from the math by complexity requirements that are ill applied.
> --
> /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
> \ / ASCII ribbon campaign | I'm a .signature virus! |
> X against HTML mail | Copy me into your ~/.signature|
> / \ and postings | to help me spread! |
--
Peter Larsen
Lyalc wrote:
> Maybe the best meaure is to actually do more about controlling individual
> permissions, rights and audit trails that keep trying to build stronger
> 'doors' in the form of passwords.
One should not assume that one layer of security is sufficient, there is
also the "whatif they pass that one" concern. There is probably still a
snippet somewhere on cnn.com about "honeypot" networks ....
Gareth Jones
>> >Since *nix has such a small market share compared to win I think that
>maybe
>> >you may want to consider doing some research.
>> >I will agree that win could have done it better. I would have loved to
>see a
>> >user configurable parameter that would confuse the hashing algorithm
>while
>> >making it unique to the owning organization..
>>
>> You miss the point again......
>>
>> It is currently not feasible for most attackers to maintain a database
>> of password hashes for a brute force attack*. Were it to become
>> feasible, there are very simple techniques that can be used to defeat
>> such a measure, and MS would doubtless implement them.
>>
>
>MS being trusted to do the right thing?
It has nothing to do with trust.
>Depends on who "most" attackers are and how the system is put together.
Most attackers means more than 50% of the people who we think might be
cracking passwords. There are very few people who have the resources
to do what you are suggesting.
>The
>storage requirements are not as large as you think (using data piggybacking
>and compression techniques).
Really? Do you know a compression technique that can make an
appreciable difference to the storage requirement (i.e. reduce it by
one or more orders of magnitude), without making the whole idea
unviable (because uncompressing the data will be slower - and the only
reason to do something like this is to reduce the amount of time spend
computing hashes).
> Rules that significantly reduce the number of
>possibilities also play an important role in reducing the problem.
What you need to do with this statement is repeat it a thousand times,
in the hope that it will seem more true...oh..,..you've done that.
>What
>about distributed databases? How much disk space is available for free to
>anyone on the Internet?
Is it relevant? You want to make a brute force attack faster by
precomputing hashes. So if it takes t time to computer a hash, and
your search space is size n, you would be ordinarily be facing a task
of magnitude tn. If by precomputing, you can fetch a hash in time u,
you are hoping to save (t-u)n. The problem here is that the amount of
time you have to spend is still proportional to the search space. Even
if you save a massive amount of time per hash, the computational
resources required will be huge, because the search space is huge.
Besides, given that thousands of hashes can be calculated on a home pc
in a second, the idea that fetching them from a distributed dbase on
the internet could be faster is ludicrous.
>The point I was making is that technology has a way
>of obsoleting "truths."
I know, but that point is not correct. If the "truths" are in fact
incorrect ideas that some people insist on, then yes. one day reality
might impinge on them and shatter their illusions.
>The difference between most good guys is that good
>guys follow the rules, bad guys do not. A bad guy sees this problem as a
>challenge and looks for a way to make it happen by thinking out of the box,
>a good guy does the math, sees the numbers, and gives up!
You seem to think that you are the only good guy who has dared to
think about this stuff....I hate to disillusion you, but password
cracking was invented a long time ago, and people have been thinking
pretty hard about it for quite some time.
Gareth
Walter Roberson
Gareth Jones <gar...@uberdog.net> wrote:
:Is it relevant? You want to make a brute force attack faster by
:precomputing hashes. So if it takes t time to computer a hash, and
:your search space is size n, you would be ordinarily be facing a task
:of magnitude tn. If by precomputing, you can fetch a hash in time u,
:you are hoping to save (t-u)n. The problem here is that the amount of
:time you have to spend is still proportional to the search space. Even
:if you save a massive amount of time per hash, the computational
:resources required will be huge, because the search space is huge.
Ummm, not quite.
If we start with the traditional Unix modified-DES scheme,
we have a maximum problem size of 2^56 keys and 2^12 different salts,
with a result of 2^68 different possible password entries.
This is large number, to be sure, but if you have precomputed
all those hashes, then you can do a *single* lookup of the 13 character
hashed result. If the time to look up that hash is u, then you
have answered the *complete* problem in time u.
We then have to ask what the fastest algorithm is to look up a single entry
in a database of sized 2^68 entries. That is, of course, going to
depend on some trade-offs chosen by the database implimenter, and the
answer is going to be different during the construction phase (which
has to be able to write new entries easily) as compared to the later
static-lookup phase (in which everything becomes read-only.) We can see,
though, that the answer is going to be no worse than using a binary
tree with one hard-disk datablock read required per bit (ie, maximum
68 datablocks fetched per lookup.) In other words, the lookup is
going to be no worse than order log2(n) in your notation,
and we can almost certainly do a LOT better than that, probably
better than log256(n) for a maximum of 13 disk reads. Add a top level
cache that keeps the first couple of megabytes in memory and you could
probably get it down to on the order of 5 or 6 disk blocks read
without a lot of trouble or using a particularily 'big' computer.
Yes, there would need to be an in-memory search that's going to be
log<something> time, but the constant on that is going to be very small
so the overall time is going to end up being dominated by the disk read
time of everything that didn't fit in the cache.
So... if you had the complete database stored and accessible over
the 'net, the complete search time for an individual entry is
going to be approximately
(network connection time + 2 * network latency + time to read 6 blocks)
which is going to be much MUCH MUCH less than the t*n time that you
are talking about.
Lohkee
> "Lohkee" <Loh...@worldnet.att.net> wrote:
>
> >> >Since *nix has such a small market share compared to win I think that
> >maybe
> >> >you may want to consider doing some research.
> >> >I will agree that win could have done it better. I would have loved to
> >see a
> >> >user configurable parameter that would confuse the hashing algorithm
> >while
> >> >making it unique to the owning organization..
> >>
> >> You miss the point again......
> >>
> >> It is currently not feasible for most attackers to maintain a database
> >> of password hashes for a brute force attack*. Were it to become
> >> feasible, there are very simple techniques that can be used to defeat
> >> such a measure, and MS would doubtless implement them.
> >>
> >
> >MS being trusted to do the right thing?
>
It has everything to do with trust. Why do you think there are so many
buffer overflaw (yes this was intentional) attacks out there (could it be
that MS was more interested in money than product quality).
>
> >Depends on who "most" attackers are and how the system is put together.
>
> Most attackers means more than 50% of the people who we think might be
> cracking passwords. There are very few people who have the resources
> to do what you are suggesting.
>
Such a myopic view of the world. If I implement it, then I can make it
available to anyone with a 'net connection. How do you think the
scrptkiddies get their stuff????????
> >The
> >storage requirements are not as large as you think (using data
piggybacking
> >and compression techniques).
>
> Really? Do you know a compression technique that can make an
> appreciable difference to the storage requirement (i.e. reduce it by
> one or more orders of magnitude), without making the whole idea
> unviable (because uncompressing the data will be slower - and the only
> reason to do something like this is to reduce the amount of time spend
> computing hashes).
Yes I do. But since Winzip is common, let' use that by way of example
(although there are better methods). If I have a large amount of data then
1. Break it up into very small files, say 500K
2 Compress each file.
3. Create a directory of files indicating the data ranges within each
file.
4. Search the directory and only unzip the small file that you know will
contain the desired data.
People think the binary search is the most efficient. NOT TRUE. You can find
any record in a billion record file with only 1 (YES ONE) hit to the hard
drive (which can only block 64K at a time) as opposed to the 32 some odd
tests required by the very efficient binary search Looking at binary, AVL,
2/3 tress your calculator will undoubtedly prove me wrong, but then, we look
at things in different ways. Such a file system as I have alluded to has
been designed (by me) for a large entity which I am not at liberty to
disclose. The method listed above is not what I designed but in principal is
similar and so you should be able to figure the rest out by yourself.
Datapiggybacking could also be employed. I can use the filename to help
reduce the amount of storage space, i.e.,
a2.zip - 2 char pw starting with a
a3.zip - 3 char pw starting with a
aa4.zip - 4 char pw satring with aa
aaaa5 - five char pw staring with aaaa
aaab5 - five char pw starting with aaab
etc. With long filnames there are many possibilities which could be
exploited here.
Bottom line - there are numerious techniques that could be employed to
greatly reduce the storage requirements, some of are loosly described above
as well as others that i will keep to myself. I'm not going to map out a
system for you. Many of the techniques I have developed over many years of
routinely working with > 1 terabyte databases. These techniques are what
make me sought after within my field. Come up with 200,000 or so and I will
be more than happy to map it all out for you.
>
> > Rules that significantly reduce the number of
> >possibilities also play an important role in reducing the problem.
>
> What you need to do with this statement is repeat it a thousand times,
> in the hope that it will seem more true...oh..,..you've done that.
Have it your way. If I have 100 items to look at, and it takes the same
amount of time to look at each one, and I delete 50 of them, it will take
less time. What is SO difficult for you to understand? Or is this really
about hanging on to old ideas because the new ones are too scary??
>
> >What
> >about distributed databases? How much disk space is available for free to
> >anyone on the Internet?
>
> Is it relevant?
The people that cracked DES thought so.
You want to make a brute force attack faster by
> precomputing hashes. So if it takes t time to computer a hash, and
> your search space is size n, you would be ordinarily be facing a task
> of magnitude tn. If by precomputing, you can fetch a hash in time u,
> you are hoping to save (t-u)n. The problem here is that the amount of
> time you have to spend is still proportional to the search space. Even
> if you save a massive amount of time per hash, the computational
> resources required will be huge, because the search space is huge.
> Besides, given that thousands of hashes can be calculated on a home pc
> in a second, the idea that fetching them from a distributed dbase on
> the internet could be faster is ludicrous.
You MUST work for the government. Do a search on DESCHALL and you will find
an abstract "A brute force search of DES keyspace" that proves without
reservation you are incorrect. BIG HINT: It has already been done, in fact,
with some pretty pathetic equipment (by today's standards). The same
technique could easily be apllied to passwords. The deschall folks did over
72 quadrillion keys on the internet in about 90 days as I recall. Try that
on your home PC.
>
> >The point I was making is that technology has a way
> >of obsoleting "truths."
>
> I know, but that point is not correct. If the "truths" are in fact
> incorrect ideas that some people insist on, then yes. one day reality
> might impinge on them and shatter their illusions.
Truths may also be correct at one point in time and become obsolete simply
because of technological advances that make the once impossible, possible!
>
> >The difference between most good guys is that good
> >guys follow the rules, bad guys do not. A bad guy sees this problem as a
> >challenge and looks for a way to make it happen by thinking out of the
box,
> >a good guy does the math, sees the numbers, and gives up!
>
I was refering to you.
> You seem to think that you are the only good guy who has dared to
> think about this stuff....I hate to disillusion you, but password
> cracking was invented a long time ago, and people have been thinking
> pretty hard about it for quite some time.
>
I would disagree in part. Many people can think about many things but only
within the context of their experience. You own comments on data storage
requirements, and time requirments, illustrate this point very nicely.
Until recently, distributed attacks were COMMONLY not applied, a fact
reflected in the design of most PW cracking software available today (it
still asssumes a child on a PC working in the dead of night). I THINK the
boys at Lopht recently changed their package to better reflect current
architecture, but am not sure, and really don't care as they are about 20
years behind me.
Now that you mention it, how many other papers are out there challanging
conventional wisdom, specifically on password cracking (my first paper) and
on strong passwords (my second)? Please offer verifiable evidence on this
one (a link will do). A large majority of security professionals out there
DO NOT think, they simply regurgitate what they have been told without ever
questioning it. Much of the crap within the security community is based on
long obsolete ideas and remains unquestioned because many of the so-called
professionals don't know their collective ass form a hole in the ground.
This was, I think, the main point in the thread on CISSP certifications.
> Gareth
Lohkee
have it figured out. Just add an additonal top level table to further break
down the blocks.
"Walter Roberson" <robe...@ibd.nrc.ca> wrote in message
news:9jv8bm$5pj$1...@canopus.cc.umanitoba.ca...
Gryph
Quill claiming the address qu...@thewell.org :
> >
>
>
>
I'd suggest that you probably using a pass-'phrase', not a pass-'word'. Am
I right? Pass-phrases are easier to remember and just as difficult to crack
(IMHO)
--
"This isn't an argument! It's a contradiction!
No it isn't!
Yes it is!"
Walter Roberson
Lohkee <Loh...@worldnet.att.net> wrote:
:Thank you Walter. It can be done in ONE hit to the disk. You pretty much
:have it figured out. Just add an additonal top level table to further break
:down the blocks.
Ah, I just realized:
If one uses a fixed size to store the corresponding passwords
(e.g., left-justified, null-padded, 8 bytes each), then one can
*without any index file or index table* simply directly transform
the hashed password into a block number on disk. For example,
take the part after the salt, and transform that into a 56 bit
number (since it's the hash of a 56 bit number anyhow). Take one
character of the salt and that's a 6 bit number itself. SHIFT and OR
to get a 62 bit disk block number. Read that block, and index
it by the 6 bit number corresponding to the second character
of the salt, to know which password to pull out of the block.
2^6 salts * 8 bytes/salt = 512 bytes, aka one standard disk block.
If, though, there isn't a way to transform the 11 post-salt bytes
of the encrypted password into a a 56 bit value (looks to me that
it's a 64 bit value stored 6 bits per character), the lookup problem
stays pretty much the same. The 64 bit encrypted password gets you
to the right group, the first character of the salt gets you to
the exact block within the group of 64 blocks, and the second character
of the salt gets you to the exact password. Still just one lookup.
All of this presumes that you have a storage space of at least
2^70 blocks, which is a Rather Big Storage Device. If you have
a lot less space than 2^64 bytes (2^53 blocks), then you are going to
have an interesting time with storing the pre-computes ;-)
Any discussion of lookup times for the reversing function, should
indicate the storage assumptions, especially if the requirement is
to be imposed that storage is less than the 2^64 bytes that
would be needed to store all the possible plain-text passwords.
Lohkee
Now, transform your idea to a distributed model! TA DA!
fonzy rella
Lohkee raises some good points about the strong passwords. I'm a
sysadm and am always trying to balance neccessary user rights against
system security. I've always found that enforcing a strong password
system has another security hole....The USER, who cannot remember
his/her password. Said password gets written down and "hidden" in one
of four places. So now someone could just wait for a lunch/bathroom
break and TADA password heaven.
I don't enforce any strong password tech, rather I strongly advise
that a person takes a word that they wil not forget and replace alpha
with numerics. s33 h0w th1s c0uld w0rk guy5? Also my company has
written policies that end users must sign that activities performed
under their user accounts will be considered to be their actions and
to protect their passwords, any time an end user see questionable
activities it should be reported.
Any lock that you can create someone out there can pick. Log files and
multiple layers of security are vital to protecting your data.
OT: anyone read Cryptonomicon? Now those dudes are serious about
protecting data!
On Fri, 27 Jul 2001 04:04:27 GMT, "Lohkee" <Loh...@worldnet.att.net>
wrote:
>Strong Passwords
>
>
>The security community repeatedly tells us that a strong password will be
>much more difficult for an attacker to break than will a weak one, and
>because of this, we should encourage the use of strong passwords in order to
>protect our systems from those who would attempt to gain unauthorized access
>by cracking passwords. The wisdom of this advice is continually reinforced
>by an army of security consultants who are more than happy to demonstrate
>the ease with which commonly available password cracking software can
>recover so-called "weak" passwords, i.e., words taken from a dictionary,
>common names, etc.
>
>These same experts frequently recommend the use of special password filters
>designed to systematically enforce password complexity by disallowing any
>password that does not meet some predefined rule set, or the running of
>password cracking software in conjunction with the appropriate feedback to
>any user unfortunate enough to have their password "cracked" by the program.
>Some experts even recommend using both techniques simultaneously (although
>to do so is a rather bizarre contradiction when you stop and really think
>about it). Regardless of the method chosen, the goal is essentially the
>same, to reduce risk by enforcing the use of strong passwords.
>
>Passwords are generally considered to be reasonably "strong" if they are six
>or more characters in length and contain at least one character from each of
>the following four sets: uppercase alpha, lowercase alpha, numeric, and
>punctuation or other special characters. Passwords constructed using this
>(or any similar) set of rules are inherently stronger than words chosen from
>a dictionary because they are by design much more difficult to attack.
>Looking at an example of each ("!3&cZ@" as opposed to "voodoo") we can
>easily see why; and how running password crackers to identify and eliminate
>weak passwords will improve the overall security of our systems. At least
>this is what many security consultants would very much like you to believe.
>
>Unfortunately, passwords that follow these commonly prescribed rules are
>only "strong" in an absurd fantasy world where the only possible method of
>cracking passwords is by a dictionary attack. In a world where more than
>one method exists for the cracking of passwords, you may want to consider
>the following: If you compare any two passwords of equal length you will
>find, in many cases, that selecting what security professionals insist would
>be a very strong password, as opposed to randomly choosing a word that might
>be found in any dictionary, will actually result in choosing a password that
>is provably much easier to crack! A brute force attack, for example, will
>discover the password "!3&cZ@" long before it will ever find the password
>"voodoo". The inherent "strength" of a password such as "!3&cZ@" is an
>illusion. It appears to be stronger only because the sequence of characters
>forms a pattern unfamiliar to the average human being; to a computer, it is
>just another string of ones and zeros. In fact, at the binary level one
>password appears pretty much the same as another.
>
>01001100 01101111 01101000 01101011 01100101 01100101
>01000000 01011110 01011000 01110001 00110011 00100001
>
>Password content is an issue that is often raised (and taken out of
>context). Conventional wisdom states that one should not use the name of a
>spouse, pet, child, etc. for a password because it will make it easier for
>an attacker who knows you to guess your password. This is obviously good
>advice that just happens to illustrate an extremely important point. The
>word "password" is not inherently weak because of its composition; it is
>"weak" only because of its unique association within an extremely limited
>context. There is a big difference in not choosing a password that is in
>some way "connected" to yourself and choosing a password that may be found
>in a dictionary but is in no way associated to you or your environment.
>
>The truth is that passwords resistant to one method of attack may be
>extremely susceptible to another, and prescribing rules that fail to
>consider this basic fact, is a serious mistake. Cracking passwords really
>demonstrates nothing at all other than perhaps the ease with which it is
>possible to con people who do not know any better. Creating rules that have
>a tendency to create provably weaker passwords is bad enough, but when you
>start systematically enforcing those rules, things really start to go
>downhill fast.
>
>Like a credit card number, the strength of a password is derived solely from
>there being a vast number of possibilities for any given account.
>Predictably, the systematic enforcement of any rule that eliminates a
>significant number of possibilities serves only to weaken the overall
>mechanism because the attacker has fewer possibilities to try thus
>increasing the probability of success. If too many possibilities are
>eliminated, we incur the additional risk of inadvertently opening up avenues
>of attack previously thought to be impractical. Many of the commonly
>prescribed formulas for so-called "strong" passwords fall into both of these
>traps.
>
>Suppose, for example, we have a rule which states that all passwords must be
>six or more characters in length and contain at least one character from
>each of the following four sets: uppercase alpha, lowercase alpha, numeric,
>and punctuation (or other special characters). Assuming a six-character
>password, an analysis of this rule would yield the following: Without the
>rule, a user's password can be from one to six characters in length, and may
>use any one of ninety-five characters in each position. The total number of
>passwords possible is (951 + 952 + 953 + 954 + 955 + 956) 742,912,017,120.
>With the rule, the user's password must be a minimum of six characters in
>length and include at least one character from each of the four sets. The
>number of passwords possible is now only (952 x 262 x 10 x 33) or
>2,013,297,000
>
>By enforcing this rule, we have (in the name of hardening our system against
>an attacker attempting to gain unauthorized access by cracking passwords)
>just eliminated 99.7% of the possibilities that the attacker would otherwise
>have had to of tried. In the process of eliminating a large percentage of
>the possibilities, we have also managed to transform the simple brute force
>attack from an impractical means to the preferred means of cracking
>passwords. Since the rule has effectively eliminated 99.7% of the
>possibilities for us, we no longer have to waste time testing them. On the
>typical stand-alone system a brute force attack specifically designed to
>test only those passwords meeting our criteria for a so-called "strong"
>password would take less than a day to test all of the possibilities and
>have a 100% success rate. Try that with a dictionary attack! It could be
>argued that an outsider would have no way of knowing the rule, however, you
>still have to take into consideration all of the insiders who do know the
>rule.
>
>We can prove mathematically that the fundamental strength of a password is
>derived from the statistical improbability of being able to associate the
>correct password for a given account when there are an enormous number of
>possibilities and all are equally probable. We can also prove
>(mathematically) that passwords which follow the generally accepted and
>prescribed rules for so-called "strong" passwords are, in fact, a great deal
>easier for the attacker to crack using methods other than a dictionary
>attack. Rules designed to systematically enforce so-called strong
>passwords, unless very carefully crafted, may actually perform contrary to
>their intended purpose. There is a world of difference between simply
>recommending that users choose a password containing a mix of characters and
>systematically enforcing such a rule. In the first instance, all passwords
>are still equally possible thus preserving the inherent strength of the
>mechanism; in the second, a significant number of possibilities may be
>eliminated thereby accomplishing exactly the opposite of the desired result.
>The practical effect of any proposed rule should be fully understood and
>carefully tested before implementation. Any rule that significantly reduces
>the number of possibilities serves no purpose other than to weaken the
>overall mechanism and should be flatly rejected.
>
>Looking at the following table we can see that a rule requiring the user to
>choose a password at least seven characters in length would not
>significantly reduce the overall number of possibilities (about .01%), but
>would still eliminate a large number of "easy" passwords, including a lot of
>commonly used words, names, etc.
>
>95 1 95
>95 2 9,025
>95 3 857,375
>95 4 81,450,625
>95 5 7,737,809,375
>95 6 735,091,890,625
>95 7 69,833,729,609,375
>95 8 6,634,204,312,890,625
>
>We could further strengthen this rule (without appreciably affecting the
>overall number of possibilities) by filtering out some of the more "obvious"
>passwords such as Password, PASSWORD, password, any password that is simply
>a string of the same character repeated, User ID, machine name, company
>name, the user's real first and last name, and words generally associated
>with system accounts such as CISCO, router, etc.
>
>In a sense, this whole discussion is pointless. It is a given that any
>password up to eight characters in length is easily cracked by even a
>marginally competent attacker. In a year or so, the same will also be true
>for ten character passwords. Does this mean that passwords are outdated or
>that we should force the user to remember even longer passwords? Not at
>all, if we keep things in perspective. Running a password cracker against
>the entire password file on a dedicated system at extremely high speeds is
>one thing (essentially an unlimited number of attempts to identify a given
>password). Attempting to identify the password for a particular user within
>a very limited number of attempts (usually three) before the account is
>automatically disabled, is quite another. Which three passwords, out of the
>billions of possibilities, should be tried? Attempting to equate these two
>very different scenarios is absurd (although security people are fond of
>doing just that and thereby trying to justify the use of password crackers).
>
>There are a number of other things we can do to further enhance our defense
>against an individual gaining access by cracking passwords:
>
>1. Set the number of attempts at entering a password to two, or at most,
>three.
>
>2. Set the days and hours that a user is allowed to access the system.
>
>3. Specify the terminal/s that a given user is allowed to logon to.
>
>4. Prohibit remote logons or direct remote access to the workstation unless
>it is ABSOLUTELY necessary. Any user claiming to need such
>access should be made to prepare a formal justification for management
>review. All other avenues of satisfying the users needs should be
>exhausted before granting this request. Any accounts having remote access
>should be rigorously monitored.
>
>In conjunction with a reasonable password rule, the above steps will make it
>all but impossible for a remote user to gain access by guessing passwords.
>It is also important to protect access to the password file. This will be
>discussed at length later on.
>
>
>Lohkee
>
>
>
>
Two wrongs don't make a right, but three lefts do.
Start here ==> http://fly.to/warezpage
and here ==> http://www.laker.net/mari/alt/2600.html
then here ==> http://drink.to/warezhunter
Need help with your FTP? ==> http://alt2600.com/brat
Wanna set up a server? ==> http://start.at/jaybirds
CDR questions? ==> http://alt2600.com/superman
Need a crack? ==> http://astalavista.box.sk/
Need a serial? ==> http://lowrider.hili.com/~stigmata/serials/
Wanna know what I said? ==> http://www.netlingo.com
wtshaw
"Lohkee" <Loh...@worldnet.att.net> wrote:
> I don't see why. Regardless of how securre the OS may be, you can always
> boot around it. You could also put the hard drive into another moachine as
> the secondary drive and access it that way.
>
Which is essential to maintaining good security, the option to do as you
say. The problem I see is that you assume there is something to find when
there need not be.
The very fears that the government fears can happen regarding robust OS's
happened many years ago. A plus for them is that most do not realize that
the option has been there. I've always know it. A big negative is that
retrofitting to remove that option is all but impossible in ultra-cheap
but durable legacy hardware and its public domain software.
wtshaw
"Lohkee" <Loh...@worldnet.att.net> wrote:
>... The difference between most good guys is that good
> guys follow the rules, bad guys do not. A bad guy sees this problem as a
> challenge and looks for a way to make it happen by thinking out of the box,
> a good guy does the math, sees the numbers, and gives up! This is why (in my
> opinion) the bad guys keep winning and the good guys keep trying.
This requires good guys to be dumb sheeple. It is counter intuitive that
the less you know the better it is. Writing bad rules does not yield
goodness, and writing good and constitutional rules does not yield
badness. Perhaps your heros were the confession extractors of the
inquisitiion who could not take no for an answer.
People are not so easily placed in two groups except those who like to
play cops and robbers, or is that peace officers and perpetrators, and
those that have no reason to think criminal.
Strangely, people without general supervision manage to do quite well with
only the thinest of accepted guidelines. It is in the innoculation of
crippling ideas that they are often made to be and act inferior. Rules
may only benefit the rulemakers and further their power without
intelligent reasons for them. Arbitrary always sucks.
Gareth Jones
>In article <l456mtspglefii21s...@4ax.com>,
>Gareth Jones <gar...@uberdog.net> wrote:
>:Is it relevant? You want to make a brute force attack faster by
>:precomputing hashes. So if it takes t time to computer a hash, and
>:your search space is size n, you would be ordinarily be facing a task
>:of magnitude tn. If by precomputing, you can fetch a hash in time u,
>:you are hoping to save (t-u)n. The problem here is that the amount of
>:time you have to spend is still proportional to the search space. Even
>:if you save a massive amount of time per hash, the computational
>:resources required will be huge, because the search space is huge.
>
>Ummm, not quite.
>
>If we start with the traditional Unix modified-DES scheme,
>we have a maximum problem size of 2^56 keys and 2^12 different salts,
>with a result of 2^68 different possible password entries.
>This is large number, to be sure, but if you have precomputed
>all those hashes, then you can do a *single* lookup of the 13 character
>hashed result. If the time to look up that hash is u, then you
>have answered the *complete* problem in time u.
Duh. You right. I wrong. Will now crawl back under my stone..:-(.
Gareth
Bruce Barnett
> system has another security hole....The USER, who cannot remember
> his/her password.
That's one advantage of giving people time to pick passwords.
If you force them to pick one RIGHT NOW DAMMIT! - they will do a bad job.
> I don't enforce any strong password tech, rather I strongly advise
> that a person takes a word that they wil not forget and replace alpha
> with numerics. s33 h0w th1s c0uld w0rk guy5?
Not well in some cases. There are rules in Alec Muffet's crack that
says "take a word from the dictionary, change "i" to "1" and see if it
matches. As in "/isi1"
Any simple rule for picking passwords can also be placed in a password
cracking program.
--
Bruce <barnett at crd. ge. com> (speaking as myself, and not a GE employee)
Bill Unruh
>nextname857@DIE_SPAMMING_SCUM_yahoo.dotcom (fonzy rella) writes:
>> system has another security hole....The USER, who cannot remember
>> his/her password.
>That's one advantage of giving people time to pick passwords.
>If you force them to pick one RIGHT NOW DAMMIT! - they will do a bad job.
>> I don't enforce any strong password tech, rather I strongly advise
>> that a person takes a word that they wil not forget and replace alpha
>> with numerics. s33 h0w th1s c0uld w0rk guy5?
Weak. Such replacements are trivial for a computer to do, and they add
very little entropy. ( ie they convert a few single letter to two-- not
even as good as capitalising some letters are there at least every letter
could be capitalised. .
ClubMonkee
passwords.
You are right when you say that password crackers use a dictionary attack -
however - this attack is normally done first. Cracking passwords using a
dictionary attack is normally very very easy when cracking passwords set by
the typical user hence the policy of setting a strong passwords. Dictionary
attacks are normally done first because they will help crack passwords which
have a human relevance (essentially the processing has already being done).
The brute force attack will try every possible combination of a alpha,
numeric and country specific symbols regardless of the human element.
However, testing a password of reasonable length would take years to
complete on the standard computer hardware available to most people - again
this justifies the use of strong passwords. Most modern computer hardware
can run through each combination of characters from 1-5 in a matter of
seconds, this further justifies the reason for forcing users to set longer
passwords.
Try it for yourself:
Install a password brute force cracking utility for MS Word97 - these are
easy to find.
Password protect a document.
Set the password to something relatively easy i.e. voodoo
Then run the checker - make a note of the time it takes for you as an
individual to discover the password using the methods available via the
cracking software.
The set the password to something using all possible symbols i.e AŁk7$8
which is the same length as the word voodoo - then make a note of the time
it took you to reveal the password, you will notice that the second password
took longer for the software to reveal. This is because the password is
longer because it isn't - it is because the brute force algorithm has to
take into account more combinations of characters.
However, your analysis of people ignoring short passwords is correct - we
are effectively shortening the number of possible passwords - but since the
total number of short passwords can be cracked within minutes or even
seconds - most hackers try them by default - before trying the longer
passwords and leaving their machines to process the information over a
number of days, weeks or months.
I hope this explains a little the reason for strong passwords.
Regards,
Wizard :-)
"Lohkee" <Loh...@worldnet.att.net> wrote in message
news:fL587.8557$LP2.8...@bgtnsc06-news.ops.worldnet.att.net...
Lohkee
"ClubMonkee" <wizza...@hotmail.com> wrote in message
news:tmdann1...@xo.supernews.co.uk...
> Hmm - there are few things that wrong with your analysis of strong
> passwords.
>
> You are right when you say that password crackers use a dictionary
attack -
> however - this attack is normally done first. Cracking passwords using a
> dictionary attack is normally very very easy when cracking passwords set
by
> the typical user hence the policy of setting a strong passwords.
Dictionary
> attacks are normally done first because they will help crack passwords
which
> have a human relevance (essentially the processing has already being
done).
> The brute force attack will try every possible combination of a alpha,
> numeric and country specific symbols regardless of the human element.
> However, testing a password of reasonable length would take years to
> complete on the standard computer hardware available to most people -
again
> this justifies the use of strong passwords. Most modern computer hardware
> can run through each combination of characters from 1-5 in a matter of
> seconds, this further justifies the reason for forcing users to set longer
> passwords.
Re-read the paper. My point was that enforcing strong rules could make the
dictionary attack obsolete. Why use an "hit or miss" method when the brute
force has been made practical by the rule????
>
> Try it for yourself:
>
> Install a password brute force cracking utility for MS Word97 - these are
> easy to find.
>
> Password protect a document.
>
> Set the password to something relatively easy i.e. voodoo
> Then run the checker - make a note of the time it takes for you as an
> individual to discover the password using the methods available via the
> cracking software.
>
> The set the password to something using all possible symbols i.e AŁk7$8
> which is the same length as the word voodoo - then make a note of the time
> it took you to reveal the password, you will notice that the second
password
> took longer for the software to reveal. This is because the password is
> longer because it isn't - it is because the brute force algorithm has to
> take into account more combinations of characters.
You have interesting software. If the brute force is going low to hi,
voodoo is one of the last passwords that will be tried.
It is a function of the ASCII table, which is why I chose it. Upper case A
is dec 65 whereas v is 118. Think about it.
>
> However, your analysis of people ignoring short passwords is correct - we
> are effectively shortening the number of possible passwords - but since
the
> total number of short passwords can be cracked within minutes or even
> seconds - most hackers try them by default - before trying the longer
> passwords and leaving their machines to process the information over a
> number of days, weeks or months.
>
> I hope this explains a little the reason for strong passwords.
I understand the need for strong passwords, I simply disagree on what
exactly constitutes a "strong" password.
de...@fnmail.com
at use but the algorhitm used to enforce the enryption scheme plays a
greater role. Otherwise how is Blow fish better than MD5 os Shah ?
Enjoy!
Debashish Mukherjee
de...@fnmail.com
>NT uses only 14 characters for the passwords.
That's why you have programs like 10phtcrack that can break NT
passwords.
Enjoy!
Debashish Mukherjee
Bruce Barnett
> > The set the password to something using all possible symbols i.e AŁk7$8
> > which is the same length as the word voodoo - then make a note of the time
> > it took you to reveal the password, you will notice that the second
> password
> > took longer for the software to reveal. This is because the password is
> > longer because it isn't - it is because the brute force algorithm has to
> > take into account more combinations of characters.
>
> You have interesting software.
Which software do you use?
The ones I've used do the same thing as ClubMonkee's.
Lohkee
"Bruce Barnett" <see.my.add...@domain.com> wrote in message
news:yeky9p3...@grymoire.crd.ge.com...
> "Lohkee" <Loh...@worldnet.att.net> writes:
>
> > > The set the password to something using all possible symbols i.e
AŁk7$8
> > > which is the same length as the word voodoo - then make a note of the
time
> > > it took you to reveal the password, you will notice that the second
> > password
> > > took longer for the software to reveal. This is because the password
is
> > > longer because it isn't - it is because the brute force algorithm has
to
> > > take into account more combinations of characters.
> >
> > You have interesting software.
>
>
> Which software do you use?
> The ones I've used do the same thing as ClubMonkee's.
>
Look at an ascii table. You will see that A comes way before v. Assuming a
traditional brute force (low to high), and a password of the same length, it
is clear that any password starting with A will be cracked long before one
starting with v.
The software makes no difference (unless it is doing something very
strange - like going from high to low).
Jeff Makey
Lohkee's exposition on password strength completely fails to take into
account the lifetime of a password (i.e., the interval between
changes). Any such treatise that ignores this critical element should
be viewed with extreme skepticism.
In article <fL587.8557$LP2.8...@bgtnsc06-news.ops.worldnet.att.net>,
Lohkee <Loh...@worldnet.att.net> wrote:
>Passwords are generally considered to be reasonably "strong" if they are six
>or more characters in length and contain at least one character from each of
>the following four sets: uppercase alpha, lowercase alpha, numeric, and
>punctuation or other special characters.
The apparent basis for this unsubstantiated claim is Microsoft's
"Implementing Guidelines for Strong Passwords" at
http://www.microsoft.com/ntserver/techresources/security/password.asp .
Your first error is your claim that the Microsoft guideline is
"generally" accepted, which simply has no basis in fact. Your second
error is that you misrepresent their standard, which requires the use
of only 3 of the 4 character classes rather than the use of all 4 as
in your strawman argument.
>With the rule, the user's password must be a minimum of six characters in
>length and include at least one character from each of the four sets. The
>number of passwords possible is now only (952 x 262 x 10 x 33) or
>2,013,297,000
As Gorazd Bozic pointed out in <3B618D34...@arnes.si>, you
undercounted by a factor of 24. Combinatorial math is hard when
you're out of practice. I recommend consulting an expert.
>We can prove mathematically that the fundamental strength of a password is
>derived from the statistical improbability of being able to associate the
>correct password for a given account when there are an enormous number of
>possibilities and all are equally probable.
Given your demonstrated lack of skill in combinatorial math I doubt
you could derive such a mathematical proof. However, even if you
copied someone else's proof it would still be irrelevant in the real
world, because all passwords are not equally probable. We know this
because of the amazing success of dictionary-based attacks on
passwords. Passwords based on dictionary words have a much higher
probability of being used than randomly chosen passwords.
>We could further strengthen this rule (without appreciably affecting the
>overall number of possibilities) by filtering out some of the more "obvious"
>passwords such as Password, PASSWORD, password, any password that is simply
>a string of the same character repeated, User ID, machine name, company
>name, the user's real first and last name, and words generally associated
>with system accounts such as CISCO, router, etc.
Ah. You're talking about what Alec Muffett implemented in his
"cracklib" library 7 years ago. Clueful system administrators have
long been using such a tool to help keep people from choosing
passwords that can be quickly guessed by dictionary-based cracking
tools. These same admins also occasionally *use* those cracking tools
to test the effectiveness of the password filter.
>It is a given that any password up to eight characters in length is
>easily cracked by even a marginally competent attacker.
No. I would only say it is given that marginally competent crackers
could brute force all passwords of up to 5 (five) characters, as it
takes about a week for a 933 MHz Pentium III to exhaustively test such
short UNIX passwords. Cracking 6-character passwords is more than 100
times harder; a skillful (or wealthy) cracker is required to do this
in a useful time. The resources required to crack any 8-character
UNIX password in a reasonable time (say, less than a month) are
greater than those available even here at SDSC, where we have the 13th
most powerful computer in the world according to the list at
http://www.top500.org/list/2001/06/ .
>In a year or so, the same will also be true for ten character passwords.
Only in our dreams (or nightmares, as the case may be). I predict
that the computing power available to crack passwords will increase by
a factor of much less than 16,000 in the next year (or so).
>There are a number of other things we can do to further enhance our defense
>against an individual gaining access by cracking passwords:
>
>1. Set the number of attempts at entering a password to two, or at most,
>three.
And then what? Lock the account? *Very* few sites are willing to
tolerate the denial of service that can easily result from such a
policy. Most sites find it much more practical to have a system that
is resistant even to sustained high-speed cracking attempts.
>2. Set the days and hours that a user is allowed to access the system.
Another opportunity for denial of service.
>3. Specify the terminal/s that a given user is allowed to logon to.
Yet another opportunity for denial of service.
>4. Prohibit remote logons or direct remote access to the workstation unless
>it is ABSOLUTELY necessary. Any user claiming to need such
>access should be made to prepare a formal justification for management
>review. All other avenues of satisfying the users needs should be
>exhausted before granting this request. Any accounts having remote access
>should be rigorously monitored.
Such a labor-intensive process will almost certainly be more expensive
than an automated system than enforces the use of passwords that are
strong enough to withstand a cracking attempt.
>In conjunction with a reasonable password rule, the above steps will make it
>all but impossible for a remote user to gain access by guessing passwords.
Those steps will certainly help if your only threat is from remote
attacks, but they do nothing to protect against inside attacks, which
can be discounted at only the smallest of sites.
For anyone still reading, I recommend the "Department of Defense
Password Management Guideline" (the "green book") (claimer: I wrote
it) for a detailed mathematical analysis of password strength.
Unfortunately, all of the various online forms of this document at
http://www.radium.ncsc.mil/tpep/library/rainbow/index.html do a poor
job of representing some of the formulae. For serious study of it I
recommend looking for a printed copy in a library.
:: Jeff Makey
je...@sdsc.edu
Department of Tautological Pleonasms and Superfluous Redundancies Department
Lohkee
"Jeff Makey" <je...@sdsc.edu> wrote in message
news:9kafea$gpj$1...@news1.ucsd.edu...
> Before getting into specific rebuttals it is worth noting that
> Lohkee's exposition on password strength completely fails to take into
> account the lifetime of a password (i.e., the interval between
> changes). Any such treatise that ignores this critical element should
> be viewed with extreme skepticism.
Not ignored. Not relevant (unless you have a two day pw expiration)
>
> In article <fL587.8557$LP2.8...@bgtnsc06-news.ops.worldnet.att.net>,
> Lohkee <Loh...@worldnet.att.net> wrote:
> >Passwords are generally considered to be reasonably "strong" if they are
six
> >or more characters in length and contain at least one character from each
of
> >the following four sets: uppercase alpha, lowercase alpha, numeric, and
> >punctuation or other special characters.
>
> The apparent basis for this unsubstantiated claim is Microsoft's
> "Implementing Guidelines for Strong Passwords" at
> http://www.microsoft.com/ntserver/techresources/security/password.asp .
> Your first error is your claim that the Microsoft guideline is
> "generally" accepted, which simply has no basis in fact. Your second
> error is that you misrepresent their standard, which requires the use
> of only 3 of the 4 character classes rather than the use of all 4 as
> in your strawman argument.
Nice try. I made no such claim at all. I DARE you to show me where I did!
In fact, I DARE you to show me where I, by any stretch of the imagination,
even alluded to this. Talk about strawmnan arguments!
>
> >With the rule, the user's password must be a minimum of six characters in
> >length and include at least one character from each of the four sets.
The
> >number of passwords possible is now only (952 x 262 x 10 x 33) or
> >2,013,297,000
>
> As Gorazd Bozic pointed out in <3B618D34...@arnes.si>, you
> undercounted by a factor of 24. Combinatorial math is hard when
> you're out of practice. I recommend consulting an expert.
Gorzard and I have yet to conclude who is right, however, even at 24%,
Everything I said still holds true and the point remains the same with very
slight changes in the time estimates.
>
> >We can prove mathematically that the fundamental strength of a password
is
> >derived from the statistical improbability of being able to associate the
> >correct password for a given account when there are an enormous number of
> >possibilities and all are equally probable.
>
> Given your demonstrated lack of skill in combinatorial math I doubt
> you could derive such a mathematical proof. However, even if you
> copied someone else's proof it would still be irrelevant in the real
> world, because all passwords are not equally probable. We know this
> because of the amazing success of dictionary-based attacks on
> passwords. Passwords based on dictionary words have a much higher
> probability of being used than randomly chosen passwords.
>
Do you have to try to be an asshole, or were you simply born (hatched) that
way?
The "fact" you claim (without citations) is irrelevant to the point, which
was,
a. Defenses should take into account all scenarios, not just one.
b. Defending against only one type of attack may inadvertantly leave you at
greater risk for another.
> >We could further strengthen this rule (without appreciably affecting the
> >overall number of possibilities) by filtering out some of the more
"obvious"
> >passwords such as Password, PASSWORD, password, any password that is
simply
> >a string of the same character repeated, User ID, machine name, company
> >name, the user's real first and last name, and words generally associated
> >with system accounts such as CISCO, router, etc.
>
> Ah. You're talking about what Alec Muffett implemented in his
> "cracklib" library 7 years ago. Clueful system administrators have
> long been using such a tool to help keep people from choosing
> passwords that can be quickly guessed by dictionary-based cracking
> tools. These same admins also occasionally *use* those cracking tools
> to test the effectiveness of the password filter.
There is a big difference between checking for a few "obvious" passwords
(which is unnecessary if the filter is properly designed) and throwing a
large dictionary against the PW file. Sorry you can not see the difference.
>
> >It is a given that any password up to eight characters in length is
> >easily cracked by even a marginally competent attacker.
>
> No. I would only say it is given that marginally competent crackers
> could brute force all passwords of up to 5 (five) characters, as it
> takes about a week for a 933 MHz Pentium III to exhaustively test such
> short UNIX passwords. Cracking 6-character passwords is more than 100
> times harder; a skillful (or wealthy) cracker is required to do this
> in a useful time. The resources required to crack any 8-character
> UNIX password in a reasonable time (say, less than a month) are
> greater than those available even here at SDSC, where we have the 13th
> most powerful computer in the world according to the list at
> http://www.top500.org/list/2001/06/ .
>
Why is it that everyone is stuck on using a signle computer? The Net offers
MUCH more computational power! A rate of 600 TRILLION keys/day has already
been accomplished using the *****SPARE***** CPU cycles of the participating
clients.
> >In a year or so, the same will also be true for ten character passwords.
>
> Only in our dreams (or nightmares, as the case may be). I predict
> that the computing power available to crack passwords will increase by
> a factor of much less than 16,000 in the next year (or so).
Good luck!
>
> >There are a number of other things we can do to further enhance our
defense
> >against an individual gaining access by cracking passwords:
> >
> >1. Set the number of attempts at entering a password to two, or at most,
> >three.
>
> And then what? Lock the account? *Very* few sites are willing to
> tolerate the denial of service that can easily result from such a
> policy. Most sites find it much more practical to have a system that
> is resistant even to sustained high-speed cracking attempts.
A high speed attack will eventually lock the account anyway, unless you have
no lockout at all. No lockout gives the attacker unlimted tries. And this
is a good idea??????
>
> >2. Set the days and hours that a user is allowed to access the system.
>
> Another opportunity for denial of service.
You lost me here. The system does not lock the account, it simply refuses
the logon.
>
> >3. Specify the terminal/s that a given user is allowed to logon to.
>
> Yet another opportunity for denial of service.
See preceeding comment.
>
> >4. Prohibit remote logons or direct remote access to the workstation
unless
> >it is ABSOLUTELY necessary. Any user claiming to need such
> >access should be made to prepare a formal justification for management
> >review. All other avenues of satisfying the users needs should be
> >exhausted before granting this request. Any accounts having remote
access
> >should be rigorously monitored.
>
> Such a labor-intensive process will almost certainly be more expensive
> than an automated system than enforces the use of passwords that are
> strong enough to withstand a cracking attempt.
Where is the labor intensity????? I have over 5,000 users on my system and
it is no problem for a single SA to handle.
>
> >In conjunction with a reasonable password rule, the above steps will make
it
> >all but impossible for a remote user to gain access by guessing
passwords.
>
> Those steps will certainly help if your only threat is from remote
> attacks, but they do nothing to protect against inside attacks, which
> can be discounted at only the smallest of sites.
Maybe not on your planet! On mine, the insider would need physical access to
the workstation, which means access to . . . .
Never mind!
>
>
> For anyone still reading, I recommend the "Department of Defense
> Password Management Guideline" (the "green book") (claimer: I wrote
> it) for a detailed mathematical analysis of password strength.
> Unfortunately, all of the various online forms of this document at
> http://www.radium.ncsc.mil/tpep/library/rainbow/index.html do a poor
> job of representing some of the formulae. For serious study of it I
> recommend looking for a printed copy in a library.
>
>
And now we know why the military is consistently unable to keep school kids
out of their systems!
Bill Unruh
>A high speed attack will eventually lock the account anyway, unless you have
>no lockout at all. No lockout gives the attacker unlimted tries. And this
>is a good idea??????
Just put in a 1 second time or even an increasing time for each try (1
sec first try, 2 second, 3 third, etc).
Lohkee
"Bill Unruh" <un...@physics.ubc.ca> wrote in message
news:9kar62$kas$1...@nntp.itservices.ubc.ca...
Not a bad idea, but it would still (after several tries) have the same DOS
effect.
Barry Margolin
The typical way this is done is to only increase within one connection
session, and to limit the number of login attempts in a connection. So the
legitimate user doesn't see the delays when he tries to login.
However, the attacker could deal with this by opening multiple concurrent
connections.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Jeff Makey
Lohkee <Loh...@worldnet.att.net> wrote:
>"Jeff Makey" <je...@sdsc.edu> wrote in message
>news:9kafea$gpj$1...@news1.ucsd.edu...
>> Before getting into specific rebuttals it is worth noting that
>> Lohkee's exposition on password strength completely fails to take into
>> account the lifetime of a password (i.e., the interval between
>> changes). Any such treatise that ignores this critical element should
>> be viewed with extreme skepticism.
>
>Not ignored. Not relevant (unless you have a two day pw expiration)
Yes, ignored. Feel free to prove me wrong by quoting the portion of
your original posting where you discussed password lifetime.
Yes, relevant. Any password than can be easily guessed during its
lifetime deserves to be called "weak." For example, consider a policy
that allows 10-character passwords that must be changed every 2 years.
Although such passwords cannot be easily guessed today, you claim that
"in a year or so" they will be "easily cracked by even a marginally
competent attacker." If true, then these 10-character passwords are
in fact dangerously weak because they could be easily cracked before
they must be changed. That is the sort of consideration that makes
password lifetime an essential element of a general discussion of
password strength.
>Defenses should take into account all scenarios, not just one.
Yet your advice is completely useless in the common scenario in which
authorized users need unrestricted remote access to their computers.
>Why is it that everyone is stuck on using a signle computer? The Net offers
>MUCH more computational power! A rate of 600 TRILLION keys/day has already
>been accomplished using the *****SPARE***** CPU cycles of the participating
>clients.
Those "spare" cycles were willingly donated to a specific academic
exercise of finding one DES key. They are generally not available to
people who want to crack passwords for nefarious purposes. I have
done distributed password cracking for years, and it is much harder to
actually do it than to say it can be done in a news article.
>I have over 5,000 users on my system and
>it is no problem for a single SA to handle.
This claim is completely unverifiable by the readers of this newsgroup.
As long as you choose to post under a pseudonym, any claims based
solely upon your personal real-life situation are worthless here.
Lohkee
> In article <SS3a7.29697$gj1.2...@bgtnsc05-news.ops.worldnet.att.net>,
> Lohkee <Loh...@worldnet.att.net> wrote:
> >"Jeff Makey" <je...@sdsc.edu> wrote in message
> >news:9kafea$gpj$1...@news1.ucsd.edu...
> >> Before getting into specific rebuttals it is worth noting that
> >> Lohkee's exposition on password strength completely fails to take into
> >> account the lifetime of a password (i.e., the interval between
> >> changes). Any such treatise that ignores this critical element should
> >> be viewed with extreme skepticism.
> >
> >Not ignored. Not relevant (unless you have a two day pw expiration)
>
> Yes, ignored. Feel free to prove me wrong by quoting the portion of
> your original posting where you discussed password lifetime.
>
Have it your way. I meant exactly what I said.
> Yes, relevant. Any password than can be easily guessed during its
> lifetime deserves to be called "weak." For example, consider a policy
> that allows 10-character passwords that must be changed every 2 years.
> Although such passwords cannot be easily guessed today, you claim that
> "in a year or so" they will be "easily cracked by even a marginally
> competent attacker." If true, then these 10-character passwords are
> in fact dangerously weak because they could be easily cracked before
> they must be changed. That is the sort of consideration that makes
> password lifetime an essential element of a general discussion of
> password strength.
I disagree. If the system is set up in such a way that the attacker only
has two attempts, the problem then becomes which two out of the massivre
pool should be tried. The term "easily guessed" really means nothing.
Password age is of little use. If, for example, I have the password file
then I have an enormous advantage even if the accounts are expired before I
get the passwords. Now old passwords have meaning in CONTEXT to a particular
user which changes the landscape entirely.
>
> >Defenses should take into account all scenarios, not just one.
>
> Yet your advice is completely useless in the common scenario in which
> authorized users need unrestricted remote access to their computers.
>
Then why bother with security at all? What I suggested is that a user have
a very limited number of attempts to get the password right. I also
suggested that remote access should not be granted unless there is a
documented, reviewed, and approved, business need (that cannot be met by any
other means). I happen to think this is very good advice. There are too
many cowboys that feel they should have whatever they want without answering
to anyone. Many of these people don;t need what they think they do when
management forces them to justify it formally. Also, there are ways to
further reduce the risk, such as encrypted modms, that have nothing at all
to do with passwords but can be used to further lower the risk.
> >Why is it that everyone is stuck on using a signle computer? The Net
offers
> >MUCH more computational power! A rate of 600 TRILLION keys/day has
already
> >been accomplished using the *****SPARE***** CPU cycles of the
participating
> >clients.
>
> Those "spare" cycles were willingly donated to a specific academic
> exercise of finding one DES key. They are generally not available to
> people who want to crack passwords for nefarious purposes. I have
> done distributed password cracking for years, and it is much harder to
> actually do it than to say it can be done in a news article.
I thought it was trivial. Perhaps we use different programmng languages? I
agree that the CPU time was donated, however, all one has to do is look at
virus technology to understand the ramifications. For that matter, how many
creeps out there would be more than happy to donate their time to create a
shared database of passwords? Let's not forget about social engineering.
If the problem were presented correctly, how many people would be happy to
help out. How about a small reward for the user whose system wins, as it
were? Keep in mind that hackers, unlike security people, have been sharing
resources for years.
>
> >I have over 5,000 users on my system and
> >it is no problem for a single SA to handle.
>
> This claim is completely unverifiable by the readers of this newsgroup.
> As long as you choose to post under a pseudonym, any claims based
> solely upon your personal real-life situation are worthless here.
>
DAMN! It has nothing at all to do with passwords, unlike your absurd claim
that I used Microsoft as my model, but ya finally got me! Anyone who
administers a large network could verify that my numbers are very
reasonable.
Jeff Makey
Lohkee <Loh...@worldnet.att.net> wrote:
>Password age is of little use. If, for example, I have the password file
>then I have an enormous advantage even if the accounts are expired before I
>get the passwords. Now old passwords have meaning in CONTEXT to a particular
>user which changes the landscape entirely.
If you have a list of expired passwords then almost certainly one of
them will provide a helpful clue to a current password, but that is an
extremely improbable scenario. It could be made even more improbable
by a clever filter that requires new passwords to be substantially
different from the old ones.
Password age is an essential part of this fundamental equation of
password strength, taken from Appendix C of the DoD Password
Management Guideline I referenced in an earlier post:
P = L*R/S
where P is the probability that a password can be guessed within its
lifetime, assuming continuous guesses for this period; L is the
maximum lifetime that a password can be used to log into the system;
R is the number of guesses per unit of time that it is possible to
make; and S is the password space, i.e., the total number of unique
passwords.
The lower the probability of being guessed, the stronger we say a
password is. Each site must establish, as part of its security
policy, an acceptable probability of a password being guessed, and
then adjust the lifetime, password space, and the guess rate to
achieve that goal. In practice nobody does all of this, but it *is*
the correct scientific approach. Anything else, especially an
analysis that ignores password lifetime, is guesswork and snake oil.
>What I suggested is that a user have
>a very limited number of attempts to get the password right. I also
>suggested that remote access should not be granted unless there is a
>documented, reviewed, and approved, business need (that cannot be met by any
>other means). I happen to think this is very good advice. There are too
>many cowboys that feel they should have whatever they want without answering
>to anyone. Many of these people don;t need what they think they do when
>management forces them to justify it formally.
As you said in <OaG87.10379$LP2.1...@bgtnsc06-news.ops.worldnet.att.net>,
"such a myopic view of the world." You may have the luxury of working
in an environment where micromanagement is effective, but your advice
is useless to the rest of us. For instance, an ISP with thousands of
customers who access their e-mail via POP (which uses passwords) could
never afford to implement your suggestions. Customers would flee from
the inconvenience of having to reset their accounts every time some
hacker (possibly employed by one of the ISP's competitors) would sweep
though, making "a very limited number" plus 1 failed attempts on each
account.
>Keep in mind that hackers, unlike security people, have been sharing
>resources for years.
Hackers are too too competitive amongst each other to successfully
build the kind of huge distributed password cracking system you
envision. The scope of the Code Red worm infection shows the
potential of such an approach, but making it work without getting
caught would be well beyond the skill of most script kiddies.
>Anyone who administers a large network could verify that my numbers
>are very reasonable.
I help administer about 300 UNIX systems with 1700 users here at SDSC,
and I can verify that your numbers are quite *un*reasonable. Such a
large percentage of our users could justify having remote access that
it is much more cost-effective to give it to everyone and use a
password management system that assumes a sustained high-speed guess
rate. We don't let people choose passwords that are based on
dictionary words such as "newcastle" and we do occasionally try to
crack them. It works.
ClubMonkee
confused.
The ASCII table and position of letters within the table - has nothing to do
with issue. In the long run you are only saving a fraction of a second. It
is the number of characters (which can be more or less anything printable)
and the maximum possible combinations that matter the positions will be goto
in a matter of time. Checking each combination of character is what makes
the password strong.... like a combination lock.... or any password for that
matter...
You are thinking about it too logically and not mathematically calculate the
number of possible combinations for a 6 digit password that can only contain
numbers. Then do the same for a 6 digit password containing numbers and
letters, then do the same for a password containing all printable
characters... then you will see what I mean.
You will also see the purpose of dictionary attacks.
"Lohkee" <Loh...@worldnet.att.net> wrote in message
news:mf0a7.24008$LP2.1...@bgtnsc06-news.ops.worldnet.att.net...
ClubMonkee
you are right and lonkee is deeply wrong and confused about this issue.
I just wanted to say that your posts are very informative, reasonable and
scientific.
I can't but think that Lohkee is only pursuing his original points out of
pride or he is deliberately annoying people for fun.
The more I read this post the more I think why am I bothering - because he
doesn't even try the most simple of experiments, mathematical or otherwise.
;)
"Jeff Makey" <je...@sdsc.edu> wrote in message
news:9kt6vs$71u$1...@news1.ucsd.edu...
Lohkee
> In article <kCoa7.31115$gj1.2...@bgtnsc05-news.ops.worldnet.att.net>,
> Lohkee <Loh...@worldnet.att.net> wrote:
> >Password age is of little use. If, for example, I have the password file
> >then I have an enormous advantage even if the accounts are expired before
I
> >get the passwords. Now old passwords have meaning in CONTEXT to a
particular
> >user which changes the landscape entirely.
>
> If you have a list of expired passwords then almost certainly one of
> them will provide a helpful clue to a current password, but that is an
> extremely improbable scenario.
Depends on who the attacker is. Getting the password file *can* be very
easy for an insider. If we accept the common idea that over 90% of attacks
come from the inside, then this may not be as improbable as you suggest.
> It could be made even more improbable by a clever filter that requires new
passwords to be substantially
> different from the old ones.
Not a bad idea.
> Password age is an essential part of this fundamental equation of
> password strength, taken from Appendix C of the DoD Password
> Management Guideline I referenced in an earlier post:
>
> P = L*R/S
>
> where P is the probability that a password can be guessed within its
> lifetime, assuming continuous guesses for this period; L is the
> maximum lifetime that a password can be used to log into the system;
> R is the number of guesses per unit of time that it is possible to
> make; and S is the password space, i.e., the total number of unique
> passwords.
>
> The lower the probability of being guessed, the stronger we say a
> password is.
Since we both agree to this idea then we must also agree that any rule which
significantly reduces the password space will increase that probability (all
other being equal).
I was refering to "core" business systems (and I should have stated this).
Publiicly accessable systems should not, as a general rule, be connected to
core business systems.
>
> >Keep in mind that hackers, unlike security people, have been sharing
> >resources for years.
>
> Hackers are too too competitive amongst each other to successfully
> build the kind of huge distributed password cracking system you
> envision. The scope of the Code Red worm infection shows the
> potential of such an approach, but making it work without getting
> caught would be well beyond the skill of most script kiddies.
>
> >Anyone who administers a large network could verify that my numbers
> >are very reasonable.
>
> I help administer about 300 UNIX systems with 1700 users here at SDSC,
> and I can verify that your numbers are quite *un*reasonable.
Maybe you have lazy administrators. We have 5 admins administering 27 (or
so) unique systems with an average of 5,000 users on each. Works for us
just fine.
> Such a large percentage of our users could justify having remote access
that
> it is much more cost-effective to give it to everyone and use a
> password management system that assumes a sustained high-speed guess
> rate.
Would this be true of core business systems?
> We don't let people choose passwords that are based on
> dictionary words such as "newcastle" and we do occasionally try to
> crack them. It works.
>
If a password enforcement rule is deemed adequate, and a user chooses a
password that meets said rule, it is a bizarre contradiction to then "cite"
the user for "breaking" the rule!
Jeff Makey
Lohkee <Loh...@worldnet.att.net> wrote:
>"Jeff Makey" <je...@sdsc.edu> wrote in message
>news:9kt6vs$71u$1...@news1.ucsd.edu...
>> them will provide a helpful clue to a current password, but that is an
>> extremely improbable scenario.
>
>Depends on who the attacker is. Getting the password file *can* be very
>easy for an insider. If we accept the common idea that over 90% of attacks
>come from the inside, then this may not be as improbable as you suggest.
Lots of things can be very easy for insiders, which is why they are
involved in a high percentage (I suspect the 90% figure is poorly
supported) of successful intrusions. For systems connected to the
Internet most attacks are made by outsiders and are unsuccessful.
I still think it is extremely improbable that an insider would have
access to expired passwords but not current passwords. Your site
could be the exception, I suppose.
>> The lower the probability of being guessed, the stronger we say a
>> password is.
>
>Since we both agree to this idea then we must also agree that any rule which
>significantly reduces the password space will increase that probability (all
>other being equal).
I agree. However, all other is very rarely equal, which is why the
maximum guess rate and password lifetime must be explicitly considered
when evaluating whether a password management system provides adequate
protection in a specific operational environment.
>I was refering to "core" business systems (and I should have stated this).
>Publiicly accessable systems should not, as a general rule, be connected to
>core business systems.
Yes, you should have said so earlier. If a site's security policy
identifies certain systems that should not risk being connected to the
Internet, then the cost of other access restrictions (e.g., no logins
during off hours) could very likely be justified.
>> Such a large percentage of our users could justify having remote access that
>> it is much more cost-effective to give it to everyone and use a
>> password management system that assumes a sustained high-speed guess
>> rate.
>
>Would this be true of core business systems?
If the core business systems are the same architecture as the non-core
systems that can withstand a sustained high-speed guess rate, then the
administrators may find it less confusing to use the same password
filter everywhere and then lock down the core systems even further by
limiting failed login attempts, etc. In a heterogeneous environment
it may not be worth the effort to make things work the same everywhere.
>If a password enforcement rule is deemed adequate, and a user chooses a
>password that meets said rule, it is a bizarre contradiction to then "cite"
>the user for "breaking" the rule!
We certainly wouldn't "cite" a user for having a password that we
could guess. We would just ask them to change it and we would
probably update the password filter to keep up with the cracking tool.