ok, so lets say I hash the username then store the hash in the cookie. then lets say when i want someone to read that cookie, i tell them how i hashed it or whatever. is that better? as for sessions, it won't work with that I'm trying to do AFAIK. how to you maintain a session across different machines that have different hostnames that are written in different languages? not that it wouldn't rule, but jeff and i were chatting about it on the phone and didn't think it could be done very easily.. unless someone else hasa better idea or some insight that we didnt thanks for the reply though :) .djc. "Warden, Matt" wrote: > I mean, if you're just reading a userid out of a cookie, gimme five > minutes to whip up a PurlSkript and do a bunch of mean stuff on > thesite with your god status. > > But, if I remember correctly (becuase I'm a nut who surfs with a > browser that prompts me with whether to accept or reject every > cookie), there's some whacked hash that is stored in the cookie now. > > I just about always store username and password info in session > cookies, rather than the userid or a true/false isLoggedIn type of > thing. Then I reverify that they exist in the DB with each page that > requires a login. But, these are like 99.99% intranet management > systems for a public internet site, so extra queries aren't all that > much of a concern when only 20-25 users will be on the system each > day. > > But, the good thing about session cookies is that they aren't > (supposed to be) stored on the client computer. So, really the only > possible security issue is if Joe Schmo creates a cookie (as a txt > file or in cookies.txt depending on the browser, or in a perlscript) > and guesses the name of the cookies and also the username and > password. And, if he can do that, he can just log into the damn site > anyways.