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]

Date: Wed Mar 15 20:14:41 2006
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: HTTP AUTH BASIC monowall.

Simon Smith wrote:

>     I am not missing your point. It is me who is not being clear about
> what I am asking hence why everyone is telling me one thing when I really
> want to hear something else. I want to protect the authentication data
> within the SSL session because I do not trust the HTTP BASIC auth and I
> most certainly do not trust the end users to always do whats right. I want
> a technology to protect the data, not a user who can be social engineered
> into doing something wrong.

Ahhh -- so the solution you are really looking for is this long-kept, 
deep dark security guru guide to success (I hope none of the real 
security ninjas decide to kill me for divulging it as I'm not supposed 
to know):

  Never tell anyone anything!

If you don't tell anyone the passwords to anything, then they can never 
disclose them, no matter how cruel and unusual the torture applied to 
them (or whatever more subtle SE measures that may be employed by a 
really determined attacker).

Of course, if you are one of the employees or others involved in 
setting the system up in the first place (or at least in securing it 
post-installation), you cannot tell yourself those passwords either.

But damn, you alkready know them because your told yourself while
(re-)setting them...

Quick -- devise a script to automatically change all the initial 
passwords you know to ones randomly generated by the script at runtime 
and that are not recorded anywhere by the script and you'll be set.

Of course, _no-one_ will be able to use your IT system for anything 
useful, but it will be darned secure, as even connecting electrodes to 
_your_ genitals and repeatedly applying just short of fatal shocks will 
_never_ result in disclosure of any working access mechanism, nor will 
any less subtle means (exclusing some based on physical access).

But at least you will have what you say you want -- a technoloy that 
protects your data "and not a user who can be social engineered into 
doing something wrong".

Seriously -- you have missed the most basic aspect of computer 
security.  It is a _process_ evolving and changing over time as your 
technology uses and needs change _AND_ it is not about risk prevention 
but all about risk mediation and management...

What you are asking for is nonsensical within that proper undrstanding 
of the nature and role of computer security, which is why you are both 
getting the "wrong" kind of responses and struggling to "sensibly" 
frame your question to get the answer you (think you) want.

If people are involved in using a system it will be fallible.  You can 
always manage that fallibility a bit better than you are now, but 
depending on the value of the material being "protected" there will 
always be a point where the cost of ratcheting any more security into 
your system is not worth the resulting (miniscule) increase achieved.  
It seems that you have particularly unrealistic expectations in this 
regard...

Regards,

Nick FitzGerald