Secure State Maintenance

[George_Sherston]

Each time a user goes to a new page in my CGI-based site, the script calls up a big lump of info about this session from a db. What I plan to do is, for a properly logged-on user, send with each page a field containing a randomly generated string. When that string gets submitted, the script checks it against the db; if there is a match, it pulls out the info, and then changes the random string and sends back the new string. If there is no match, then I know that this is not a logged in user.

I have a few questions about this:

Am I right in thinking this is more secure that htpasswd (if done properly) in that each "password" only exists for a single transaction in the session - my limited understanding, which may be wrong, is that this makes it harder to sniff than $ENV{'REMOTE_USER'}.

Is there any advantage in encrypting the random string? - it seems like there must be, but given that each string only gets used once, I can't see that it's any harder to spoof when unencrypted.

Assuming I shd encrypt it, what's your recommended encryption module - there seems to be a bewildering array of them in CPAN

In generaly, am I barking up the wrong tree (or just plain barking) with this? I'm pretty ignorant abt security, so please don't refrain from telling me something because you think I'll already know it!

Many thanks, sibling monks.

§ George Sherston

[perrin]

And what if the user hits back and then submits an older one? Will you be keeping the old ones in the db for a certain amount of time? Doesn't sound so secure to me.

The right way to ensure that client-side data has not been messed with is to use a message digest. This is described quite nicely in the free chapter from O'Reilly's CGI book.

[George_Sherston]

Good point. I had intended to delete each one as I create a new one. But then if somebody hits the back button... he gets treated as logged out. So it IS secure... in much the way as locking the doors of your shop stops people stealing from it. Huh. Glad I asked. Thx

§ George Sherston

[hatter]

Going through the points in order, yes I think your system is more secure than .htaccess over a non-ssl link, because htaccess sends the details in plaintext and those details will work perpetually. The rest of your system may or may not introduce errors which make it less secure, but I don't think that's part of this discussion.

The only gain I could see from encrypting the string is that it will make it more difficult for someone to figure out the algorithm that is used to generate the pseudo-random string.

While you're looking for possible modules to encrypt it though, I'd suggest that you pass over them and head straight for something like Apache::Session::* as a complete solution already checked for problems by someone else.

the hatter

[thraxil]

no, this is really not any more secure than http authentication (not that that's saying much).

if Eve is watching the transactions, all she has to do is take the random string out of the page that you send and send it back to you with some bogus data. she just has to do it before the legitimate user hits submit. yes, you prevent her from learning the user's password and using at a later date but that's about it. (although if she can sniff the connection, she could probably just grab it at an earlier stage when you first authenticate so it doesn't matter much)

encrypting the random string won't make any difference. a good encryption algorithm will effectively just turn one random string into another random string.

if you are worried about sniffing, stick with SSL.

anders pearson

[Ryszard]

My take on the best method of security is context. I reckon one of the better methods is similar to what you suggest.
• Issue the user with a non-determinate token (sess_id) in a cookie, with a timeout value (5mins, 15 mins etc)
• Stick the sess_id in a database along with the user that owns it.
• For each pageview, get the cookie value, and check it against your database.
• If the cookie expires but the session is still active, set another cookie, with a different value and extend the session.
• Make sure you include a logout function which will purge the record from the database.

  IMO there is no need to use crypto, save for md5, or sha1, which you could use to generate the sess_id, (seeded by the pid, time, rand and username perhaps). If you're going to have a high transaction site, you may as well use md5 (or sha1) because, its easy, and the chance of a collision is amazingly small.

  There are of course prebuilt things out there, however, I chose to write my own because it was fun and taught me a lot.

  For added security, add a dash of https, and run your sessions over it.

  Check out this node for a thread on sessions management without cookies, and here for a bit of light reading on secure session management.

[rrwo]

Uh oh. You said:

I'm pretty ignorant abt security, so please don't refrain from telling me something because you think I'll already know it

First rule is to keep it simple. Then the security is easy to evaluate. If you don't understand whether doing something will make it more secure, then don't do it. Because it probably won't.

That said...

Read up on security before you implement any algorithms, protocols, etc. Otherwise you'll make some glaring holes amidst all the hoopes you jump through. A good start for crypto and protocols is Applied Cryptography by Bruce Schneier. But that's only a start..... search the web for articles on CGI and security. There are plenty.

In the meatime, look at what other people implementing similar applications have done, and if there is any code available that has been around for a while, evaluated/tested/hacked enough that the "community" has a reasonable amount of confidence in it's security.