[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4419C81C.5060707@snosoft.com>
Date: Thu Mar 16 20:50:31 2006
From: simon at snosoft.com (Simon Smith)
Subject: HTTP AUTH BASIC monowall.
Jeremy,
Thanks for the input, I appreciate this a great deal!
Jeremy Bishop wrote:
> On Thursday 16 March 2006 06:48, Simon Smith wrote:
> <snip>
>
>> Encoding a username and password combination using base64 is not
>> secure, but, I understand why it is encoded in base64. Having said
>> that, I am trying to discover/create an alternate method for
>> authentication that is secure even if the SSL pipe is compromised. I
>>
>
> Pavel's link on SRP ( http://srp.stanford.edu/ ) is close to what you
> might be looking for. (That is, a means of password-based
> authentication over an untrusted medium.)
>
>
>> liked the idea of creating a secondary tunnel within the initial SSL
>> tunnel but I am not certain that it would be the best way to do it.
>>
>
> Either your secondary tunnel corrects the issues with the initial tunnel
> or it does not. If it does there's no need to bother with SSL in the
> first place. If it doesn't, you're still open to the exact same
> attacks.
>
> <more snippage>
>
>> once a LAN is penetrated. Providing an extra layer of security within
>> the SSL tunnel would help to prevent this tool and others like it
>> from being compromised so easily. 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.
>>
>
> If you secure the authentication alone, an attacker will simply
> piggy-back on your existing session. E.g., you tell server A to
> reboot, but by the time the command gets to the webserver it happens to
> include a few extra commands.
>
>
--
Regards,
Jackass
Powered by blists - more mailing lists