24 Apr
2007
24 Apr
'07
6:51 p.m.
At 09:18 PM 4/24/2007, Jerome H. Fine wrote:
It's not reversible because a hash algorithm is used. A hash
deliberately "throws away" information, distilling a string into a
smaller representation. (You can't reconstruct an apple from a bowl of
applesauce.) That's a common operating system concept first employed by
Unix systems.
Richard wrote:
Lots of systems made that error. For instance,
RSTS/E stored the
passwords in cleartext and you could list them out if you were a
privileged (1,*) user. I discovered that when you submitted a batch
job through the @ processor, it ran as user batch on account (1,2).
So it wasn't too hard to submit a batch job that ran the ACCOUN
program to list out the passwords.
Jerome Fine replies:
Perhaps Zane is following this thread or anyone else
who knows VMS well. I seem to remember that the
userid / password were placed through the same algorithm
as the stored values. The results were compared and
that was what produced a match. In addition, I also
understand that it was impossible to reverse the results
of the "encryption" algorithm. And with later versions
of VMS, the choice of the password was restricted, possibly
to a string produced at random by VMS itself; this latter
feature prevented users from having the name of a special
individual as the password.
In other words, forced generated passwords. Many other OSs allow this;
for example, DEC UNIX.
Does anyone know of any other operating system which
requires
secure passwords along with storing only the encrypted
equivalents of the userid / password?
Lots and lots of 'em. Most unix compatible systems, windows, etc.
VMS did not encrypt usernames, BTW. Just passwords.
Here's what I see if I edit SYSUAF.DAT on my system:
**DEFAULT *************
**DGS *************
**FIELD *************
**MURPHY *************
**SYSTEM *************
**SYSTEST *************
**SYSTEST_CLIG *************
**TCPIP$FTP *************
**TCPIP$REXEC *************
**TCPIP$RSH *************
-Rick