3 ms·

How is it not rate limited? I don't understand why this is not a thing in every login activity everywhere. can someone explain one reason you might choose to NO

by sekasi 12y ago

How is it not rate limited? I don't understand why this is not a thing in every login activity everywhere. can someone explain one reason you might choose to NOT rate limit auth attempts? I don't understand :S

dogma1138 12y ago
Any effective rate limiting tends to cause major UX issues under many circumstances and opens the system to denial of service under some. Probably the best way of dealing with such attacks these days is what Google and many other companies do and that's use huristics and progressive challenges, while not perfect these tend to be usually even more effective than rate limiting. If the auth requests are comming for an unknown device, a foriegn IP address, at a suspicious time/rate etc. the user is challenged for additional information than just their passwords this can be some random secret question a secondary authentication (via phone, SMS, email etc) or even some anti scripting stuff.
- neotek 12y ago
  Heuristics and progressive challenges are definitely the best option, but beyond scope for a lot of developers. Rate limiting is the simplest option, and the only real "major UX issue" I can think of is locking someone out of their account after three password attempts, which can definitely be a pain in the arse if you're trying to log into a site you don't frequently visit. But the solution is pretty simple: rate limit to one attempt every few seconds, and if you want to lock the account, only do so after a lot of unsuccessful attempts. For example, bruteforcing is impractical if you can only try one password every five seconds, and essentially impossible if you only get 100 bites at the apple before you get locked out.
  - dogma1138 12y ago
    I would think Apple is more than capable of doing progressive challenges and heuristic analysis for the login. And while it's true that it's not as easy as simple rate limiting for developers that develope their own simple services there are plenty of login providers and frameworks that handle it well. Honestly today i see very little reason to develope your own login mechanism and not use many of the available SSO's out there unless you are big enough for it to matter, and then you have no resource limitation. The problem with rate limiting is that it's very hard to do it properly and scale it. For example how do you do rate limiting? are you doing it per "session" e.g. increase the login proccessing time for each individual IP address? if so then distributed attacks will still be effective. And if you are simply doing it for each sessions (by cookie or some other identifier) then it doesn't help against scripting attacks what so ever since they can be adapted to request a new session every time. Where do you set the limit flag? is it handled by the authentication front end? If so you'll have issues enforcing this if you have a distributed solution which a service with as many users as iCloud will have. If you are doing it on your main identity DB then you also might have scalability issues since you will have to sync these values accross all of your instances. Also don't forget that every time you do this "rate limit" it means that there will be a "proccess" on your authentication server idling for the duration of the limit, this means that there will be halted login attempts on your authentication servers, enough of them and you might get into some serious resource issues. A 10 second pause might be acceptable on your laptop after you type your password wrong 3 times, but doing it on the server means that it allocates resources then puts limitations on how fast these resources can be cleared which isn't a very good design. As for the UX issues the problem is that it's not always as simple as some username and password, especially for services such as iCloud where a simple missbihaving app can cause accounts to be effectively locked out, and when you count in the amount of users such services has then it becomes quite a frequent event. So yes while i do agree rate limiting does effectively prevent brute forcing, i don't see it as being a viable strategy for an online service. Rate limiting should be left for closed enviornments where you have full control over your clients and where users can be serviced in a reasonable manner. Putting it on distributed open services that service millions of users where you might have various types of clients that you have no control over making authentication requests will just cause trouble.
    - neotek 12y ago
      >Honestly today i see very little reason to develope your own login mechanism and not use many of the available SSO's out there unless you are big enough for it to matter, and then you have no resource limitation. On the contrary, I see very little reason to use someone else's authentication infrastructure (Facebook, Google+, et al) without at least also providing the option to register using plain old email, unless you're developing an app that is intimately tied to that service. You lose so much control over your users, and you risk everything on your SSO provider not changing their minds about how you can use their service (see Twitter.) Regarding your other points about rate limiting, I think you're overcomplicating the situation. It doesn't require a process on your authentication server that sits around and waits for one particular client to be allowed to try again (why would it?), and db sync issues are largely irrelevant unless you're at serious scale, which 99.9999% of web apps never will be, and if they are at serious scale, chances are syncing a "last_login_attempt" field in a login table is the least of their difficulties. In Apple's case, of course rate limiting isn't the only solution they should be using, but it's a perfectly fine solution in the vast majority of cases where building a heuristic engine to protect a cat forum login page is overkill.
  - madeofpalk 12y ago
    > but beyond scope for a lot of developers. Nothing is, or should be, beyond the scope of Apple.
    - neotek 12y ago
      Yes, I wasn't talking about Apple.
baby 12y ago
Because if you want to limit the number of attempts you have to code it into the login module. If you want to save time... By the way, if you're attempting a bruteforce don't use PHP.
- pilfers 12y ago
  I agree. I tossed up a terrible drunk Python PoC on /r/netsec. https://github.com/Pilfer/iDictPy https://github.com/Pilfer/iDictPy

by sekasi 12y ago

dogma1138 12y ago

Any effective rate limiting tends to cause major UX issues under many circumstances and opens the system to denial of service under some. Probably the best way of dealing with such attacks these days is what Google and many other companies do and that's use huristics and progressive challenges, while not perfect these tend to be usually even more effective than rate limiting. If the auth requests are comming for an unknown device, a foriegn IP address, at a suspicious time/rate etc. the user is challenged for additional information than just their passwords this can be some random secret question a secondary authentication (via phone, SMS, email etc) or even some anti scripting stuff.

neotek 12y ago
Heuristics and progressive challenges are definitely the best option, but beyond scope for a lot of developers. Rate limiting is the simplest option, and the only real "major UX issue" I can think of is locking someone out of their account after three password attempts, which can definitely be a pain in the arse if you're trying to log into a site you don't frequently visit. But the solution is pretty simple: rate limit to one attempt every few seconds, and if you want to lock the account, only do so after a lot of unsuccessful attempts. For example, bruteforcing is impractical if you can only try one password every five seconds, and essentially impossible if you only get 100 bites at the apple before you get locked out.
- dogma1138 12y ago
  I would think Apple is more than capable of doing progressive challenges and heuristic analysis for the login. And while it's true that it's not as easy as simple rate limiting for developers that develope their own simple services there are plenty of login providers and frameworks that handle it well. Honestly today i see very little reason to develope your own login mechanism and not use many of the available SSO's out there unless you are big enough for it to matter, and then you have no resource limitation. The problem with rate limiting is that it's very hard to do it properly and scale it. For example how do you do rate limiting? are you doing it per "session" e.g. increase the login proccessing time for each individual IP address? if so then distributed attacks will still be effective. And if you are simply doing it for each sessions (by cookie or some other identifier) then it doesn't help against scripting attacks what so ever since they can be adapted to request a new session every time. Where do you set the limit flag? is it handled by the authentication front end? If so you'll have issues enforcing this if you have a distributed solution which a service with as many users as iCloud will have. If you are doing it on your main identity DB then you also might have scalability issues since you will have to sync these values accross all of your instances. Also don't forget that every time you do this "rate limit" it means that there will be a "proccess" on your authentication server idling for the duration of the limit, this means that there will be halted login attempts on your authentication servers, enough of them and you might get into some serious resource issues. A 10 second pause might be acceptable on your laptop after you type your password wrong 3 times, but doing it on the server means that it allocates resources then puts limitations on how fast these resources can be cleared which isn't a very good design. As for the UX issues the problem is that it's not always as simple as some username and password, especially for services such as iCloud where a simple missbihaving app can cause accounts to be effectively locked out, and when you count in the amount of users such services has then it becomes quite a frequent event. So yes while i do agree rate limiting does effectively prevent brute forcing, i don't see it as being a viable strategy for an online service. Rate limiting should be left for closed enviornments where you have full control over your clients and where users can be serviced in a reasonable manner. Putting it on distributed open services that service millions of users where you might have various types of clients that you have no control over making authentication requests will just cause trouble.
  - neotek 12y ago
    >Honestly today i see very little reason to develope your own login mechanism and not use many of the available SSO's out there unless you are big enough for it to matter, and then you have no resource limitation. On the contrary, I see very little reason to use someone else's authentication infrastructure (Facebook, Google+, et al) without at least also providing the option to register using plain old email, unless you're developing an app that is intimately tied to that service. You lose so much control over your users, and you risk everything on your SSO provider not changing their minds about how you can use their service (see Twitter.) Regarding your other points about rate limiting, I think you're overcomplicating the situation. It doesn't require a process on your authentication server that sits around and waits for one particular client to be allowed to try again (why would it?), and db sync issues are largely irrelevant unless you're at serious scale, which 99.9999% of web apps never will be, and if they are at serious scale, chances are syncing a "last_login_attempt" field in a login table is the least of their difficulties. In Apple's case, of course rate limiting isn't the only solution they should be using, but it's a perfectly fine solution in the vast majority of cases where building a heuristic engine to protect a cat forum login page is overkill.
- madeofpalk 12y ago
  > but beyond scope for a lot of developers. Nothing is, or should be, beyond the scope of Apple.
  - neotek 12y ago
    Yes, I wasn't talking about Apple.

baby 12y ago

Because if you want to limit the number of attempts you have to code it into the login module. If you want to save time... By the way, if you're attempting a bruteforce don't use PHP.

pilfers 12y ago
I agree. I tossed up a terrible drunk Python PoC on /r/netsec. https://github.com/Pilfer/iDictPy https://github.com/Pilfer/iDictPy