Password security - Another idea

[Dennis L. Mumaugh]

In article <1687 at unisoft.UUCP> greywolf at unisoft.UUCP (The Grey Wolf) writes:
>Small point here:  Getty doesn't even look at the password.  Login is
>the one that takes it.

True, but getty looks at the logname:  if it is all UPPER CASE it
sets tty modes to map upper case to lower.  Then login will only
see lower case input [unless one uses escapes].  Hence for true
concern one can't allow upper case characters when older/obselete
terminals [e.g.  TTY33 or IBM3270] are used.

>
>I am also a bit shaky on how you mean "pass phrases" -- does this entail
>enforcing very long strings or what?

Perhaps.  My work with that had a requirement that the password
be a MINIMUM of 8 characters and a MAXIMUM of 64, blanks and
control characters [and case] significant.

>
>Another idea:  Why do we not advance our technology to make use of
>larger password salt/key strings (instead of using 8 chars and returning
>13, why not try for 16 chars and return 26)?  
>
We should but the details of implementation are a bit tricky and it
isn't a glamorous project so some developers haven't proposed it.
The encryption really ought to use Cipher Block Chaining, or
encryption of each 64 byte chunk independently.  The strength of
the technique must be analyzed cryptologically and shown to be
properly secure.  As a developer, do that and sign your name.
Hope that you are right.  Perhaps a half dozen people in
comp.unix.wizards could feel safe in their implementation
[outside of current NSA employees].

>I think that people are reluctant to explore the above possibility because
>they are (mentally) comfortable to remain where they are.  So long as this
>condition exists, passwords will be restricted in usable length (I have
>often wished for passwords on the order of 12+ characters, but gave up
>on them since only the first 8 were used), and we will have this problem.
>
See above. It's easy in theory to solve a security problem.  But
do the implementation and then explain to your senior
vice-president or general counsel why you think that it will
GUARENTEE solving the problem.  Despite all security discussion
and theory and provable systems, etc. it all comes down to what I
call the "comfort factor".  Just how comfortable the boss is in
signing the paper work.

When I was the one that originated the DoD rules on
declassification of magnetic tapes and memories [extended to
disks now] the document said do this and that and then the tape
is declassified.  I said "Then that means I can deliver it to
the Russian Embassy without worry." The answer was "Well, it
isn't really *that* unclassified." I.e. the comfort factor wasn't
too high on the decision.

>(I am probably missing something here, but that's okay; this news group
>is better than any C compiler I have ever seen -- not only will it tell
>me I made an error, but it will point out the error and ram it down my
>throat! :-)
>
Not much.  Anything to do with security is reminiscent of the
Dutch boy and the dike philosophy, patching up known holes and
anxiously looking for new ones.  The NSA people have said for
years that this is a bad way of doing things.  Design and prove a
secure system, implement it and prove the implementation is
mathematically correct.  It might be possible, but then convince
the boss that it is so correct that he can put his job on the
line.  Ne c'est paix?
-- 
=Dennis L. Mumaugh
 Lisle, IL       ...!{att,lll-crg}!cuuxb!dlm  OR cuuxb!dlm at arpa.att.com