[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200603161057.13765.requiem@praetor.org>
Date: Thu Mar 16 20:21:41 2006
From: requiem at praetor.org (Jeremy Bishop)
Subject: HTTP AUTH BASIC monowall.
On Thursday 16 March 2006 06:48, Simon Smith wrote:
<snip>
> 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
Pavel's link on SRP ( http://srp.stanford.edu/ ) is close to what you
might be looking for. (That is, a means of password-based
authentication over an untrusted medium.)
> 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.
Either your secondary tunnel corrects the issues with the initial tunnel
or it does not. If it does there's no need to bother with SSL in the
first place. If it doesn't, you're still open to the exact same
attacks.
<more snippage>
> 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.
If you secure the authentication alone, an attacker will simply
piggy-back on your existing session. E.g., you tell server A to
reboot, but by the time the command gets to the webserver it happens to
include a few extra commands.
--
Violence is the last resort of the incompetent.
The competent, of course, make it their *first* resort.
Powered by blists - more mailing lists