Well, shamefully I've searched this topic and found answers that say it can't be done. I'm going to ask the question again, knowing I'll get the same answer, but expecting something different. I'm sure I read somewhere that this is a definition of insanity, but here goes anyway...
I have a web based application (written in perl of course). It uses a simple user login scheme to generate a unique session id which is used by the client until the user logs out (or the session times out). Nothing special there.
If a client attempts to run the application with an unknown or expired session id, the client ip is placed a penalty box for a timeout (no login allowed during the timeout). If the client attempts to login with an invalid password (no session id), the client ip is placed in a penalty box for a timeout. If the same client ip attempts to run the application during the timeout, not only do they get refused, but the timeout gets extended, exponentionally (4 seconds, then 8 seconds, 16, 32, 64, etc). This appeared to be reasonable approach to prevent brute force attacks of either the login/password or session ids and works very well when each client has a unique ip.
Recently this approach hit a little snag. A number of the users were sitting behind a nat router and thus appeared to the application as the same ip (many of you are probably already chuckling). Things worked fine until one of the user session ids expired. When this client tried the application (after expiry), the ip was sent to the penalty box - 4 seconds. At the same time other users continued to use the application (with their perfectly good session ids), but the ip was now blocked, so the application dutifully refused each user request and upped the timeout with each request as well. More users found the application wasn't working and before you know it, that particular ip (and all the users behind the router) were blacklisted for 6 hours and growing.
This scenario is likely to be common (and unacceptable) for the application. I've wracked my brains and searched till my fingers bled, but I just can't see the logic to get out of this. The users are trusted and co-operative, so if there's a way they can set something in their browser to distinguish themselves (they're nearly all running personal laptops) then this could be used as a solution (blacklist ip plus some other client provided data). Not perfect, and not 100% secure, but reasonable for the usage.
Perhaps a cookie intervention might save the day? If I tie a random value to a session id and save it with a client cookie is that any more secure? (I can require users to have cookies enabled). Or is a cookie no different than the original session id? What's to stop an attacker from forging up cookies?
My worst case option at the moment is to have an ip whitelist built into the application to not block attempts from particular ips (trusted router networks). I'd like to avoid this if possible.
Any sane or insane ideas on how to handle this problem? I don't need a department of defense strength solution here!
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.