21–30 of 42 posts
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
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.
Earlier quoted context omitted.
Having had to deal with apple and knowing quite a few other people who had a simmilar exprience i have a feeling that this was the only way of doing so. Apple is notorious for not accepting certain discovered vulnerabilities at best, and at worst ciminilizing people who do try and report an issue. This for some reason is much more prevelant for their services and mobile platform (especially when it comes to "design"…
> at worst ciminilizing people who do try and report an issue […] will atleast not send you threatening letters from their lawyers Wow. Citation needed, please.
We all know that anything that paints Apple in a bad light travels faster than the speed of said light and generally gets picked up by a dozen news outlets, no matter how rumour-esque it is. So it ought to be some traces of Apple taking legal actions against people reporting security issues against them, no?
Earlier quoted context omitted.
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 u…
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 li…
Nothing is, or should be, beyond the scope of Apple.
"Why? This bug is painfully obvious and was only a matter of time before it was privately used for malicious or nefarious activities, I publicly disclosed it so apple will patch it." I'm not a security expert but that does not sound like responsible disclosure to me. Granted, Apple is not easy to communicate with, but still… Edit: This does indeed look like a really bad thing. At the very least one would hope that lo…
Having had to deal with apple and knowing quite a few other people who had a simmilar exprience i have a feeling that this was the only way of doing so. Apple is notorious for not accepting certain discovered vulnerabilities at best, and at worst ciminilizing people who do try and report an issue. This for some reason is much more prevelant for their services and mobile platform (especially when it comes to "design"…
I don't think this is accurate, is it? I'm not aware of any security issue where Apple has tried to criminalise the reporter. I'm not even aware of an issue that hasn't been 'accepted'.
... ... wait, wait, wait. This is a tool which attempts to brute force a password by making HTTP POSTs to an API? And someone though the best way to write that was in in PHP, which is single threaded and thus cannot try multiple passwords in parallel? Wow. Ok. Good luck with that.
Earlier quoted context omitted.
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 li…
> but beyond scope for a lot of developers. Nothing is, or should be, beyond the scope of Apple.
One oddity I found is different length requirements for regular email and recovery email
EmailTooLong: "Email address must be less than 320 characters.",
RecoveryEmailTooLong: "Email address must be less than 256 characters.","Why? This bug is painfully obvious and was only a matter of time before it was privately used for malicious or nefarious activities, I publicly disclosed it so apple will patch it." I'm not a security expert but that does not sound like responsible disclosure to me. Granted, Apple is not easy to communicate with, but still… Edit: This does indeed look like a really bad thing. At the very least one would hope that lo…
Having had to deal with apple and knowing quite a few other people who had a simmilar exprience i have a feeling that this was the only way of doing so. Apple is notorious for not accepting certain discovered vulnerabilities at best, and at worst ciminilizing people who do try and report an issue. This for some reason is much more prevelant for their services and mobile platform (especially when it comes to "design"…
Earlier quoted context omitted.
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 li…
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…
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.
"Why? This bug is painfully obvious and was only a matter of time before it was privately used for malicious or nefarious activities, I publicly disclosed it so apple will patch it." I'm not a security expert but that does not sound like responsible disclosure to me. Granted, Apple is not easy to communicate with, but still… Edit: This does indeed look like a really bad thing. At the very least one would hope that lo…
Having had to deal with apple and knowing quite a few other people who had a simmilar exprience i have a feeling that this was the only way of doing so. Apple is notorious for not accepting certain discovered vulnerabilities at best, and at worst ciminilizing people who do try and report an issue. This for some reason is much more prevelant for their services and mobile platform (especially when it comes to "design"…
For that matter, I've never seen any of my friends in /r/netsec have difficulty either.
Slow to respond? Perhaps, if they receive many reports. Outright ignore or invalidate real flaws? Never seen it.
Do you have a data point to back this up?