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: <44198B0E.6090007@snosoft.com>
Date: Thu Mar 16 15:58:16 2006
From: simon at snosoft.com (Simon Smith)
Subject: HTTP AUTH BASIC monowall.

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