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: Mon Mar 13 21:27:52 2006
From: lyal.collins at key2it.com.au (Lyal Collins)
Subject: HTTP AUTH BASIC monowall.

Although something else may have been intended by using the phrase
"password-authenticated key agreement", lets not forget that's all PKI is -
key agreement based on verifying a password.
At the server end, the site admins password is verified e.g. for SSL servers
At the client, if you're lucky, the user chose a hard to crack password.

That, and the access controls on each ndpoint is all that authenticates any
PKI-based schema.

Lyal

-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Jeremy
Bishop
Sent: Tuesday, 14 March 2006 8:02 AM
To: full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] 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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ