Re: Re: Cookie Security

[Audrius <organzarama () gmail com>]

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...

Actually I think the whole implementation isn't good. Bad thing is,
that all the encryption must be done on users side and using
JavaScript.  We gonna have a usability problem here. Let's look here.
http://www.w3schools.com/browsers/browsers_stats.asp. Statistics
shows, that 5% of user this year browse sites with JS turned off. For
them your site won't work and probably they will never return back.

>  I had in my mind to implement md5 and 3des via JavaScript to deal with the
> operation. These are tried and tested algorithms. Both already implemented in a
> similar way for our authentication mechanism.

SessionID + Password MD5 = 3DES result? And everything must be done
using JS on client side?

>  "...if I will have another data?
>  in order to build the string, you would require the users password md5 hash
> (our PSK in this implementation). (not transmitted!).

Do you know what is rainbow tables? If I'll get a users password MD5
from cookies, then there will be no need for me to build any strings.
Because I'll try to get a users password first. And if I'll be lucky,
then I'll just log in. I think it would be good to add some salt
(quite long string) to users password before making MD5 hash. This
will prevent from rainbow tables (question is for how long). :)

>  "Where you will store sessionID and this hash"
>  The hash & sessionid would be stored in cookies, client side.
>  Unless you are aware of an alternative location?

I think the weak thing here is that both values are in the same place.
If I can get hash, then probably I will get sessionId too. It means I
must to find a way how to get cookies. After that what do I need to
do, just few the client side code what calculations are made.
I think, that to make such calcs on client side is bad.

Actually I do not see any advantages in your method. I think that
tokens can give the same functionality, no JS on client side will be
required and no calculations will be done on client side. If for the
token will be used for example a GUID, then there will be no
possibility to decode a users password from it. It means it's useful
only till next request. Both methods are prone to same attacks, so why
to make life harder? :) I think you also must concentrate more on
other parts of security too. And even then your site visitors won't be
100% secure using your site. There are some things which you can't
control. For example vulnerable users browser or os.

Ok, try to protect your point of view, maybe in this discussion we
will find some interesting security ways. :)

Audrius


P.S. Where others are gone? :)