[4579] in WWW Security List Archive
Re: Removing info from a PC cache
daemon@ATHENA.MIT.EDU (Darren Cook)
Tue Feb 25 05:05:00 1997
To: www-security@ns2.rutgers.edu
From: darren@factcomm.co.jp (Darren Cook)
Date: Tue, 25 Feb 1997 16:26:27 +0900
Errors-To: owner-www-security@ns2.rutgers.edu
An update on people being able to use other people's accounts because their
passwords are still in the cache.
I tried both "Expires: <Old GMT date>\n" and "Pragam:no-cache\n", and they
both seem to do the same thing. So I am using the Pragma, as it is simpler
(you put them in the cgi-header, eg. just before you do "Content-Type:
text/html\n\n").
Now when I click BACK, it still works okay, until I get back to the first
page after the password form. It says "results of a POST operation are not
in the cache". But if I click reload, it asks me if I want to repost the
form. I say OK, and I am back in again!
So I tried the idea of embedding the time I gave them the password form, and
making sure that it is later than the last logon they did (I've repeated my
original message below). This worked - when I click reload, it tells them
their session has expired, and they must log on again.
I've used it in combination with "Pragma:no-cache", so it should now be safe
if used in Internet Cafes, etc. Even if someone could hack into the cache.
NB. the session lasts 30 minutes from their last web access, and the links
that only use GET work until the session expires. A 'change my password'
option would also therefore work. But as long as I require them to give the
old password if they want to change their password, this should be okay.
Can anyone see any flaws in the above system?
Darren
PS. This works under Netscape 3.0, and Explorer 3.0.
------------my previous message--------------
Good point. I did not think of them using BACK to go as far back as the
initial password form.
How about this:
1.I know the time&date of their last web access, which is after they
submitted the password form.
2.When I give them the password form, include a hidden with the current time.
3.If they try to submit a password form which has a time earlier than their
last access, ignore it (and send back a fresh password form :-).
A clever hacker could go directly into the cache and get the password out,
and log in the normal way. I cannot see any way round this last one.
