Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
Login delay
Question: why do we subject all user-submitted login requests to a 3-second delay before checking if it’s valid? It slows down valid attempts, when all we really should be doing is trying to slow down invalid attempts to annoy brute-forcers.
Could we get away with perhaps sleep(1) before the validation begins and — only if validation fails — do a further sleep(2)? Or does the enforced sleep(3) prior to running any validation code protect against some kind of attack I can’t think of right now?
From what I can gather, the PHP sleep() function is interruptable by other threads so it’s conceivable that a process running on the same box (in a badly-configured shared hosting environment, perhaps?) could short-circuit the existing sleep command. Splitting the sleep into two would mean an extra hoop to jump through in these edge cases. Ummm, I think. But my security knowledge here is somewhat lacking. Anyone give me any compelling reasons to keep the single 3-second sleep instead of splitting it?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Login delay
I don’t see any reason why the sleep command could not be moved to after an unsuccessful login attempt. No need to split it. The sleep won’t affect other processes on the box – only the process executing the login attempt.
Offline
Re: Login delay
artagesw wrote:
No need to split it.
Thanks Sam. I did wonder about this too and tried it out, but you know what, it just feels wrong not to have that moment where your details are “being checked”.
I’m not sure what it is, but people seem to be cognitively accustomed to the login process taking time. Perhaps it adds confidence to the proceedings or something? Three seconds is annoying, but I find that going straight into the interface without a delay almost seems ‘cheap’; like TXP’s not trying hard enough to take my security seriously. At least it feels that way to me: perhaps I’m alone here and I’ll get used to it :-)
I’ve done cognitive UI studies in the past (gotta love Universities!) and it always surprised me the way different people responded to interfaces. For instance, most didn’t mind — almost expected — some tasks to take time and didn’t believe something happened if it was too quick (clicking again to make sure). But most were universally annoyed if something took longer than expected, and tended to click again and again if there wasn’t adequate feedback.
So I simply don’t know. I’m quietly convinced it doesn’t impact security either way — someone more knowledgeable than me can hopefully vouch for this view. Try it out with zero delay and see what your initial reaction is. Then try 1 second (or even usleep(500000) for half a second) and see if it changes you perception. Like I say, it may just be me and everyone would prefer no delay at all.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Login delay
I don’t think splitting the delay adds anything besides yet another “WTF” moment for code reviewers. If some people feel comfortable with their software if it makes them wait, I’d advise them to look for another toolset.
Moving the delay into the “invalid credentials” code path is a sensible suggestion, I think.
As it goes for the possible fallout, DoS attacks would then exhaust CPU cycles instead of httpd threads as they do now. Pick your poison.
Offline
Re: Login delay
wet wrote:
I don’t think splitting the delay adds anything besides yet another “WTF” moment for code reviewers
Fine by me. I’ll live with my cognitive dissonance :-)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Login delay
As a simple “user” I would be happy to get straight to work trusting that the devs know what they are doing. 3 seconds is neither here nor there but I certainly wouldn’t miss them.
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: Login delay
wet wrote:
I don’t think splitting the delay adds anything besides yet another “WTF” moment for code reviewers. If some people feel comfortable with their software if it makes them wait, I’d advise them to look for another toolset.
I agree.
Offline
Pages: 1