Hmm - let's see who isn't
protecting accounts, let alone validation from brute forces...? No API for authentication should trust the client supplying it to do the validation - another Tmo fail to allow this.
¯\_(ツ)_/¯
Agreed. This is the first security rule in developing APIs and interacting with Client/Server type of data - never, under any circumstances, rely on client-side validation. T-Mobile is at fault here, not Apple. T-Mobile should NEVER rely on third party validation and security checks.
This is the biggest security rule in web development when passing data around! I am shocked T-Mobile even allowed this to begin with. NEVER EVER absolutely NEVER rely on client-side validation or security like 5 failed attempts.
[doublepost=1535372881][/doublepost]
"The page allowed for infinite entry attempts into the PIN field...."
This is web security 101. Who puts a form online nowadays without some form of captcha or limit on usage? Hell, even Apple's form that allows you to look up Macs by serial number cuts you off after 3 lookups for a period of time. And yet, this is just sitting there waiting to be abused? This was sloppy and inexcusable.
That's true, but this was really basic. This is something that anyone running a web site backend knows to shield their databases from. How many forms do you encounter nowadays that don't have a captcha or a built-in limit on usage? Almost none. This was an embarrassing oversight for Apple. It was the security equivalent of "hiding" your front door keys under the welcome mat. Apple is a great company but this was just dumb.
Apple certainly could implement a three check system, but it is an API integrated with T-Mobile's database. Apple would need to take up database storage to handle this. This is entirely on T-Mobile by not adding the required security on their API. Apple should not be forced to implement security that the API should have in the first place. It would take more resources for Apple to have database tables for keeping record of attempts, especially if you want a lockout for say an hour or 24 hours for one account.
[doublepost=1535373127][/doublepost]
Shouldn't T-Mobile's API have a rate limit per user? Even if you look past that, does their API documentation say that they don't have a limit and that clients like Apple should do the limiting?
You never, EVER absolutely NEVER should expose security risks by trusting third parties to perform your validation and security checks. NEVER. Under any circumstance! You can never trust client side validation.
The API should be the one performing this check. It should not be depending on Apple for this. What if someone found a way to bypass Apple's site altogether and develop their own malicious site/software that interacted with the API that did NOT perform these checks?
This is why the API level MUST.....ALWAYS....100% perform validation and security checks. There are no ifs. For proper security, it needs to be on the API level, not on a third party like Apple's website.
[doublepost=1535373290][/doublepost]
T-Mobile was definitely doing something wrong here. No matter what they shouldn't be allowing infinite requests to check a 4-digit numeric PIN. Apple also should not have allowed it, but mainly cause they should know Tmo's security sucks (besides that just for their internal reasons); it's Tmo's job to protect the PIN and not "trust the client" as others said above.
Along with my previous statements, I will add this. It is not Apple's job to do what an API should be doing in the first place. It would cost Apple significant resources by implementing their own database tables and storage. This is not just a simple thing.
