prevent multiple login from different IP on membership artcile / blog

Thanks

Liu’s paper is nonsense as well.

1.) It states clearly that the most prominent vulnerability for replay attacks in Fu’s protocol (the one they purportedly deprecate) is an attacker obtaining the SSL Session key via various methods (albeit not simple ones), but then goes on to state that their ‘fix’ for this issue was simply to include the SSL session key in the HMAC of the cookie, which is useless fluff if the attacker can obtain the SSL session key (as they state is a very real possibility just a paragraph before). See section 2.3 (Problem II: Replay Attacks) in Liu’s paper.

2.) SSL Session keys can, and do, get re-negotiated at arbitrary times both by the client and the server, rendering this nearly useless as an authenticated session scheme. The client will effectively be logged off for (as far as he/she knows) no apparent reason and at random times. Setting a higher cache/timeout times for the keys in Apache or similar will also be ineffective because that is simply a top-shelf suggestion, and not a static timeout requirement.

As for tying a cookie to an IP address, that is simply idiotic. Not only are IP addresses incredibly simple to spoof, many (if not a huge) amount of legitimate users are routed through rotating proxies, NATs, gateways, et al. Not to mention TOR users (or similar) who’s IP address will change with nearly every request.

An IP address is not a unique identifier, nor is the User Agent string. They can not be relied upon.

Frankly, nearly any attempt to ’secure’ a cookie-based authentication scheme against replay attacks is moot. The flaw is in the protocol itself, it’s stateless. Until there is a way for a client to sign or alter their cookies in some way prior to being sent to the server, there will always be holes in any cookie-based authentication scheme. Using SSL is a step-above, but still just as vulnerable. The cookies are stored in the clear on the user’s hard-drive, so SSL-only cookies simply prevent (well, not ‘prevent’, simply increase the difficulty of) man-in-the-middle attacks.

Sorry to say it, but your scheme is about as naive as they come. Which isn’t to say that there are many better solutions, but don’t think you’re fireproof or something. Your scheme is a script-kiddies dream, even more so when you mistakenly think that it’s somehow secure.