Re: Is it secure "enough" to put login info in the session?

[ristretto.rb]

Hi Craig,

I'm considering something like this

Trigger:  User comes to site for the first time
1.  User requests to be a guest
2.  system creates a guest User with randomness for username and
password, authenticates and logs in the user, also sets a cookie in
the browser with the id of the Guest User.
3.  User has full access to the site, however some features will be
limited.


Trigger:  User returns to site
1.  User requests to be a guest, and expects to see the data created
in the first session
2.  System checks cookie in browser for an ID, if one is found, find a
matching Guest User, auth and login
3.  User continues to us the site

If the user tried to log in as a guest from another computer, they
will, of course, not see they're information.  In fact, they will see
the information that was saved, if a guest was every created on that
machine.  I'm not too worried about that at this point.

I'm just working through when Django saves a cookie, and I think this
will work.

Gene





On Sep 9, 5:54 pm, Craig McClanahan  wrote:
> On Tue, Sep 8, 2009 at 10:20 PM, ristretto.rb wrote:
>
> > Hi
>
> > I want to have a guest concept.  You get instant access to my app.
> > There are limits.  But, you will be allowed to come back multiple
> > times before I require you to register.
>
> How do you plan to tell if the guest "came back"?  The only reasonable
> mechanism I can think of is to use a session cookie (you can't rely on
> things like IP address ... like most folks with a home router, all the
> computers in my household will appear to have the same IP address to a
> service we contact, and the same would be true for most business
> situations).  And even if you rely on a session cookie, your
> restrictions are easily bypassed by the user who simply clears their
> cookie cache.
>
> Until you can solve this problem reliably (good luck!), the
> implementation details are not really worth thinking about.  But
> things like using a session cookie are no more or less secure for this
> use case than they are for the usual approach to keep a user logged on
> to a web app, other than the fact that you'd probably need to keep
> your session alive a lot longer.
>
> Craig
>
> PS:  The typical solution I've seen for a "guest" concept is to offer
> only a limited subset of the overall functionality to non-registered
> users, with lots of teasers about "if you would only bother to
> register, you could do FOO and BAR and BAZ!".  Example:  ESPN's web
> site has a bunch of "freely available" stories accessible to anonymous
> users, but the (presumbably) good stuff requires a login.  Figuring
> out the balance point is a challenge -- for me, for example, I'm not a
> fantasy football junkie, so the extra subscribers-only analysis
> doesn't have enough value for me to bother to register (or pay, as the
> case may be).
>
>
>
> > When a user comes in as a guest, I will create a user with a bogus
> > username, password and email, and put  the user_id in the session, so
> > that when the user comes back I can read it and restore saved state.
>
> > I'm mildly concerned that it's unsafe to put the user_id in the
> > session.  I can imagine a hacker faking that somehow, and getting
> > access to other guest accounts.  I'm not sure the risk is that big,
> > and once users register, the risk goes down.  But, I'm wondering if
> > this is at all foolhardy.  Is there a better way to approach this?
>
> > Perhaps a hash key or something that isn't sequentially too
> > guessable.  Or some encryption.
>
> > This guest concept has inherent security issues with shared computers:
> > labs, cafes, etc.  The user will made aware of this when logging in as
> > Guest.  Also there will be no sensitive or private data in this guest
> > account that if seen by another user would make much difference.
>
> > Thanks for any insight
> > Gene
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Is it secure "enough" to put login info in the session?

[Craig McClanahan]

On Tue, Sep 8, 2009 at 10:20 PM, ristretto.rb wrote:
>
> Hi
>
> I want to have a guest concept.  You get instant access to my app.
> There are limits.  But, you will be allowed to come back multiple
> times before I require you to register.

How do you plan to tell if the guest "came back"?  The only reasonable
mechanism I can think of is to use a session cookie (you can't rely on
things like IP address ... like most folks with a home router, all the
computers in my household will appear to have the same IP address to a
service we contact, and the same would be true for most business
situations).  And even if you rely on a session cookie, your
restrictions are easily bypassed by the user who simply clears their
cookie cache.

Until you can solve this problem reliably (good luck!), the
implementation details are not really worth thinking about.  But
things like using a session cookie are no more or less secure for this
use case than they are for the usual approach to keep a user logged on
to a web app, other than the fact that you'd probably need to keep
your session alive a lot longer.

Craig

PS:  The typical solution I've seen for a "guest" concept is to offer
only a limited subset of the overall functionality to non-registered
users, with lots of teasers about "if you would only bother to
register, you could do FOO and BAR and BAZ!".  Example:  ESPN's web
site has a bunch of "freely available" stories accessible to anonymous
users, but the (presumbably) good stuff requires a login.  Figuring
out the balance point is a challenge -- for me, for example, I'm not a
fantasy football junkie, so the extra subscribers-only analysis
doesn't have enough value for me to bother to register (or pay, as the
case may be).

>
> When a user comes in as a guest, I will create a user with a bogus
> username, password and email, and put  the user_id in the session, so
> that when the user comes back I can read it and restore saved state.
>
> I'm mildly concerned that it's unsafe to put the user_id in the
> session.  I can imagine a hacker faking that somehow, and getting
> access to other guest accounts.  I'm not sure the risk is that big,
> and once users register, the risk goes down.  But, I'm wondering if
> this is at all foolhardy.  Is there a better way to approach this?
>
> Perhaps a hash key or something that isn't sequentially too
> guessable.  Or some encryption.
>
> This guest concept has inherent security issues with shared computers:
> labs, cafes, etc.  The user will made aware of this when logging in as
> Guest.  Also there will be no sensitive or private data in this guest
> account that if seen by another user would make much difference.
>
> Thanks for any insight
> Gene
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Is it secure "enough" to put login info in the session?

[ristretto.rb]

Hi

I want to have a guest concept.  You get instant access to my app.
There are limits.  But, you will be allowed to come back multiple
times before I require you to register.

When a user comes in as a guest, I will create a user with a bogus
username, password and email, and put  the user_id in the session, so
that when the user comes back I can read it and restore saved state.

I'm mildly concerned that it's unsafe to put the user_id in the
session.  I can imagine a hacker faking that somehow, and getting
access to other guest accounts.  I'm not sure the risk is that big,
and once users register, the risk goes down.  But, I'm wondering if
this is at all foolhardy.  Is there a better way to approach this?

Perhaps a hash key or something that isn't sequentially too
guessable.  Or some encryption.

This guest concept has inherent security issues with shared computers:
labs, cafes, etc.  The user will made aware of this when logging in as
Guest.  Also there will be no sensitive or private data in this guest
account that if seen by another user would make much difference.

Thanks for any insight
Gene


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---