Password security - Another idea

[Barry Shein]

Doug Gwyn responding to my note
>>Can we assume that before we make exotic changes like shadow passwords
>>we can make simple changes (some Unix's already have these) to the
>>passwd changing programs like: ...
>
>NO!

please dont shout, i have a headache.

>  The "easy-to-guess password" checks are not sufficient, and
>the accompanying restrictions are a royal pain in the user's ass.
>It has been argued that they result in REDUCED security!

I suppose one can say I'm being hoisted on my own petard. Because
they're not sufficient they're useless? They're only a regal malady if
you sit there trying to type in pw's it won't accept (that is, you
don't know what a good approximation of a reasonable password is and
you decide to type in /usr/dict/words as it rejects anything in
/usr/dict words), no? This is what I meant by user education, how to
choose a password that's both secure and acceptable to the software,
both, not only the first.

The reduced security argument I assume you are referring to generally
is the claim that if you force people to use hard to remember
passwords they will write them down etc. No one is advocating hard to
remember passwords, just not pw's in the dictionary and a few other
easy guesses (like your login name), monocase, stuff like that. That's
not that monarchically grimacious, is it, really? Doesn't SYSV enforce
this sort of thing right now out of the can? Or at least mixed case
and/or punct/digits.

If that's not what you meant then I need a phrase worth of recap.

>Exposing the encrypted password for anyone to see is FOLLY; it was
>barely excusable in the first place and is inexcusable now.  The
>shadow password file (which is NOT "exotic"; in fact JHU/BRL PDP-11
>UNIX had something of the sort many years ago) has already been
>implemented; so long as UNIX sticks to the general modified DES
>encryption scheme, hiding the encrypted passwords is a necessary
>security measure.

Ok, fine, it's folly. When the ftpd bug was discovered a few weeks ago
and the possibility existed that all of BRL's pw files, protected or
not, were read, what was done? The shadow pw file offered no
protection against this and being as you seem to believe in allowing
users to choose easy passwords and just hide the encryptions you had
to acknowledge a major security breach, no? Any time you have discover
a hole (even a badly installed piece of software, like vendor stuff
which installs itself setuid dangerously) that's been around for more
than (I dunno, an hour?) you have to assume someone walked off with
your shadow password file, no? It's such an easy and obvious target.

See, I can *almost* buy the argument that given a set of security
measures they can be treated as the product of the probabilities of
each being broken IFF they are truly independent. Once one relies on
the other then that reasoning collapses and you tend towards a weakest
link probability.

I will point out that I consider the possibility of moving from the
current general modified DES an intriguing area. Making it much more
expensive to spin passwords (esp given the higher average MIPS today),
reliably, should be more secure than relying on read permissions in
the file system, and more transparent also (and heck, maybe it can
even be exported...)

	-Barry Shein, ||Encore||