5 ms·

Account gets locked just for that computer.

by obilgic 14y ago

Jach 14y ago
Oh, you mean just for that IP? Torify. Cookies? Bots don't need to accept them. Do you have something better?
- raverbashing 14y ago
  Having to wait 1s between attempts (per user) could be enough to prevent brute force attacks Of course, if one ip is making too many requests, it gets blocked or captchaed
  - morsch 14y ago
    That prevents brute force attacks against one specific account, but not against an attack against all users of a site. If you have the capability to make, say, 10k login attempts per second (no idea if that's realistic), you don't slow down to 1 attempt/second, you just attack 10k different accounts once every second. IP blocks can be countered in other ways (botnets, tor, etc). I'm not saying it's a bad idea though, there doesn't seem to be any downside apart from the book-keeping required. You could probably start with a higher delay (5 to 10 seconds seems very reasonable) and increase it to several minutes. But please don't make it 24 hours after 3 failed attempts, which happened to me when I tried to order train tickets online and forced me to make a trip to a physical ticket vending machine.
    - kattuviriyan 14y ago
      The site should have the capability to detect login attempt for multiple attempts - Show captcha Same account login attempt from multiple IPs - show captcha With the above: a simple time wait for next attempt could solve the issue for most legit attempts right?
- Xymak1y 14y ago
  How would you login without cookies anyway?
  - waterhouse 14y ago
    I believe a cookie is a datum given by the server to the client so that the client may present it to the server when making requests later. This is entirely voluntary on the part of the client; the client is free to pretend it has never received any cookies, or to present a made-up cookie (though the server would likely recognize that as suspicious). Browsers are likely to mindlessly accept cookies from servers and to obey servers' instructions as to when to present the cookies back to the server; but obviously a bot is likely to be more sophisticated, and to not present any cookies other than ones that say "You have successfully authenticated yourself as user xxx".
  - kappaloris 14y ago
    you put the session id inside the url params :3
    - neurostimulant 14y ago
      But then the session id can leak via referer header :(
      - dvhh 14y ago
        He was suppose to give a solution to parent's question, not necessary a secure one.
- hobin 14y ago
  Would it work to do that by IP, and allow only X different IPs for an account to try to login on a single day? e.g. if you've tried to login with 10 different IPs on that day, you will no longer be able to login that day. (Of course this would mean saving some extra data.) The biggest problem I see is that this means people can lock you out of your account, which is probably unacceptable.
  - Jach 14y ago
    What my bank does (and PayPal too if I remember correctly) is keep track of my IP, and if it changes then it forces me to enter additional data about my account before letting me continue. (This assumes I got the password correct.) I think one or both also may use some cookie(s) to mitigate changing IPs. They may also make use of leaky browser data (like user agent strings etc.) to help identify me; they have the potential to see a lot since I'm not trying to hide from them. I don't see anything wrong in principle with "account lock out" provided that it doesn't affect existing sessions and provided that you can just ask the site to send an email with a token to reset your password. Spammers can lock a user out, so what. Minor inconvenience. If it's happening a lot to the same user and it's also affecting the user negatively, something extra could be done to minimize lockouts for the actual user (who should be easy to detect by the server through logs and a premise the user isn't trying to hide). Spammers are able to flood you with "forgot your password?" emails, too. I don't know how often they do it. I had my first wave in after 7 years of the same email just a few months ago mostly from old sites I forgot I even had accounts on. I'm not really a fan of the exponential backoff idea proposed earlier above, I'd sooner go with the "X tries, then wait" approach. The lockout time should not be more than 24 hours, ideally less. Though one could also set the lockout period to expire when the user's session automatically expires, if there's a current one, but that may be too clever. I feel that there are really two pieces of advice to give on dealing with spammers for the general case... Advice for low-traffic sites and advice for high-traffic sites. I don't have any advice with high-traffic sites since I have no experience with spam at that level (and by high-traffic I mean thousands to millions of uniques per hour), though I don't think the status quo is good enough. With low-traffic sites spam behavior is easy to detect and create a custom solution against. Custom solutions are often better than the popular stuff just by virtue of not having anyone targeting them specifically, and even if that's the case it's still easier to cat-and-mouse if the main options against spam aren't acceptable. Something as dead-simple as loading your form with javascript (or dynamically changing the URL endpoint when the submit button is clicked to something different than what's reported by the form's html attribute...) stops a lot of bots regardless of a captcha, even though you sacrifice the Lynx users. And in my own anecdotal experience I've had more success (less spam bots getting through and leaving a message) with a captcha like "Please join these two "words" together (without spaces): taeiswovd and brhpugqc" than with ReCaptcha even though it'd take less than a minute to add a parser for mine in a bot program. I used to use an arithmetic question but even the dumb bots are on to that one these days--at least the ones after my comment boxes. (I don't even think they added, they just tried numbers 0-99 and sometimes got lucky.)

Account gets locked just for that computer.

by obilgic 14y ago

Account gets locked just for that computer.

Jach 14y ago

Oh, you mean just for that IP? Torify. Cookies? Bots don't need to accept them. Do you have something better?

raverbashing 14y ago
Having to wait 1s between attempts (per user) could be enough to prevent brute force attacks Of course, if one ip is making too many requests, it gets blocked or captchaed
- morsch 14y ago
  That prevents brute force attacks against one specific account, but not against an attack against all users of a site. If you have the capability to make, say, 10k login attempts per second (no idea if that's realistic), you don't slow down to 1 attempt/second, you just attack 10k different accounts once every second. IP blocks can be countered in other ways (botnets, tor, etc). I'm not saying it's a bad idea though, there doesn't seem to be any downside apart from the book-keeping required. You could probably start with a higher delay (5 to 10 seconds seems very reasonable) and increase it to several minutes. But please don't make it 24 hours after 3 failed attempts, which happened to me when I tried to order train tickets online and forced me to make a trip to a physical ticket vending machine.
  - kattuviriyan 14y ago
    The site should have the capability to detect login attempt for multiple attempts - Show captcha Same account login attempt from multiple IPs - show captcha With the above: a simple time wait for next attempt could solve the issue for most legit attempts right?
Xymak1y 14y ago
How would you login without cookies anyway?
- waterhouse 14y ago
  I believe a cookie is a datum given by the server to the client so that the client may present it to the server when making requests later. This is entirely voluntary on the part of the client; the client is free to pretend it has never received any cookies, or to present a made-up cookie (though the server would likely recognize that as suspicious). Browsers are likely to mindlessly accept cookies from servers and to obey servers' instructions as to when to present the cookies back to the server; but obviously a bot is likely to be more sophisticated, and to not present any cookies other than ones that say "You have successfully authenticated yourself as user xxx".
- kappaloris 14y ago
  you put the session id inside the url params :3
  - neurostimulant 14y ago
    But then the session id can leak via referer header :(
    - dvhh 14y ago
      He was suppose to give a solution to parent's question, not necessary a secure one.
hobin 14y ago
Would it work to do that by IP, and allow only X different IPs for an account to try to login on a single day? e.g. if you've tried to login with 10 different IPs on that day, you will no longer be able to login that day. (Of course this would mean saving some extra data.) The biggest problem I see is that this means people can lock you out of your account, which is probably unacceptable.
- Jach 14y ago
  What my bank does (and PayPal too if I remember correctly) is keep track of my IP, and if it changes then it forces me to enter additional data about my account before letting me continue. (This assumes I got the password correct.) I think one or both also may use some cookie(s) to mitigate changing IPs. They may also make use of leaky browser data (like user agent strings etc.) to help identify me; they have the potential to see a lot since I'm not trying to hide from them. I don't see anything wrong in principle with "account lock out" provided that it doesn't affect existing sessions and provided that you can just ask the site to send an email with a token to reset your password. Spammers can lock a user out, so what. Minor inconvenience. If it's happening a lot to the same user and it's also affecting the user negatively, something extra could be done to minimize lockouts for the actual user (who should be easy to detect by the server through logs and a premise the user isn't trying to hide). Spammers are able to flood you with "forgot your password?" emails, too. I don't know how often they do it. I had my first wave in after 7 years of the same email just a few months ago mostly from old sites I forgot I even had accounts on. I'm not really a fan of the exponential backoff idea proposed earlier above, I'd sooner go with the "X tries, then wait" approach. The lockout time should not be more than 24 hours, ideally less. Though one could also set the lockout period to expire when the user's session automatically expires, if there's a current one, but that may be too clever. I feel that there are really two pieces of advice to give on dealing with spammers for the general case... Advice for low-traffic sites and advice for high-traffic sites. I don't have any advice with high-traffic sites since I have no experience with spam at that level (and by high-traffic I mean thousands to millions of uniques per hour), though I don't think the status quo is good enough. With low-traffic sites spam behavior is easy to detect and create a custom solution against. Custom solutions are often better than the popular stuff just by virtue of not having anyone targeting them specifically, and even if that's the case it's still easier to cat-and-mouse if the main options against spam aren't acceptable. Something as dead-simple as loading your form with javascript (or dynamically changing the URL endpoint when the submit button is clicked to something different than what's reported by the form's html attribute...) stops a lot of bots regardless of a captcha, even though you sacrifice the Lynx users. And in my own anecdotal experience I've had more success (less spam bots getting through and leaving a message) with a captcha like "Please join these two "words" together (without spaces): taeiswovd and brhpugqc" than with ReCaptcha even though it'd take less than a minute to add a parser for mine in a bot program. I used to use an arithmetic question but even the dumb bots are on to that one these days--at least the ones after my comment boxes. (I don't even think they added, they just tried numbers 0-99 and sometimes got lucky.)