Tom writes:
> Many years ago, the encrypted value was only two bytes (16 bits).

That was my recollection too, hence the warning that these techniques might
not be as good today as they once were (not that 16 bits was *ever* any good
:-)

> At the time, I calculated out how much "storage" would be needed to
> create a "dictionary" of all possible encrypted values, and it spanned
> many discs "at the time" -- of course, we're talking about 7933-class
> drives with max capacities in the "mere megabytes" range ;)

16 bits gives you 65536 possible passwords times eight characters (does
Security/3000 support longer passwords?) would be one half megabyte of data
before any compression and would fit nicely on a 1980s floppy disk.

Even increasing this to a 32-bit hash would only require 32GB (without
compression) to store all possible password values.  Might take a while to
compute (depending on just how insecure the algorithm is) but it might fit
comfortably on to a single blue laser DVD in a year or two, and you could
fit it on a laptop hard disk today.

But I suspect that the "hash" algorithms used could easily be so simple that
a "reverse" algorithm could be constructed which would go directly from the
hashed value to a useable password string in a fraction of a second.

> I think we are on a similar threshold now [and I've let Vesoft know it],
> but I think they are focusing their attention on keeping the encrypted
> values "secure" [priv files, etc.]
>
> In other words, if you have enough resources to GET the file of encrypted
> passwords in the first place, you would have already compromised the
> security enough that the passwords would be of little additional value...

Perhaps, but I don't think this will make anyone feel very good.  There are
other ways of compromising the password list (access to any backup tape for
example) which do not require compromising the system itself first.

Typical MPE system security is excellent with respect to end users who only
access the system through a logon that puts them directly into an
application (apart from "minor" issues like unencrypted network login
dialog), but most systems are secure against users who can get to a CI
prompt only through obscurity.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *