On Thu, 2002-07-04 at 03:54, Steve Freitas wrote:
> >>> 2) If you use your browser's BACK button to go back to the login form, then
> >>> re-post the user name and password, it will always fail to log you in. This
> >>> is by design. A unique random ID (I think it's called "loginid") is
> >>> generated in a hidden variable in the login form and also saved in the
> >>> session, then it is only allowed to be used once after which it is erased
> >>> from the session. I put this in for security reasons, so somebody couldn't
> >>> log out, then have some nefarious individual go up to their machine and use
> >>> the BACK button to go back to the login page, re-POST it, and therefore get
> >>> logged back in without having to know the user name and password.
> >> "Unnecessary paranoia?" In computer security, there is no such thing.
> > True. What I meant is, maybe it just appears to add extra security, but
> > doesn't in fact really do so.
> Can we explore this topic? I haven't thought about this for a while because
> I need to understand the scenario better.
> What we've got here:
> - A cached username and password in the user's browser
> - A changing loginid
> - The inability to use the back button without logging in again
> Whether your countermeasure adds security depends, I suppose, on the
> motivation of the attacker. If s/he's willing to search browser memory for
> the username and password (I assume there are slick tools for this), then
> the loginid doesn't help. (Aside: Would a tcpdump do the same? Does the
> browser send the user/pass to every page?) However, since the idea with
> security is to get the thieves to rob your neighbors instead of you, I think
> your method is very useful, as it discourages casual hacks.
> What would be interesting is if we could keep the loginid stable for the
> session, but expire it when a) The user logs out, b) The session expires due
> to inactivity, and I suppose a corner case might be c) The user's SID no
> longer matches (because the browser was closed, then reopened, and it has
> mad user/pass caching skillZ).
This is easy to do. SecurePage stores the login id in the session, but
clears it immediately upon login. All you'd have to do is not clear the
login ID upon login but instead leave it in the session where it can be
reused. The session expiration code and logout code will take care of
the rest automatically.
I'm still not sure if this compromises security somehow. I have to give
it some more thought.
> I don't understand Webware too well yet, so I'm sure I'm missing things, but
> I'm trying to see if we can keep loginid intact until certain events take
> place, and only then let slip the dogs of /dev/random.
> I'm also wondering why Amazon.com does the same thing. Use of the back
> button during the order process will cause you to start over, if I remember
> correctly. Given how customer-centric they are, I'd think they'd solve that
> if they could, so there may be A Very Good Reason behind it.