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]

Message-ID: <200603131301.37931.requiem@praetor.org>
Date: Mon Mar 13 21:01:25 2006
From: requiem at praetor.org (Jeremy Bishop)
Subject: HTTP AUTH BASIC monowall.

On Monday 13 March 2006 12:37, you wrote:
> List,
>     SSL is not a fix for the problem, SSL is just a way of evading
> the issue or hiding the hole. I can bypass SSL with a man in the
> middle attack (which I've already done several times). Once I bypass

I'm assuming that this is using unsigned or otherwise invalid 
certificates, and relying on user ignorance or apathy to succeed.

>     What is the solution to this problem? Is there a solution that
> does not require a different auth type?

SSL.  (Done correctly.)

Any "solution" is likely to rely on public-key crypto and as such will 
require a similar mechanism for verifying identity.  If sufficiently 
widespread, apathy and ignorance will render it vulnerable to the exact 
same problems.

I suggest "password-authenticated key agreement" as a starting point for 
research outside the traditional public-key methods.  (Although, as far 
as I can tell, it would require the "password" to be accessible to the 
server so that the session can be set up.  IOW, you get around the 
problems of trusting a cert, but you're back to storing passwords in 
plaintext.)

Jeremy

-- 
Rules build up fortifications behind which small minds create satrapies.
A perilous state of affairs in the best of times, disastrous during
crises.
                         -- Bene Gesserit Coda