Good salt practices, references?

From: Andrew van der Stock (ajv@e-secure.com.au)
Date: 09/07/01 

From: "Andrew van der Stock" <ajv@e-secure.com.au>
To: <secprog@securityfocus.com>
Subject: Good salt practices, references?
Date: Fri, 7 Sep 2001 15:24:24 +1000
Message-ID: <GLEMLPDJLNNLKLDLMOJEMENHCDAA.ajv@e-secure.com.au>

Hi there,

I'm looking at trying to reduce the risk from authentication over the
network using preshared secrets.

Right now, the scheme is:

Server encrypts the password, truncated to 8 characters with 3des, using a
static 8 byte salt. It's then stored on the server, supposedly in a safe
place.

When the user authenticates, the client takes the user's input, encrypts the
password with 3des and the same static salt, and takes a random 8 or 16 byte
challenge from the server to hash with the encrypted password. The resulting
digest response is sent back to the server. The server also does the same as
the client and compares the two digests. If they compare, you're in.

There's two attack mechanisms available:

* get the password from the server; time to decrypt, < 1s.
* As the challenge, the fixed 8 bit salt, the response and the algorithms
are known, a remote attacker with access to the data stream can attack the
password using standard dictionary and brute force attacks, particularly as
the initial password is always =< 8 chars long. It shouldn't take much more
than two weeks using something like John the Ripper on one machine.

I'm interested in best practices with C/R mechanisms, dealing with salts,
etc.

My current thoughts for improving this process are:

Digest the password using SHA1 and store on the server.

When the client connects to the server, the server gives the client a random
salt to use. The client concatenates the digest, the current time and IP
address, and symmetrically (ie 3des or AES) encrypts the resulting
concatenation using the digest as the key with the server supplied random
salt. The server takes the encrypted string, and decrypts it. If the time is
out of whack (within limits, a la kerberos), it dumps it. If the IP address
doesn't match its ACLs, it dumps the connection. It then compares the two
digests, and if it's okay, it's in.

The desired risk outcomes are:

a) lower security than public key alternatives* for ease of use
b) better than before (pretty much anything will be)

(* the new authentication process optionally supports public key, NTLM,
RADIUS and Kerberos authentication methods; so users can choose their
preferred poison)

The security aims of the new pre-shared authentication method is to ensure
that if the password digest is captured on the client, a lot of work
(commensurate with the user's ability to create decent passwords, obviously)
will have to be done to reverse it, and to avoid the digest being misused if
the network stream is captured or replayed.

Obvious errors, improvements, or has someone solved this before, and I'd be
better off adopting that instead?

Andrew

Relevant Pages

  • Re: Digest Authentication - IIS6
    ... I am fighting with a web site to setting up to use Digest ... If I setup the website with Basic authentication works fine (for the ... It happen on a Windows 2003 Server R2, IIS6, Application Pool was ... Your english is better then most people who were born in the US:) ...
    (microsoft.public.inetserver.iis.security)
  • RE: Good salt practices, references?
    ... Subject: Good salt practices, references? ... A static salt is all but worthless; all it does is prevent an attacker from ... > It's then stored on the server, ... > When the user authenticates, the client takes the user's input, ...
    (SecProg)
  • Re: Proposal for Lite Encryption for Login Form without SSL
    ... This way the password is not sent to the server ... simply copy the server-side salt used to hash the pw in the ... This would be the equivalent to a public key in public key encryption ... library or function that's readily available for both js and php. ...
    (comp.lang.php)
  • Re: Proposal for Lite Encryption for Login Form without SSL
    ... This way the password is not sent to the server ... simply copy the server-side salt used to hash the pw in the ... password in the database, it does make public the server-side salt ... This would be the equivalent to a public key in public key encryption ...
    (comp.lang.php)
  • Re: Unable to authenticate with digest authentication...
    ... No, I have to access to this device, it's a sealed embedded web server type ... device, with no apparent logs. ... Somehow I think .NET is doing Digest authentication incorrectly. ...
    (microsoft.public.dotnet.security)