Re: Re: Re: Cookie Security

[ellukicq () icqmail com]

When someone says the words "Client Side Security", it's time to worry! 
But I must stress that the security in my solution is not operating at client side. 
Essentially it is just challenge response authentication method!  and that is not client side security. we would all be 
in trouble if it was! 
 
 
 
"And it's why I provoke you to better analyze your own algorithm" 
        The actual method of protecting the user from session stealing via network eavesdropping seems to be good to 
me. 
        That is what I am dealing with here. Protecting from sniffers. Not XSS. Not Malware. Not even access to 
cookies! 
        I can't find fault with the proposed system from that respect, and thats why I posted here. 
 
 
"Statistics shows, that 5% of user this year browse sites with JS turned off" 
        Our web application is dependant upon JavaScript already. it's not a public system, we manage the client side 
also. 
        I'm not aware of any client side language that would not suffer from this lack of distribution. 95% is likely 
to be the best coverage I can expect! 
 
 
"SessionID + Password MD5 = 3DES result?" 
        No, that doesn't make any sense.  
        *       Take sessionID GUID string. 
        *       Encrypt the sessionID string using the MD5 hash as the 3DES ENCRYPTION KEY. 
        *       That gives us the 3DES result. 
 
 
"Do you know what is rainbow tables?" 
        Security is my business. so yes. :-) 
 
 
"If I'll get a users password MD5 from cookies," 
        If that information is made available to an attacker, a level of security has been bypassed already... 
        I am protecting from network eavesdropping (packet sniffers) here. 
 
 
"I think it would be good to add some salt" 
        good shout. even though the md5 shoud NEVER be available to an attacker, this is a good suggestion. defense in 
depth! :-) 
 
 
"It means I must to find a way how to get cookies." 
        All web applications suffer this problem, even over SSL. This is NOT what i am trying to fix here. 
 
 
"I think, that to make such calcs on client side is bad." 
        making the calculations client side poses no risk. storing the data for these calculations client side does... 
        but again, this is a separate risk from network eavesdropping. 
 
 
"Actually I do not see any advantages in your method. I think that tokens can give the same functionality" 
"Both methods are prone to same attacks" 
        Both not true. Tokens can be sniffed and used. My method stops this. That is the advantage. 
 
 
"I think you also must concentrate more on other parts of security too" 
        I agree, however, any chain is only as strong as it's weakest link... right now, that is this issue! 
        I have analyzed all aspects of the system including client OS, browser, user awareness (all of which we are 
lucky enough to manage also) :-) 
        Priority has been given to this flaw. 
 
 
"in this discussion we will find some interesting security ways." 
        It has already been very useful for me. although not in the areas i was looking for!    :-) 
 
 
Right now, it feels this method of protecting the user from session stealing via network sniffing is ok... 
But the technologies around it, i.e server side issues (XSS), browser vulns (Cookie divulge e.t.c), and OS vulns are 
the concern. 
But I feel that this would be the case for any solution! 
 
 
RPT:    When someone says the work "Client Side Security", it's time to worry! 
RPT:    But I must stress that the security in my solution is not operating at client side. 
RPT:    Essentially it is just challenge response authentication method! that is not client side security. we would all 
be in trouble if it was! 
<-----Original Message-----> 
> From: Audrius
> Sent: 4/30/2008 8:47:59 PM
> To: ellukicq () icqmail com;security-basics () securityfocus com
> Subject: Re: Re: Cookie Security
>
> 2008/4/30 Elliott Lewis <ellukicq () icqmail com>:
> >  If we don't consider the theory at the very first step, we are very likely
> > to end up wasting our time.
> >  If the theory is proven to be sound, that is when you move on.
>
> Yes, I agree. And it's why I provoke you to better analyze your own
> algorithm (also have some discussion why some things are good and some
> are bad). :)
>
> >  I assume from your response, the basic procedure seems to be reasonable?
> >  Now time for the practice...