Re: [WebDNA] Encode cookies ONLY via "method=Base64"
This WebDNA talk-list message is from 2008
It keeps the original formatting.
numero = 101283
interpreted = N
texte = > What about just creating a new field in your user table > called hiddenval. Then when a person logs in, write a > cookie with a random number and set that field to the > same number for the logged in user ... Now that you mention this I remember that this is what I did with some site I worked on years ago. Thanks for reminding me, it's been so long that I almost forgot about it completely! Here's how I guaranteed that the new value was absolutely unique (not random): Inside a loop that iterates 1000 times, I set a text variable to a new and theoretically unique value, such as string created by using 5 or 10 [random] tags concatenated together. After the new value is created I do a [lookup] for it in the "hiddenval" field of my members.db. If the new value does not exist I [break] the loop (this usually occurs after the first iteration) and then I write the new and unique value to the "hiddenval" field of that user's db record. If the newly created value already exists the loop tries to create and check another new value, and it keeps doing this up to 1000 times before failing with an error message, so that's the reason for the loop. -------------------------- One good thing about this approach is that it never sends a login value that might be reverse engineered by a hacker. Another is that the cookie value is reset upon each request, thus limiting the time a hacker has to use it -- sometimes only a few seconds between clicks. The new unique value should be written with its own prepended expiration timestamp too. Then a separate script can check these values in the db and delete the ones that have expired. This prevents a hacker from stealing the "last request" cookie and removing its expiration so that he can login after the cookie itself was supposed to have expired. :) It still makes sense to match the ipaddress, referrer, user-agent, or even the browser's authentication user/pass values as additional security. After all, their use in conjunction with a cookie will be substantially harder to hack than a lone cookie. Sincerely, Ken Grome
Associated Messages, from the most recent to the oldest:
> What about just creating a new field in your user table > called hiddenval. Then when a person logs in, write a > cookie with a random number and set that field to the > same number for the logged in user ... Now that you mention this I remember that this is what I did with some site I worked on years ago. Thanks for reminding me, it's been so long that I almost forgot about it completely! Here's how I guaranteed that the new value was absolutely unique (not random): Inside a loop that iterates 1000 times, I set a text variable to a new and theoretically unique value, such as string created by using 5 or 10
[random] tags concatenated together. After the new value is created I do a
[lookup] for it in the "hiddenval" field of my members.db. If the new value does not exist I [break] the loop (this usually occurs after the first iteration) and then I write the new and unique value to the "hiddenval" field of that user's db record. If the newly created value already exists the loop tries to create and check another new value, and it keeps doing this up to 1000 times before failing with an error message, so that's the reason for the loop. -------------------------- One good thing about this approach is that it never sends a login value that might be reverse engineered by a hacker. Another is that the cookie value is reset upon each request, thus limiting the time a hacker has to use it -- sometimes only a few seconds between clicks. The new unique value should be written with its own prepended expiration timestamp too. Then a separate script can check these values in the db and delete the ones that have expired. This prevents a hacker from stealing the "last request" cookie and removing its expiration so that he can login after the cookie itself was supposed to have expired. :) It still makes sense to match the ipaddress, referrer, user-agent, or even the browser's authentication user/pass values as additional security. After all, their use in conjunction with a cookie will be substantially harder to hack than a lone cookie. Sincerely, Ken Grome
Kenneth Grome
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:
Requiring that certain fields be completed (1997)
Bit off subject -- Faxing orders (1997)
Credit card arrangement (2005)
Newbie problem blah blah blah (1997)
hhtps to http and back? (2000)
Pull Down Search (2000)
Re[2]: Balancing randomness (2000)
Limiting user access to .tmpl files (1997)
select multiple 2 more cents (1997)
Cookies and webcat (1997)
CC: (1998)
multi-paragraph fields (1997)
There's a bug in the math context ... (1997)
WriteFile is there a max size? (1998)
For those of you not on the WebCatalog Beta... (1997)
Emailer setup (1997)
vs (1997)
DB Size - MAX (2004)
Stinkin' [Referrer] (1998)
WebCatalog for Postcards ? (1997)