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
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
Return to July 1995
Return to “Chris Gorsuch <chrisg@chrisg.itg.ti.com>”
1995-07-24 (Mon, 24 Jul 95 12:13:41 PDT) - re: big dictionaries - Chris Gorsuch <chrisg@chrisg.itg.ti.com>