full-disclosure - HTTP AUTH BASIC monowall.

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] [thread-next>] [day] [month] [year] [list]

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