Date: Wed,  9 Jun 93 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #149
To: tcp-group-digest


TCP-Group Digest            Wed,  9 Jun 93       Volume 93 : Issue  149

Today's Topics:
                          Password security

Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Tue, 8 Jun 93 09:57:28 +0200
From: jt@fuw.edu.pl
Subject: Password security
To: samisen!djc@sol.UVic.CA, tcp-group@ucsd.edu

> > From djc Fri Jun 04 13:01:14 1993
> > To: J.R.Jagger@sheffield-hallam.ac.uk
> > Subject: Password security
> > 
> > I wrote some code that does secure password security that you are welcome
> > to.  It's purpose was to secure radio logins to a Unix box and for that
...
> > When you log out you are all ready to start all over again with S98 instead
> > of S99.  You can continue this process until you get to S0; then you have
> > to call up the sysadmin and get your account reset so you can start with

Seems it is really good. I see can set new password through radio without
risk of security loss: send S100 of new password and use S99 on first
login. Did you try the MD5 written in assembly or in high-level language?
Few seconds can be noticeable bit of time, especially if during the time
computer doesn't do anything else (i.e. doesn't service network packets).
If it isn't too complicated, I would rewrite it in 8088/80386 assembly
language, but I don't know the MD4/MD5 algorithms - can you send me them?

Suppose to avoid modifying NOS (or other network software) the password
encoding can be written as separate program which, when invoked, asks
for password, reads hash count from a file and puts count-1 there, then
TSR, waits until return to terminal mode ("Password: " or other string
defined in program configuration on screen in current line), then puts
encoded password in keyboard buffer and finally frees its memory.
Some problems can be expected: there are programs which read keystrokes
directly from hardware (FTP TELNET), it is not so easy to emulate it;
I don't know what to do on server's side - replace login by own program?

73's, JT

------------------------------

End of TCP-Group Digest V93 #149
******************************
******************************