Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2818 > unrolled thread

Using sessions and cookies

Back to article view | Back to comp.programming

Contents

  Using sessions and cookies Victor Porton <porton@narod.ru> - 2013-01-15 19:37 +0200
    Re: Using sessions and cookies Bjoern Hoehrmann <bjoern@hoehrmann.de> - 2013-01-15 20:33 +0100
    Re: Using sessions and cookies bob <bob@coolfone.comze.com> - 2013-01-15 13:07 -0800

#2818 — Using sessions and cookies

From
http://www.larryullman.com/2010/01/07/custom-authentication-using-the-yii-framework/:

Now, by default, Yii will use cookies for authentication. In most
situations that’s fine, but if anything of a sensitive nature is
being stored, you should use sessions instead. This would apply
to both the user’s ID value and their role. If either is
available through a cookie, it wouldn’t be hard for the user to
edit that cookie’s value in order to become someone else. So, to
start, let’s disable the potential for using cookies.

My question: Is it OK to use cookies for:
1. storing session IDs?
2. storing username and password?

Larry speaks as if using cookies and using sessions would contradict
to each other. But what about the combination (1. above) to use
cookies with session IDs?

-- 
Victor Porton - http://portonvictor.org

[toc] | [next] | [standalone]

#2819

* Victor Porton wrote in comp.programming:
>From
>http://www.larryullman.com/2010/01/07/custom-authentication-using-the-yii-framework/:
>
>Now, by default, Yii will use cookies for authentication. In most
>situations that’s fine, but if anything of a sensitive nature is
>being stored, you should use sessions instead. This would apply
>to both the user’s ID value and their role. If either is
>available through a cookie, it wouldn’t be hard for the user to
>edit that cookie’s value in order to become someone else. So, to
>start, let’s disable the potential for using cookies.

This does not seem to be a suitable resource to learn about the security
properties of various online authentication schemes. Note in particular
the preceding paragraph with the example of storing a "SHA1()-encrypted
version of the user’s password". SHA-1 is a cryptographic hash function
and no encryption scheme, and it is rather unsound to store bare hashes
of user passwords; even as an example it is rather misleading because it
does not offer any notable advantage over storing the plain password.

Further, I note that such tutorials are often written using the termino-
logy of the framework being employed, so I am not sure what is meant by
"Yii will use cookies for authentication" without further context.

>My question: Is it OK to use cookies for:
>1. storing session IDs?
>2. storing username and password?

The important thing to note is that cookies are sent over the wire all
the time, anything "stored in a cookie" is part of every request to the
server. If, for instance, an attacker can observe what the victim is
sending to the server, then sending username and password with each and
every request would make it a lot easier for the attacker to know them;
that can be more problematic than the attacker obtaining a session iden-
tifier because the user might use the password on other sites, or it may
be a long time before the user changes the password, while the session
identifier might expire quickly, so the attacker would have more time to
conduct an attack. So passwords in cookies are worse than session iden-
tifiers.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[toc] | [prev] | [next] | [standalone]

#2820

On Tuesday, January 15, 2013 11:37:20 AM UTC-6, Victor Porton wrote:
> From
> 
> http://www.larryullman.com/2010/01/07/custom-authentication-using-the-yii-framework/:
> 
> 
> 
> Now, by default, Yii will use cookies for authentication. In most
> 
> situations that’s fine, but if anything of a sensitive nature is
> 
> being stored, you should use sessions instead. This would apply
> 
> to both the user’s ID value and their role. If either is
> 
> available through a cookie, it wouldn’t be hard for the user to
> 
> edit that cookie’s value in order to become someone else. So, to
> 
> start, let’s disable the potential for using cookies.
> 
> 
> 
> My question: Is it OK to use cookies for:
> 
> 1. storing session IDs?
> 
> 2. storing username and password?
> 
> 
> 
> Larry speaks as if using cookies and using sessions would contradict
> 
> to each other. But what about the combination (1. above) to use
> 
> cookies with session IDs?
> 
> 
> 
> -- 
> 
> Victor Porton - http://portonvictor.org

This is an interesting problem.

I believe both 1 and 2 might be feasible if you just use HTTPS.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web