Home Log In or Register Forums

Security Loophole

Home > Forums > Burninghorizons Development > 'Security Loophole'
'Security Loophole'
Page: [1] [2]
richard's user image
richard
06.03.2003 - 09:40
forum administrator
Nelson,

I have been going through the way we keep track of users, i.e. through the use of cookies, and have found that it would be possible to gain access to a user account by intercepting the transmission of the cookie.

As an example, do the following: Log in to BH (if you're not already), go to File > Import and Export, then go through the wizard to export your cookies. Trim that file to remove any cookies not relevant to BH, then in your Temporary Internet Folder, delete your BH cookie. Hit refresh on your browser, and note that you are no longer logged in. Next, go through the import procedure, then hit refresh again. You are now logged in, as you would expect.

Someone clever enough to intercept that cookie during transmission would be able to import the cookie as just done, then gain access to your account.

They wouldn't have any sensitive information such as your password, since that's not stored anywhere, so they would only be able to gain access temporarily. This would mean that they could make phoney posts and worse if they happened to intercept an administrators cookie.

On the plus side, I have been going through the PHP documentation and there are some very useful tools to do with SESSION variables, which I don't think can be used to gain access to the system, since the internal mechanisms of the functions protect against that...
richard's user image
richard
06.03.2003 - 09:40
forum administrator
The only downside with that is that closing Internet Explorer would close the session, meaning that you'd have to re-enter your password again.

Comments?

Rich
-rob-'s user image
-rob-
06.03.2003 - 11:11
Um, when we log on we are sending plaintext passwords to the web server as its not using SSL. So why are you worried about people stealing cookies over the wire when they can easily get the passwords? :P
richard's user image
richard
06.03.2003 - 12:41
forum administrator
Actually, plaintext passwords are NOT sent. I devised the following algorithm:

1) Take password and generate pseudo-password (a hash function of the password)

2) XOR that with a random-key sent from the server.

3) Take a checksum of that value and send it to the server.

4) The server has the pseudo-password stored in the database and XORs it with the random-key used, then if the checksums match, the user is logged in.

:oP~~~~~~~~~~~~~~~~~
richard's user image
richard
06.03.2003 - 12:45
forum administrator
p.s. feel free to look at the source code!

Pick holes if you can find them!

(and yes, we know about the registration form weakness, maybe you can think of a better way of getting the pseudo-key to the server securely?)
richard's user image
richard
06.03.2003 - 12:47
forum administrator
p.s... that wasn't meant to sound sarcastic, if that's how you interpreted it! I am genuinely interested if you know of a better way? (Obv. SSL)
nelson's user image
nelson
06.03.2003 - 13:48
forum administrator
Rich - I know it's possible to intercept or steal cookies. That's why the server logs a new "session key" for each page request per logged user. That key must be returned when requesting the next page for you to remain logged in. So, if someone steals and uses your cookie, then -

a) they have to do it before you request another page, since that would invalidate the stolen cookie's key

b) if anyone tries to use an "invalid key" cookie, it will automatically invalidate that user's session ("your session has expired").

c) even if the stolen cookie's key is still valid, when the original user requests a page it will invalidate them both.

d) only the original user will have the password to re-login

However, there might be a weakness that will cause a stolen, "invalid key"-cookie, to repeatedly invalidate the legitimate user. Will think about that one...

Don't like SESSION variables... they log you off all the time! I'm using them in ASP at the moment in a different project at work.
-rob-'s user image
-rob-
06.03.2003 - 14:49
bahh....

Can't beleive I didn't bother to actually check before saying that *sigh*

wheres that edit facility?? <removes foot from mouth>

You could use pgp/gpg to get the secret to the server initially. Dunno if any of you use it though.
richard's user image
richard
06.03.2003 - 15:23
forum administrator
Yeah, I know all about points a-d, but was just concerned about a), that's all.

Was thinking about your point after d) too, and this whole thing might be resolved by storing the users' IP address?

If both the IP address and session key are correct, then it's ok.

If session key is ok, but different IP, then either someone's possibly trying to break in, or a dial-up account has had to redial. Either way, force a re-login.

If IP is ok, then something went wrong with the user browsing the site (i.e. pressed F5 twice). Not sure what you want to do here? Can keep the same as it currently is, i.e. expire them.

If neither are correct - who the hell are they trying to kid?!

What do you think?
richard's user image
richard
06.03.2003 - 15:24
forum administrator
Funnily enough, did think of using PGP, but then thought 'eek', since the maths for that is not nice :o(
Page: [1] [2]

This discussion is now closed and you cannot add to it.

contact us © 2003, 2004 BurningHorizons.net