1995-07-24 - re: big dictionaries

Header Data

From: Chris Gorsuch <chrisg@chrisg.itg.ti.com>
To: cypherpunks@toad.com
Message Hash: 861bc37a97b4f5ca23cba621bafa77e0069014c448f1dba4965fcb867e47a6f0
Message ID: <199507241910.OAA00283@chrisg.itg.ti.com>
Reply To: N/A
UTC Datetime: 1995-07-24 19:13:41 UTC
Raw Date: Mon, 24 Jul 95 12:13:41 PDT

Raw message

From: Chris Gorsuch <chrisg@chrisg.itg.ti.com>
Date: Mon, 24 Jul 95 12:13:41 PDT
To: cypherpunks@toad.com
Subject: re: big dictionaries
Message-ID: <199507241910.OAA00283@chrisg.itg.ti.com>
MIME-Version: 1.0
Content-Type: text/plain


Bill,
   Good point about using a "slow" hash algorithm.  A "dictionary" attack on
the hash should fail because, in order to currently use the password the old
password had to not be in the dictionary in the first place.  However "keyspace"
attacks (brute force) would still be quite feasible.  Would probably want to
put something similiar to a salt in there to help increase the keyspace.
   Keep in mind that the only reason I suggested a hash at all is to prevent an
admin who, in general, would not go through the effort to replace login/password
or install a sniffer to get your password, but might be "unnecessarily" tempted
by having easy to access passwords stored in plaintext on the server (still 
in a file only the admin could read).  Basically just as a method to keep
honest people honest.
   To verify that a user wasn't using a variation on the original, you would 
want to only store the hash of the original, but do hashes of the variants on
the "new" password and compare with the stored hash of the old password.  And
of course, only store a password AFTER it has been changed.
   Really paranoid admins should use challenge/response/one-time passwords 
with/or kerberos.

chris gorsuch
chrisg@ti.com





Thread