A mildly-edited response question variations upon which I am still asked; quoth the questioner:

I’m getting grief from boss that our application which runs on Solaris7 does not have sufficient logical access controls.

In particular:

1. password aging.
2. locking account after three unsuccessful log-in attempts.
3. lexical complexity (e.g. needs to be 8 chars with 2 numeric etc)

My response:

---

Solaris 7 is an old operating system from the perspective of security – it was released in 1998, for heaven’s sake – and a lot of features have since evolved into the current release, Solaris 10. This is an effect of changing technology, customer demand, and (to be honest) Sun’s corporate culture.

Looking at your points in specific:

* “Password aging” of the “your password expires in two days time” has basically been around since Solaris 2.0 or earlier, it came in with the password-shadowing scheme when Solaris merged with AT&T SystemV. Earlier revs of Solaris had this feature available via an alternative method, so in short: it’s been available since the 1980s. Check the manual pages for “shadow” and “passwd”

* Native “three strikes” password lockout is something that has only recently been added to Solaris 10, and that only in response to customer demand.

This is because modern security geeks (myself included) tend to view “three-strikes” as a horrible, complicated, messy, stupid security risk, irrespective of the number of stuck-in-the-1980s VAX-VMS-based / IBM-mainframe-based customer security operations documents that demand it.

The problems of “three-strikes” in the modern enterprise environment are legion: in modern distributed authentication directories – NIS, LDAP, etc – there is no typically no central authority who is counting the number of failed authentication attempts, generally for technical reasons. For example: LDAP is deeply sub-optimal for poking little bits of data like that back to a central place, for immediate propagation to all replicas. No immediacy == no security.

Even if there were a central authority that brokered this sort of information it would be subject to flooding attacks by miscreants who could tie-up that one service and thereby prevent anyone from authenticating in your enterpise, with significant business impact.

You cannot architect around this risk by including a “timeout” or other “we’ve tried checking whether the user has struck-out but got no reply, so we’ll let him in anyway” mechanism, because that defeats the whole point of the policy.

Anyway – what merits being called “authentication” nowadays? Would you like it if you changed your system password, and then – having walked away for a coffee – your automatic IMAP-enabled mail client goofed-up three authentications and locked you out of your own system because you forgot to update the client?

Typically, the answer to that one is “no”; on the other hand, if your three-strikes system does not cover IMAP, then someone will write an IMAP-based password cracker.

Another implementational issue is that of “locking” – if you implement three-strikes checking because you’re worried about password-guessing attempts, then I’ll write a distributed program that establish several thousand authentication attempts in parallel and simultaneously – so that unless your implementation is very clever / heavily locked / rather fragile and complicated, I will get one single shot at making seven thousand guesses.

That’s generally adequate.

Further, three-strikes leads to weak operational security thinking: when I was a (quite wussy) university hacker back in the 1980s we did make sure only to try two attempts when probing for accounts where the password was the same as the username (eg: user: sysdiag ; password: sysdiag) because less than three failures would not be audited and we’d stay off the sysadmin’s radar.

So: in Solaris 10, Sun finally caved and implemented the functionality for non-root users (else I could try logging in as “root” with the (wrong) password “sesame” three times, and lock you out of your own system) and only for users where non-distributed, “files”-based directory services are being used.

Anything else would just be stupid.

Plus: frankly, it still is a greater business risk than it solves. If a hacker could get ahold of (or just guess) a list of all usernames on all systems in your enterprise, he could just go and poll each system, logging into each user three times with the (wrong) password “sesame”, and lock all of your users out of all your machines.

Verb Sap.

* In Solaris7, the following password construction restrictions are built-in / hardwired to the system:

Extract taken from [docs.sun.com]

Passwords must be constructed to meet the following requirements:

Each password must have PASSLENGTH characters, where PASSLENGTH is defined in /etc/default/passwd and is set to 6. Only the first eight characters are significant.

Each password must contain at least two alphabetic characters and at least one numeric or special character. In this case, “alphabetic” refers to all upper or lower case letters.

Each password must differ from the user’s login name and any reverse or circular shift of that login name. For comparison purposes, an upper case letter and its corresponding lower case letter are equivalent.

New passwords must differ from the old by at least three characters. For comparison purposes, an upper case letter and its corresponding lower case letter are equivalent.

…and the wise system administrator shall no doubt have improved upon these PASSLENGTH (etc) security settings by investigating the possibilities afforded to him in the Solaris Security Hardening Toolkit, available at [www.sun.com]

In Solaris 10 (of course) this has been significantly upgraded with a PAM module that can do comprehensive checking of the plaintext for “I am Paris Hilton and nobody will ever guess my dog’s name” syndrome.