Re: Comments wanted on an authentication protocol

From: Sebastien Varrette (Sebastien.Varrette_at_imag.fr)
Date: 01/30/04

  • Next message: John E. Hadstate: "Re: FFT test with few kbits" 
    Date: Fri, 30 Jan 2004 10:42:52 +0100

    Johan Lindh wrote:
    > Sebastien Varrette wrote:
    >
    >> Johan Lindh wrote:
    >>
    >>> Hi all,
    >>>
    >>> If this is posted in the wrong place, please direct me to where I
    >>> should be.
    >>>
    >>> I'm designing a network protocol that intends to be simple to
    >>> implement (requiring no public key cryptography) with a known shared
    >>> secret. Unfortunately, the shared secret will have to be a
    >>> user-selected password, so it's going to be very weak in itself.
    >>>
    >>> My current scheme to protect the password when authenticating the
    >>> user uses SHA-1 and the standard 16-round Blowfish in CBC mode, as
    >>> well as a PRNG with a period of 2^8222.
    >>>
    >>> It goes like this, (where A is the server and B is the user/attacker):
    >>>
    >>> Sent in cleartext:
    >>>
    >>> A: send 20 random bytes for use as 'salt'
    >>> B: send username
    >>>
    >>> Now, both parties construct a blowfish key using the shared secret
    >>> (password, probably very weak) followed by the 'salt' bytes as input
    >>> to an SHA-1 hash function. The resulting SHA-1 hash is used as the
    >>> key to the blowfish cipher. [Note: Blowfish pretty well messes up
    >>> it's key. I'm not sure if I gain anything by hashing it first.]
    >>>
    >>> Sent encrypted:
    >>>
    >>> A: send 40 random bytes
    >>> B: calculate two SHA-1 hashes from the given 40 bytes, and send that
    >>>
    >>> [Note: 40 bytes because I need a number that blowfish won't have to
    >>> pad, while also being a multiple of SHA-1 digest size]
    >>>
    >>> Now, if A recieves the correct hashes from the client, the client is
    >>> authenticated. I do it this way so that an attacker that's listening
    >>> on the wire won't be able to make a dictionary or brute force attack
    >>> on the password offline. The only way to verify a guessed password is
    >>> online against A.
    >>>
    >>> What, if anything, have I missed?
    >>>
    >>> Should I drop the secret+salt -> sha-1 digest step?
    >>>
    >>> Regards,
    >>>
    >>> Johan
    >>
    >>
    >>
    >> Well, If I were you, I would use a public known and tested algorithm.
    >> The use of Blowfish AND a hach function just for authentication is in
    >> my opinion too complicated.
    >> If I analyse your constraints : the shared secret are user password
    >> possibly weak. Consequently, you wanted (of course it's a good idea)
    >> to use the hash of the password as a key. That's normal. Then, you can
    >> simply use the same hash algorithm (SHA-1 for you) for the
    >> authentication rather than wanted to add the use of a secret key
    >> algorithm (Blowfish for you). This is called MAC (for Massage
    >> Authentication Code).
    >> Authentication protocols based on MAC are various.
    >> SKID for example is part of the RIPE project.
    >> The protocol is the Following :
    >> A (Serveur) B (User)
    >> Choose random number Ra Choose random number Rb
    >> ----------- Ra ----------->
    >> compute T=Rb,H_K(Ra,Rb,"username")
    >> <----------- T ------------
    >> compute
    >> H_K(Ra,Rb,"username")
    >> and compare the result
    >> with the second part of
    >> T
    >>
    >> Ra and Rb are 64-bit long. H_K is the MAC (where K = SHA1("password")
    >> for you)
    >> To do a MAC, you can use HMAC (with SHA-1) for example :
    >> HMAC_K(M) = SHA1( (K xor pad1), SHA1( (K xor pad2),M) )
    >> cf http://www.ietf.org/rfc/rfc2104.txt
    >>
    >> For mutual authentication, simply continue the previous scheme in the
    >> following way :
    >> - A send to B : U=H_K(Rb,"servername")
    >> - B compute the U and compare it with what he receives.
    >>
    >>
    >> Another similar protocol you can use is the one used in the
    >> KryptoKnight that provide mutual authentication :
    >>
    >> Server User
    >> Choose random number Ra Choose random number Rb
    >> -------------------- Ra ------------------->
    >> <---- Rb,H_K(Ra,Rb,Ra xor "servername") ----
    >> ----------------- H_K(Ra,Rb) ---------------
    >>
    >> Sorry if I don't really answer your question.
    >> As I said, I just think that the use of a hash function AND a secret
    >> key algorithm such as Blowfish only for authentication is too
    >> complicated.
    >>
    >> The advantage to use H_K as a MAC rather than a secret key algorithm
    >> is for me to optimize the size of the message that are exchanged...
    >> If you prefer, just use Blowfish as H_K!
    >>
    >>
    >> Best Regards,
    >>
    >> Seb
    >
    >
    > I'm afraid I don't understand how these approaches would keep a
    > listening third party from doing an offline attack on the secret?
    >
    > You left out how the 'username' gets from the client to the server, so
    > I'll assume that it's being sent in the plain.
    >
    > A listener would know Ra and Rb (since they're being sent plaintext),
    > and would also know 'servername' and 'username'. So they could simply
    > start doing H_K(Ra,Rb,"username") with different values for K until they
    > come up with the same value that they saw on the wire. And since they
    > can do that offline, in parallell, it wouldn't take long.
    >
    To do this, he has to test all the possible keys K with a brute force
    attack, and you can have for exemple K=SHA-1(Ra,"passwd") (it's better
    than H("passwd") that's right). So K is 160 bits length... But you're
    right : it is possible for a man in the middle to do this offline. I
    should have notice that was one of your criteria, sorry.

    > Then they'd have the password. I *think* that my protocol prevents an
    > attacker from doing an offline attack. Am I wrong? Do I miss the point
    > of what you're saying?
    >
    I think so...

    > [I should note that I at first planned on using a HMAC-SHA1, but then I
    > realized that would allow offline dictionary attacks, which would most
    > likely be extremely effective against user-chosen passwords.]
    >
    > /Johan
    >

  • Next message: John E. Hadstate: "Re: FFT test with few kbits"

    Relevant Pages

    • (fwd) FreeBSD Security Advisory FreeBSD-SA-01:39.tcp-isn (fwd)
      ... susceptible to attack than other unencrypted sessions. ... > incoming connection is being established, ... > All versions of FreeBSD 3.x and 4.x prior to the correction date ... > requiring other authentication of the originator are vulnerable to ...
      (FreeBSD-Security)
    • RUS-CERT Advisory 2001-08:01
      ... Vulnerabilities in several Apache authentication modules ... vulnerable to a remote SQL code injection attack. ... SQL statements or cause the database query for the password to return ... In the MySQL and Oracle cases, the impact of the vulnerability is ...
      (Bugtraq)
    • RE: [Full-disclosure] Mozilla Thunderbird SMTP down-negotiation weakness
      ... MOZILLA THUNDERBIRD SMTP DOWN-NEGOTIATION WEAKNESS ... authentication information. ... Passive eavesdropping attack on CRAM-MD5 authentication failure ...
      (Full-Disclosure)
    • Re: [fw-wiz] Hardware tokens for remote access authentication
      ... >>md5 authentication, ... >some fancy theoretical footwork to pull off an attack. ... the relative importance of hash collisions in the classic 64-bit SecurID ... But the baseline really depends on your particular threat profile, ...
      (Firewall-Wizards)
    • Re: Comments wanted on an authentication protocol
      ... >> secret. ... >> on the wire won't be able to make a dictionary or brute force attack ... > The use of Blowfish AND a hach function just for authentication is in my ... I just think that the use of a hash function AND a secret key ...
      (sci.crypt)