lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <441B0B49.1080304@brvenik.com>
Date: Fri Mar 17 19:18:36 2006
From: security at brvenik.com (Jason)
Subject: HTTP AUTH BASIC monowall.

I do not think that digest over basic is really going to help in the
MITM case either since the attacker that can successfully pull off the
SSL MITM he controls the connection. Digest avoids disclosing the actual
password but it does not necessarily prevent the attacker from changing
it. The attacker can now not only access the system impersonating you
but hijack it from you just as if he had the actual password.

Digest also does not prevent the attacker in this case from presenting
the client with data that produces a reversible or discoverable text
thereby recovering an _effective_ password.


"
   Like Basic Access Authentication, the Digest scheme is based on a
   simple challenge-response paradigm. The Digest scheme challenges
   using a nonce value. A valid response contains a checksum (by
   default, the MD5 checksum) of the username, the password, the given
   nonce value, the HTTP method, and the requested URI. In this way, the
   password is never sent in the clear. Just as with the Basic scheme,
   the username and password must be prearranged in some fashion not
   addressed by this document.
"

The attacker now needs to provide a nonce and wait for the reply. The
ability to control data that will be used in the hash is key to making
it potentially successful. The nonce, username, HTTP method, and URI
will all be known at this point. Now the attacker only needs to find a
hash collision with _any_ password that satisfies the checksum and the
game is again over.

http://www.stachliu.com/collisions.html

New average run time on P4 1.6ghz PC - 45 minutes

I don't think that the attacker needs to actually launch a collision
attack because they have all but one component used in the hash. Now the
attacker only need to launch a dictionary attack against the provided
hash and they likely will find the result.

Given that the attacker controls the connection they can learn the
requisite details by observing normal interaction and producing a
precomputed hash table with the nonce they plan on providing. This could
result in a near real-time compromise of the password when an actual
attack is launched.

A solution that requires another successful MITM is required to add any
real complexity to the equation. The solution must introduce a
computational complexity that removes the precomputed and known text
attack vectors. Any solution that does not is ultimately no better when
considered in the context of a successful MITM. Digest raises the bar a
little more but I do not think it will solve the problem.

Simon Smith wrote:
> Thanks felix!
> 
> Felix Lindner wrote:
> 
>>Hi,
>>
>>On Thu, 16 Mar 2006 09:48:07 -0500
>>Simon Smith <simon@...soft.com> wrote:
>>  
>>
>>>My first thought was on how to harden the
>>>authentication because the basic auth didn't cut it for me. Thats what I
>>>am looking for ideas for.
>>>    
>>
>>you may be looking for Digest Authentication:
>>http://www.ietf.org/rfc/rfc2617.txt:
>>
>>   "Like Basic, Digest access authentication verifies that both parties
>>   to a communication know a shared secret (a password); unlike Basic,
>>   this verification can be done without sending the password in the
>>   clear, which is Basic's biggest weakness. As with most other
>>   authentication protocols, the greatest sources of risks are usually
>>   found not in the core protocol itself but in policies and procedures
>>   surrounding its use."
>>
>>cheers
>>FX
>>
>>  
> 
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ