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: Wed Mar 15 16:44:04 2006
From: simon at snosoft.com (Simon Smith)
Subject: HTTP AUTH BASIC monowall.

Now we're on the right track...

which brings up a question... what are the odds that someone could
forcefully redirect traffic to their proxy after having compromised a
network? Could this be done with arp poisoning? I haven't toyed with
that in a while so I can't say yes or no...

Valdis.Kletnieks@...edu wrote:
> On Wed, 15 Mar 2006 10:14:23 EST, Simon Smith said:
>   
>>     I think that we've lost focus of my original question. My question
>> refined is, does anyone else agree with me that using HTTP BASIC AUTH
>> for important applications is a security risk/vulnerability (regardless
>> of SSL)? Or, is everyone here telling me that they "feel safe" if the
>> connections are SSL'ed and are not worried that the HTTP BASIC AUTH is
>> only creating a base64 hash of their usernames and passwords that can
>> easily be reversed? My personal opinion, I feel like we're painting over
>> the rust on an old car... I don't feel like we're fixing the risks.
>>     
>
> It's not bulletproof.  There are holes.
>
> Having said that, remember two things:
>
> 1) Once you're doing BASIC over SSL, it requires a MITM attack.  In most
> network configs, that means that the attacker needs to already control at
> least one *other* box on the wire.  At that point, you have bigger problems.
>
> 2) BASIC AUTH over SSL isn't the weak point, especially if the source box is
> a Windows box with 57 different kinds of spyware and backdoors on it.  If the
> endpoints aren't secure, you can't *really* secure the path between them.  This
> is also why using SSL on your e-commerce site doesn't mean it's secure - it
> merely guarantees that the data isn't screwed with on its way to the server,
> where it will likely get dumped into a world-readable file for the benefit of
> the first guy to try anonymous FTP to the site because the FTP server doesn't
> chroot an anonymous connection....
>   


-- 


Regards, 
	Adriel T. Desautels
	Harvard Security Group
	http://www.harvardsecuritygroup.com


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ