Re: HTTP AUTH BASIC monowall.

[Simon Smith <simon () snosoft com>]

Mike,
    Flames like yours are useless. If you do not know how to answer the
question that I am asking, then just be quiet. Mark Coleman is one of
the few people that seems to have understood my question and provided me
with a viable solution. Again, thanks Mark!

Michael Holstein wrote:
> First off, I think 3 days spent on this topic is sufficient --
> epically since you fail to grasp some of the more basic concepts which
> underly the OSI model.
>
> > 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 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.
>
> Basic Auth via SSL is secure. I could use ROT-13 encoding inside SSL,
> and it'd still be 128 bit encryption over the pipe. What matters here
> is not how the password is encoded for transmission, but HOW it's
> transmitted (in this case, via a SSL session).
>
> >     This concern came about initially because I was sniffing a LAN and I
> > noticed a lot of clear text http communications. Within those
> > communications was the basic authentication header. When I decoded the
> > auth string I successfully logged into the system receiving the packets.
> > Very quickly I found that I was connected to a centralized IT management
> > system that allowed me to control any other computer on the network. Not
> > only that, but it also allowed me to record emails, key strokes, install
> > software, remove software, etc.
>
> Duh. If I can sniff a network, I can do all sorts of stuff. Welcome to
> the world of tcpdump, ethereal, and promiscious capture.
>
> > I took the liberty of hardening the system by implementing SSL
> > internally. That really didn't do much for the security of the system
> > though. I had one of my co-workers attempt a Man in the Middle attack,
> > and he did it successfully. Sure enough, once the SSL session was had
> > the encoded string could be decoded and access to the main console could
> > be gained.
>
> Then he tricked you into accepting the bogus certificate. Shame on you.
>
> >     My concern isn't firewall management. My concern isn't with SSL
> > going over the Internet. My concern is more with SSL on a LAN and that
> > this IT tool and other similar tools can be compromised easily 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.
>
> Good grief .. if you're that worried about it, use client-side
> certificates (with a password). If you're even MORE worried, put that
> certificate on a hardware token that protects the key in hardware.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/


-- 
Regards, 
        Jackass


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