Date: Wed Mar 15 20:59:53 2006
From: simon at snosoft.com (Simon Smith)
Subject: HTTP AUTH BASIC monowall.

Nick,
    I partially agree with what you've said and rather enjoyed your email...

Nick FitzGerald wrote:
> 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
>
> _______________________________________________
> 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, 
	Adriel T. Desautels
	Harvard Security Group
	http://www.harvardsecuritygroup.com

Powered by blists - more mailing lists