NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/bit/listserv/ibmmain/2836

Text File | 1992-12-11 | 7.5 KB | 150 lines

Newsgroups: bit.listserv.ibm-main
Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!stortek!LSTC2VM.stortek.com!MCMASTER
From: [e-mail] (Jim McMaster)
Subject: Re: Password (was mvs tcp/ip) security
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: lstc2vm.stortek.com
Organization: StorageTek SW Engineering
References:  <[e-mail]>
Date: Fri, 11 Dec 1992 19:11:35 GMT
Lines: 137

In article <[e-mail]>
"Mark C. Lawrence" <[e-mail]> writes:

>REPLY TO 12/10/92 05:09 FROM [e-mail] "IBM Mainframe Discussion
>list": Re: telnet mvs tcp/ip security
>
>On  Wed, 9 Dec 1992, Jim McMaster <[e-mail]> writes,
>>In article <"92-12-08-14:42:49.00*X22"@MVS.URZ.UNI-HEIDELBERG.DE>
>>[e-mail] writes:
>>
>>>[description of MVS TCP/IP security hole deleted]
>>>My question: Is there a real danger that somebody writes a
>>>program (in MVS, VM, AIX, UNIX, OS/2, MS-DOS, ...) which
>>>generates passwords and feeds them into the TELNET dialog?
>>
>>This is a very small exposure compared to the inherent insecurity of
>>passwords.  Certainly a program can generate all possible passwords
>>quickly, but how fast will MVS accept them?  Let's assume you have an
>>eight character random password, composed of characters from the set
>                 :::::::::::::::
>>A-Z and 0-9.  This allows 36**8 = 2.8 trillion possible passwords.
>
>Not all of which are equally likely, unless you have a random-string generator
>make them up, in which case you are sure to end up with the problem you refer
>to below...
>
Agreed.  My problem is with the reliance on passwords to provide
security.  Passwords are inherently insecure, and if you attempt to
close one hole, you always open one of the other ones.  I was trying to
say that this particular hole is not as big as you might expect.  Yes,
a CRAY could probably generate all possible passwords in a matter of
hours, but it is impossible to get MVS to accept them that fast.

Worrying about this particular hole is like installing iron bars on
your third floor windows while ignoring the broken lock on the front
door.

>>Assuming TSO/TELNET has a consistent one-second response time and stays
>>up 24 hours per day, 365 days per year (HAH!), it would take
>>36**8/60/60/24/365 = 89,456 years to input them all.  You have to enter
>>one-half the possible passwords to have a 50% probability of hitting
>>the correct one, so you really are "safe" only for 44,728 years.
>
>Well, this certainly illustrates why the password shouldn't be any word that's
>in the dictionary, for example.  It would only take a couple of days (at your
>assumed 1/sec rate) to test the whole English dictionary.
>
That is why I don't use English words.  I pick a word, then
deliberately misspell it.  This prevents dictionary-type assaults.

>>If you have a minimum password length of five aharacters, you are down
>>to about one "safe year".  If you require a password change every sixty
>>days, the attacker could enter about 8% of the possible five-character
>>passwords before it changes, assuming miraculous availability and
>>response time.
>
>Yes, but the more often you require passwords be changed, the more likely it
>is that the user will either (1) pick a word from the dictionary or (2) tape
>it to the terminal (remember how the kid got the password to the school
>computer in WarGames?).  You want users to choose a password (yes, choose, not
>have it chosen) that they can easily remember (so they won't tape it to the
>terminal) and that no one else can easily guess.  The set of such words is
>small; requiring frequent changes will result in one of the first two rules
>being violated.  The password should be changed only when one suspects misuse
>of the account, or when an authorized user terminates employment, or one
>otherwise believes security to be compromised.
>
A speaker at a Computer Security Conference a few years ago had code
that generated random pronounceable passwords.  Not words, just
combinations of characters that could be pronounced.  I never got the
code, but the idea was to have a single thing to remember.

He also cited studies that only a very small percentage of people could
remember a random string of eight things (on the order of 5%, I think).
About 97% can remember a random string of five things, with the others
being those who can't remember their own phone numbers.  He advocated a
five-character random password, changed every 60-90 days on the basis of
his research.

A better approach is to use some sort of security system that does not
use passwords at all.  These, however, are expensive, so management
does not want to hear about them.

>There is also no substitute for paying attention.  Someone needs to be
>notified when there are multiple unsuccessful attempts to logon.  My system
>notifies me (when I logon) if there was an unsuccessful attempt; it also tells
>me when the last logoff was, so I would detect a successful logon too.  This
>last check obviously does no good if you leave unused accounts open for long
>periods of time.
>
Agreed again.  As long as you pay attention, you can reduce some of the
risks of passwords.  The original poster asked if the threat of
someone's using a computer in a brute-force assault was real.  My
response was (and is) that it is, but the risk is very small.

>>As I said, it is a risk, but a more likely exposure is the idiot who
>>uses his wife's name or tapes his password to his terminal.
>
>Well, I won't defend the first, but the second is the result of the idiot
>sysadmin who requires that the password be changed every "n" days and/or has a
>random-string generator make them up.  You tell me my password for this week
>is ZQ97PAA9, and you think I'm gonna remember it?  Fat chance.
>
>Maybe instead of doing password expiration, the system should do password
>guessing.  You enter your new password, the system checks its standard list
>(dictionary plus whatever other "easily guessed" words you could define); if
>your choice is in the list, it is rejected.
>
>The problem (as with many "auditing" type problems) is that there is a
>tendency to check what is easy to check, instead of what is important.  It's
>real easy to have the system monitor password ages, generate reports, do nasty
>things to users who fail to change their password every "n" days.  But the
>system can't tell that you wrote the password on the paper taped to your desk,
>or stuck it on the terminal with a Post-It, or stored it in a file on your
>other account, or...?
>
You have hit the nail on the head.  The weaknesses in a password system
are human failings, not technical problems.  Using technical means to
overcome human failings is a losing proposition.  The only reason for
using a password-based security system is that they are cheap and easy
to implement.  They also are inherently insecure.  You get what you are
willing to pay for, and management typically is not interested enough
to pay for very much.

>As to TCP/IP MVS, invalid passwords supplied to it don't trigger "unsuccessful
>logon attempt" messages on my system at least, but they do appear in the job
>log of the TCPIP task.  So it would pay to have someone reviewing that log on
>a regular basis, to detect "brute force" hacking attempts.
>
>Mark C. Lawrence
>Systems Programmer     Internet: [e-mail]
>Stanford Data Center     Bitnet: M.Lawrence@STANFORD
>Stanford, CA 94305-4136     Tel: [phone]
>
>To:  [e-mail]

Jim McMaster