Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt!ius2.cs.cmu.edu!edw
From: edw@ius2.cs.cmu.edu (Eddie Wyatt)
Newsgroups: misc.headlines,comp.misc
Subject: Re: Hacker Scholarship
Message-ID: <1220@ius2.cs.cmu.edu>
Date: Tue, 30-Jun-87 10:45:55 EDT
Article-I.D.: ius2.1220
Posted: Tue Jun 30 10:45:55 1987
Date-Received: Sun, 5-Jul-87 20:22:25 EDT
References: <2757@mtgzz.UUCP> <345@genesis.UUCP> <532@houxa.UUCP> <1226@osiris.UUCP>
Distribution: na
Organization: Carnegie-Mellon University, CS/RI
Lines: 85
Keywords: Wozniak, CU, Apple, security
Xref: mnetor misc.headlines:856 comp.misc:794

In article <1226@osiris.UUCP>, jdia@osiris.UUCP (Josh Diamond) writes:
> 
> I my opinion, a little of all aspects of protection is necessary.  A
> combination of stiffer penalties for computer fraud/vandalism/theft, strong
> education on the fact that these actions are immoral (or at least illegal --
> no flames about "morality" please), and better security procedures.

     You have to be able to catch them first. Not a simple problem.

> 
> With regards to maintaining better security procedures, these could include
> (but in no means be limited to) the following ideas:
> 
> 1) Distribution of random letter combination privaledged passwords at random
>    intervals through secure communication channels.
> 2) Forcing users to change their passwords regularly.
> 3) Callback systems to verify the system is being accessed from a known
>    terminal.
> 4) Implementation of a key card system, in which the user must insert his/her
>    card into a slot in the terminal so that it can be read and verified.
>    Login name and password would still be required, but this would help
>    prevent users from looking over someones shoulder to find out their
>    password and get onto the system. (I believe that IBM already implemented
>    a system like this as an option on their 3270 series terminals).
> 5) Use of encryption systems (RSA public key preferably) for communication and
>    storage of private data/messages.
> 6) Keep accurate accounting files tracking all commands/system calls executed.
> 7) Make sure that all acounts autologout after a relatively short period
>    of idle time (perhaps send a warning message after 30 seconds idle time,
>    then autologout if still no key hit within 30 seconds).  This would prevent
>    the "root forgot to log out and left an open terminal as superuser" problem.
> 
> 					Spidey!
> 
> 
> 
> 
> -- 
> DON'T PANIC!!!                                          /\ Josh /\   At last! a
>                                                        //\\ .. //\\  spider that
> A message from Spidey, and the Spidey Team.  ----->>>  //\((  ))/\\  looks like
> Available via UUCP: ...[seismo,mimsy]!jhu!osiris!jdia  /  < `' >  \  a spider!


1)  Not really save.  If someone knows what the procedure is then 
    they will be able to use the passwords.

2)  If you force users to  change their passwords regularly then - 1. you'll
    have your users forgetting their passwords regularly, 2. have a less
    friendly system, 3 probably have the user cycle between two different
    passwords.

3)  Is only as safe as the phone lines.  If you have broken Ma'bell, you could
    probably fool this mechanism.

4)  This is only as safe as an extra password.  At some level this will
    get turned into a bit stream.

5) Isn't one of the problems with data encryption for communications, the
   fact that the both systems have to agree on the key?  And hence the key
   must be transmitted.

6) is easy to break, what if someone writes this loop -

	while (1) logged_system_call();

    when the log file is filled (ie. no more disk space) does your system
    come to a grinding halt or do you truncate the log file. Either
    solution is unexpectable.

7) easy to fool, plus makes the system very unfriendly.  You'll find users
   writing little programs like

	while (1) { printf("Hello\n"); sleep(29); }

   Theses are a start though and will help keep the novice from doing damage,
but if someone wants to get onto your system, I'm sure they'll find away
around those security  measures.

-- 
					Eddie Wyatt

e-mail: edw@ius2.cs.cmu.edu

terrorist, cryptography, DES, drugs, cipher, secret, decode, NSA, CIA, NRO.