Re: [WebDNA] Secure Cookies
This WebDNA talk-list message is from 2009
It keeps the original formatting.
numero = 103885
interpreted = N
texte = > I have a system where someone logs in with a user and pass, and > webdna checks a user database. If they are a member, they get a > cookie named status with a value of current. This lets them into the > member area. Anyone can see the name and value by looking at their > cookies in the browser settings. So is this a bad idea on my part? > The wiki article was somewhat over my head. > > Terry I wrote my cookie-based log-in system so that: - when user logs in, i.e. inputs his usr/pass via HTML form, then it checks those against db values (pass is encrypted).. - if valid, then usrID (cart#) cookie is set matching the value for user's ID (cart#), and sessionID (another cart #) cookie is also set, and this same sessionID is written to this user's db record. Also [replace]ed in this record is the date and time of last log in. Any time a login or protected-page check fails for any reason (like timed out, or bad pass), then those cookies are reset to "logged out". on every protected page: - search for a record in the user db whose: userID matches that first cookie, sessionID matches the second cookie, datelastloggedin matches today, timelastloggedin is less than 30 mins. They can hack their cookie sheet all they want.. they would have to guess the user's unique ID (cart#) and also the sessionID (another cart #) in that same user's record.. and which is only valid for 30 mins. Sure SSL would add more protection, not to mention encrypting ([url]- encoded) the cookie values.. But I think Bill was right that you want to build your system so that it is not so hackable in the first place as to simply require changing one cookie value to a static/consistent "current" - for any and all users. ------------ Govinda govinda.webdnatalk@gmail.com > > On Sun, 25 Oct 2009 23:55:24 -0400 > William DeVaul
wrote: > > It can be easy depending on countermeasures in place. > > > > http://en.wikipedia.org/wiki/Session_hijacking > > > > One super easy way is to store user credentials in the > >cookie. For > > example, if after logging in as "bill" to a web site, a > >cookie with > > the user name "bill" is stored on the client so that the > >server > > remembers me as "bill" on subsequent requests, the > >client could read > > the cookie and change the credential to "jim." This > >problem is not > > solved by the use of SSL but by not storing user > >credentials in the > > cookie such a manner that they can be easily modified. > > > >For this reason, it is highly recommended to encrypt data > >in the cookie. > > > > Bill >
Associated Messages, from the most recent to the oldest:
> I have a system where someone logs in with a user and pass, and > webdna checks a user database. If they are a member, they get a > cookie named status with a value of current. This lets them into the > member area. Anyone can see the name and value by looking at their > cookies in the browser settings. So is this a bad idea on my part? > The wiki article was somewhat over my head. > > Terry I wrote my cookie-based log-in system so that: - when user logs in, i.e. inputs his usr/pass via HTML form, then it checks those against db values (pass is encrypted).. - if valid, then usrID (cart#) cookie is set matching the value for user's ID (cart#), and sessionID (another cart #) cookie is also set, and this same sessionID is written to this user's db record. Also [replace]ed in this record is the date and time of last log in. Any time a login or protected-page check fails for any reason (like timed out, or bad pass), then those cookies are reset to "logged out". on every protected page: - search for a record in the user db whose: userID matches that first cookie, sessionID matches the second cookie, datelastloggedin matches today, timelastloggedin is less than 30 mins. They can hack their cookie sheet all they want.. they would have to guess the user's unique ID (cart#) and also the sessionID (another cart #) in that same user's record.. and which is only valid for 30 mins. Sure SSL would add more protection, not to mention encrypting ([url]- encoded) the cookie values.. But I think Bill was right that you want to build your system so that it is not so hackable in the first place as to simply require changing one cookie value to a static/consistent "current" - for any and all users. ------------ Govinda govinda.webdnatalk@gmail.com > > On Sun, 25 Oct 2009 23:55:24 -0400 > William DeVaul wrote: > > It can be easy depending on countermeasures in place. > > > > http://en.wikipedia.org/wiki/Session_hijacking > > > > One super easy way is to store user credentials in the > >cookie. For > > example, if after logging in as "bill" to a web site, a > >cookie with > > the user name "bill" is stored on the client so that the > >server > > remembers me as "bill" on subsequent requests, the > >client could read > > the cookie and change the credential to "jim." This > >problem is not > > solved by the use of SSL but by not storing user > >credentials in the > > cookie such a manner that they can be easily modified. > > > >For this reason, it is highly recommended to encrypt data > >in the cookie. > > > > Bill >
Govinda
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
New Cart No. on same page (2003)
Single Link browsing (1997)
'does not contain' operator needed ... (1997)
WebCatalog2 Feature Feedback (1996)
Formating found categories (1997)
Math Problem - Format? (1997)
secret [cmd] variable? (2004)
[WebDNA] Has anyone used WebDNA as the back end to an app from end? (2016)
javascript popup (2005)
Generating Report Totals (1997)
customer info (2001)
OS X problem: when using [ShowCart] or [orderfile]... (2000)
Encrypt (2000)
Grep -Replace with nothing (2003)
WebCat2 - Getting to the browser's username/password data (1997)
Web Catalog 2 demo (1997)
Don't tick me off :) [elaspedtime] (1997)
[protect] error page (1997)
RE: E-mailer error codes (1997)
user flush db (2002)