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: <441988F2.5050303@csuohio.edu>
Date: Thu Mar 16 15:49:47 2006
From: michael.holstein at csuohio.edu (Michael Holstein)
Subject: HTTP AUTH BASIC monowall.

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.