4 ms·

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 on

by 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.

by neotek 12y ago

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.