Re: Suggested extension

Ned Freed <NED@sigurd.innosoft.com> Tue, 01 December 1992 02:04 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19889; 30 Nov 92 21:04 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19885; 30 Nov 92 21:04 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23903; 30 Nov 92 21:05 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19880; 30 Nov 92 21:04 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19876; 30 Nov 92 21:04 EST
Received: from [192.160.253.70] by CNRI.Reston.VA.US id aa23896; 30 Nov 92 21:05 EST
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF #1992 ) id <01GRRSDUOOVE8Y510G@SIGURD.INNOSOFT.COM>; Mon, 30 Nov 1992 18:04:57 PDT
Date: Mon, 30 Nov 1992 18:04:57 -0700
X-Orig-Sender: ident-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: Suggested extension
To: stjohns@umd5.umd.edu
Cc: galvin@tis.com, pen@lysator.liu.se, ident@CNRI.Reston.VA.US
Message-id: <01GRRSDUOOVG8Y510G@SIGURD.INNOSOFT.COM>
X-VMS-To: IN%"stjohns@umd5.umd.edu"
X-VMS-Cc: IN%"galvin@tis.com", IN%"pen@lysator.liu.se", IN%"ident@CNRI.Reston.VA.US"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Content-transfer-encoding: 7bit

Just because this particular extension doesn't offer much exposure (i.e.
the password doesn't protect anything that important) is no excuse for
deploying another clear-text-password scheme on the Internet. Such schemes
should be carefully limited to the essential cases, since fixing them
later is quite costly.

An alternative proposal: Instead of sending the password, send a hash value.
Specifically, take the password-in-clear plus the entire text of the query
and run it through a good hash function like MD5. Take the output of this
function and send that along with the query. This eliminates exposure of the
clear text password and limits a network sniffer to repeating old queries.
(It presumably already saw the answers to these queries.) If you want a
bit more security, put a time value in there and hash it too -- this can be
used to limit queries to a small time regime.

I do agree that this should only get done in the next revision of the document.
But if it gets done at all I think a hash function is the right way to go
about it.

				Ned