MD5 proposal

On Mon, Apr 01, 2002 at 01:32:24AM +0300, Andrei Robachevsky wrote:
> Allowing longer keys and using more secure encryption algorithm could
> improve security of password-based auth scheme.
>
> A new "auth:" scheme is introduced based on MD5 hash algorithm. The format
> of the new "auth" scheme is:
> 
> auth:             MD5-PW <digest>
> 
> where <digest> is a 128-bit MD5 digest.
> 
> For example: 
> 
> auth:             MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524

Please allow me to disturb your discussion. Using only a hash of a secret
does protect the structure of the secret, but does not increase the security
itself.

The security risk a password protection scheme protects against is
unauthorised access. This scheme is obviously vulnerable against eyesdropping.
Replacing the secret by a hash of the secret does change nothing of this
scheme. The hash does protect against attackers seeking for structured
secrets (i.e. Customer-ID || "-" || Service), which allow them to guess
other secrets correctly. So a hash does only protect customers with
correlated, easy guessable passwords. Futhermore this protection is weak,
because those secrets can be determined by a simple dictionary attack.

In order to really increase security there are two easy to implement variants:
 
  Descending Hashes (transaction hashes)
  
      Store a hash in your database as usual. A message is valid, if they
      HASH in the message can be hashed in a limited number of steps to the
      stored one. Then (with a time window for disordered messages) replace
      the stored hash by the new one. To reset the hash, allow a new syntax:
      SET-HASH authorised by this scheme itself to set this new value instead
      of the hash used for authentification.
      
      Example:
         Hash Generation:
	   Choose a secret                 => [h(=@X&Z
	   Genereate a number of hashes    => 0cad040d8049d9b612009821981ea1be
	    (shorten to demonstrate)       => 9b7a384557c7b80d321ae00e3ac40c79
					   => 980982910baed9b8642b5254b2ca495b
					   => c1322fe1ea006cbc265e4efde666724d
	   				   => b1b7a8a865734a4d4042f99441bda01e
         Store the initial hash "b1b7a8....da01e" in the DB.
	 Send a authenticated message with the hash "c1322f...724d".
	 Verification "echo -n 'c1322f...724d' | md5sum -b" successful and
	   therefore the hash in the database is replaced by "c1322f...724d".

  Keyed Hashes
      
      Store a secret in your database as usual. A message is valid, if some
      header lines, followed by the whole body of the message (but without
      the hash line itself), and followed by the line: "Password:
      >>secret<<" hashes to the same result as provided in the HASH line.

Pro and Cons:
  Transaction hashes are easy to compute even on Windows systems.
  Keyed hashes are difficult to compute on integrated mail systems.
  Transaction hashes are convertion independed.
  Keyed hashes should be taken the MIME way to be robust (software required).
  Transaction hashes require organisational prerequisites to be multiuser able.
  Keyed hashes can be computed indiviually.
  Transaction hashes require a sort of ordered message processing.
  Keyed hashes can be verified in any order.
  Transaction hashes provide an autoaging.
  Keyed hashes (without header processing) allow replay attacks.

Enough?