passwds and crypt(3)... (LONG)

[P E Smee]

In article <657 at hepburn.UUCP> joeg at hepburn.UUCP (Joe Gaudreau) writes:
>
>Well, the numbers are still pretty big even for set #4 but are they big
>enough?  Do you have enough protection should someone know that the root
>password is 5 characters long and only made up of letters (a common practice
>as a site I visited).  Fast crypt(3) routines are available.  So THEY changed
>the constant string - it can be found out.  Looks like shadow passwds
>are VERY convincing...

Our experience when our Multics passwords were absconded with is that
about 85% of users' passwords will be either (1) their username; (2)
their real name -- bit harder to mechanically break; or (3) a word of
between 4 and 8 characters which can be found in the system's
spell-checking dictionary.  Ignoring (2) and assuming you are trawling
the passwords, that means that you need NUsers uses of crypt to check
case (1) for all users, and at worst 4096*(wc -w dictionary) for case
(3).  For a dictionary size of about 20000 words, that's a mere
80,000,000 tries -- probably less since you can prbably ignore words
outside the 4-8 char range.  Can also take advantage of knowledge which
will allow you at any point to only worry about seeds which are still
in use for passwords which remain uncracked.

Not intractable, specially if you can involve an integer-capable vector
processor in your work.  (One hopes that people responsible for
privileged accounts are more clever with their passwords.)

Some systems try to impose restrictions on what you can choose as a
password.  Sometimes these actually help break in.  If you impose a
6-char minimum, for example, then the probability is that the passwords
will be words between 6 and 8 chars which are in the spell-checking
dictionary.  You've just cut down the number of cases to check.  If you
require at least one uppercase letter, odds are that the user will
uppercase either the First, or ALL, letters, because that's easier than
shifting in mid-word.  If you require at least one non-alpha, odds are
that the user will take a word meeting the criteria above, and tack a
digit or two on the end.  Again, that's easier to type.  So, a
non-alpha may gain a little, but not as much as you'd expect from a
simple alphabet**length calculation.  (Does, though, decrease the
chance that you can break multiple users by a single encryption.)

Since (we'll assume) any serious privileged user will be cleverer about
picking passwords, this does not particularly help if you want to crack
'root'.  But, if you just want to break any passwords you can, the
problem is not that difficult.

-- 
Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132
 Smee at bristol.ac.uk  :-)  (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)