[Xitami] Plaintext passwords on Bugtraq (again)

Thomas J. Hruska xitami@lists.xitami.org
Thu, 04 Jul 2002 15:41:32 -0400


At 08:14 AM 7/4/2002 +0100, Brian {Hamilton Kelly} writeth:
>In message <3.0.6.32.20020624091136.00a26550@mail.shininglightpro.com>
>   "Thomas J. Hruska" writes:
>
>> However, the problem still won't go away since anyone sniffing for packets
>> can grab any HTTP Authorization header and store it away for a later replay
>> attack (MD5 hashes included).  What is worse is that Xitami doesn't have
>> DIGEST mode available which means that the username:password combination is
>> only Base64 encoded (and makes it _VERY_ easy to obtain access to "secure"
>> areas - e.g. remote /admin access).  Even with DIGEST mode, it still
>> doesn't stop a replay attack since the HTTP protocol doesn't have any
>> secure handshaking methods.
>> 
>> So, hashing the files might help some locally, but won't stop anyone from
>> attacking the server remotely.  The problem is not necessarily with Xitami
>> but also has to do with the inherent weakness of the HTTP protocol.
>
>There's an easy answer to that: don't remotely administer the server via
>HTTP!  Either walk into the machine room (or use SSH sessions) and use a
>text editor.

Another answer would be to set up some sort of handshaking in the HTTP
protocol (however, I don't see the IETF moving to change that very
quickly).  It isn't that difficult to add a level of security that would
make it much more difficult to crack.  ESMTP already does this with the
header in the first message from the server.  You then run an MD5 hash with
your password and the string sent in the first message and send it with the
EHLO command.  Much more secure than even DIGEST since a replay attack
requires cracking the username and password before a replay can occur.

However, I agree with the use of SSH tunnelling for remote admin.  Yet,
HTTP could offer a little more security than it does right now (which is
basically squat).


          Thomas J. Hruska -- shinelight@shininglightpro.com
Shining Light Productions -- "Meeting the needs of fellow programmers"
                  http://www.shininglightpro.com/