Re: Password strength on UNIX

[Jon Kibler <Jon.Kibler () aset com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

lgpmsec wrote:
> Hi list,
>
> Is there a means to audit/check the strength of passwords on UNIX machines
> with a native unix utility? If not, would you recommend utilities such as
> john the ripper or crack? Finally, in this case, any special considerations
> I should be aware of (account lockouts, system performance...)?
>
> Thank you
>
> -<M


*WHICH* Unix? That makes a BIG difference. Unix vendor and version will
determine the default means by how passwords are hashed. How passwords
are hashed will greatly impact how rapidly they can be brute forced.

If you are using crypt-style passwords (13 char salt+hash values), then
they are all worthless. Any crypt-style password can be brute forced
with a cheap crypto accelerator card in less than a day. Using a weak
password (dictionary word, short length, low complexity, etc.) only
makes the process faster.

The only hard to brute force Unix passwords (that I am aware of) are the
MD5 ($1$SALT$HASH) or Blow Fish ($2$SALT$HASH) passwords. That said, you
still have to use good passwords (>10 chars, at least 2 digits, 2 lc, 2
uc, and 2 symbol) that are not based on any word (even if it comes from
a Vulcan dictionary).

In reality, passwords have become next to useless. They are like cheap
locks -- they keep honest people honest. They do nothing to stop the
determined -- or big brother. What you really need is two factor
authentication -- with my preference being smart cards.

Even bigger issue:
   Do you know where are all of your passwords?
   How often do you change all passwords?
   What about "unchangeable" passwords in COTS applications?

For example, if you have PL/SQL applications, it will have hard coded
into the application the database view name and password. To change the
password, you have to recompile the program. To recover the password,
just use the 'strings' program on the binary file. Thus, probably anyone
who can run the app can then recover the password and manipulate the
database in ways never intended. (Now, if all apps had the proper
minimum permissions -- which I almost never see -- then the strings
command could not read the file, which would semi-fix the problem with
non-privileged users!)

Another issue: Look at passwords cracking from a statistical standpoint.
If you have the password hashes from an organization, the greater the
number of hashes you have, the greater the chance of being able to brute
force at least one password in a given period of time. Something most
organizations fail to consider is that the greater the number of users
that they have in a given authentication database, the shorter must be
the minimum allowable lifetime of a password.

Passwords are, for now at least, a necessary evil. But, we desperately
need to find something better and move away from passwords as fast as we
can.

My $0.02 worth.

Jon K
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC  USA
o: 843-849-8214
c: 843-224-2494
s: 843-564-4224
http://www.linkedin.com/in/jonrkibler

My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklcQQAACgkQUVxQRc85QlN3iwCglumBktnAKaBnkNfwIFMZvHeB
p9sAoKBKyAGNUHNRPbpYoUxpHcx070ks
=2f8X
-----END PGP SIGNATURE-----