Re: Authentication

Richard Lynch wrote:

Another thing some people use to strengthen their security model is to involve some sort of sequence number in the data that the client sends back. For example, instead of just a session ID, perhaps you have a cookie, URL variable, or whatever that is an encrypted (two-way so you can decrypt it) session ID, sequence number, and anything else you might think of to include. When you decrypt this at the beginning of each script, you make sure the sequence number is not less than the last sequence number sent (which you store on the server),

Unfortunately, that will break the "Back" button :-(

This is not entirely correct, though it does present a good case for using cookies rather than a URL variable. Using the back button will do one of two things: 1. Present the user with the cached version of the previous page 2. Resubmit the request for the previous page In case #2, you would only run into a problem if you chose to use a URL variable for the encrypted string containing the sequence number. When cookies are used, it makes absolutely no difference, which I think should be pretty clear. There are creative ways around the use of a URL variable for this as well to lessen or nearly eliminate the potential impact to the legitimate user. For example, you could allow a small tolerance, such as allowing the sequence number be either the current expected one or one less. This would only cause problems in case #2 when URL variables were used *and* the user goes back more than one page at once (using the back drop-down, for example). Even then, "break" can just mean resubmitting the password, which is very little hassle for a rare situation. Balancing usability with security is the whole game. Happy hacking. Chris