Security and Directory Services for UNIX Guide Released

re: Security and Directory Services for UNIX Guide Released

zKVOgPSM — Tue, 15 Sep 2009 12:02:36 GMT

doors.txt;10;15

nessiness.com » [Slashdot] Stories for 2006-08-12

nessiness.com » [Slashdot] Stories for 2006-08-12 — Sat, 26 Aug 2006 06:08:49 GMT

PingBack from http://nessiness.com/index.php/?p=121

re: Security and Directory Services for UNIX Guide Released

fluke — Wed, 19 Jul 2006 23:23:04 GMT

I was talking to a friend about the same exact issue about having administrative access means giving up the barn. In the discussion it was in regards to how well signed drivers in Linux 2.6 and Vista will actually improve security. My friend made an interesting point that it is not ment to be perfect security but rather a discouragement system. Some Debian developers choose passwords which where not a sufficent discouragement system. And it is my opinion that unsalted MD4 hashes is not a sufficent discouragement system. Not all leaks of the authentication hashes indicates the ability to run arbitary code. Organizations misplace unencrypted back-up tapes. Companies resell refurbished hard drives without erasing them. Mike Howard gave a good talk on how Microsoft is discouraging known attack vectors using different methods. It seems clear to me how successful rainbow table based brute force cracking will be over the 10 year life cycle of Longhorn Server. So why not also apply the known methods to discourage that attack vector too? As a work-around I can use PAM plugins that use strong hash algorthms with long salt values. But this work-around also involves loosing the advantages of leveraging MAD as the central password store the entire enterprise. I would just like to know if there is a point on the road-map to get the best of both worlds.

If you can't trust your admins, you're already doomed

jdzions — Tue, 18 Jul 2006 23:47:25 GMT

No security system can stand up to admins who are compromised. This is a basic tenet of security. Not AD, not Kerberos, not iPlanet on Solaris, not /etc/shadow on Linux.

If the admin can read the hashes, the admin can insert software into the stack which captures cleartext passwords before hashing. Superuser means *anything* can be done. And usually it can be done more quickly than L0phtcrack can crack hashes (especially if password policies really are good enough to keep people from using trivial passwords).

The current story unfolding about the most recent security troubles at Debian bear this out. A single account was compromised, thus allowing a non-trusted person to have root privs (after exploiting some unpatched bugs). Additionaly account passwords may have been cracked; the Debian admins ran a password cracker on their account data and disabled a bunch of accounts which had trivial passwords. See http://news.com.com/Debian+locks+out+developers+after+server+hack/2100-7349_3-6094335.html for details.

re: Security and Directory Services for UNIX Guide Released

fluke — Thu, 06 Jul 2006 17:52:20 GMT

The Washington Post has an article named "Computer consultant hacked into FBI's classified system" by Eric M. Weiss. A copy can currently (July 6th, 2006) be found at:
http://seattletimes.nwsource.com/html/nationworld/2003107651_fbi06.html

This article discusses the case of BAE Systems' employee Joseph Thomas Colon and his "break-in" with FBI computers.

Key quotes from the article:

- "the bureau said it was forced to temporarily shut down its network and commit thousands of man-hours and millions of dollars to ensure no sensitive information was lost or misused."

- "Colon used a program downloaded from the Internet to extract 'hashes' — user names, encrypted passwords and other information — from the FBI's database."

I don't mean this as an attack on Microsoft or Centrify. Neither company is even named in the article at all. My point is that the strength of the password hashes does matter to the security of the enviroment. While a single point of administration for both Windows and *nix is something I am interested in, loosing the flexiablity to decide the strength of the locks to the kingdom is not something I would be willing to trade-in.

re: Security and Directory Services for UNIX Guide Released

fluke — Sat, 01 Jul 2006 01:33:53 GMT

Is there a reason you choose a version of RedHat that already reached End of Life on April 30, 2004? The documenation makes reference to the Fedora Legacy Project which suggests the author was aware that the version being discussed was already beyond EoL.

Isn't it a little silly to beat your drum on what security issues that RH does not plan to fix in an EoL product. It is not like MS06-015 for Windows 98/ME where the vendor decided to just not address security holes even before EoL was reached. You might want to give RH a break on this one?

And what do you mean the native OS can not do LDAP over TLS/SSL??

Did you not notice the documentation on using authconfig with the TLS checkbox at (you know... RTFM):
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-authconfig.html

Maybe you should have noticed the OpenLDAP SSL mechanism/options section of the default /etc/ldap.conf from the nss_ldap package?

Or you could have taken into account that the RH9 native OS also has the stunnel package. *sigh* I really do understand. Rover must have eaten your homework. Damn that search assistant and all the trouble he causes.

And then there is the big issue on how well the security of such a configuration would hold up to a disgruntled employee that had priviledged access to the AD server.

From http://www.windowsitlibrary.com/Content/617/06/2.html:
"For obvious security reasons the AD never stores the plain password but a hashed version. The hash algorithm used for password hashing is MD4."

Further information available on the Internet shows that the password hash is stored without using any "salt" (a method accepted by the security community to further increase the work involved in guessing the password).

Given the on-going information on Rainbow Table cracking which is known to be highly effective at cracking unsalted MD4 hashes, wouldn't following the documents given above potentally increase the security risk to the organization?

Where is there information on modifying the LASS to use an alernative digest algorthm/method? Can I get a little salt with my hash?

Overall, the documenation was interesting. I like the break-down into different end stages. But without more flexiblity to address weaknesses in the LASS which both parts of AD (Kerberos and LDAP) end up leveraging.

Anyways. Thanks. It was a good try. The effort really did show through. I give you a extra shinny star * and smily face :)