Apple Online Store Security Flaw Exposed PINs of T-Mobile Customers

Discussion in 'MacRumors.com News Discussion' started by MacRumors, Aug 24, 2018.

  1. xWhiplash macrumors 68000

    Joined:
    Oct 21, 2009
    #101
    And what happens when a million people miss type their pin three times? Millions of records. Like I said, it needs to support millions of records. What happens if they only plan for 10 people to have this issue at a time and there is an 11th person? Small example but you get the idea. They need to plan for large scale, or else there will be more problems.

    This is like fixing a bug within a day vs a week to make sure it doesn't cause any more issues. Sure they can slap a poorly designed database table together, but it could cause issues if a lot of people suddenly start mistyping their pins several times.

    This is how you handle large databases or a large customer base. Plan for a large data set. For example, we started using bigint instead of int for tables that constantly grow due to running into the limits of ints numerous times. You think it will never happen, but it does. And adjusting the code after the fact is very time consuming. Or a horrible approach is to reseed the index so that it utilizes the negative int values. So....you plan ahead. Oh and obviously our site was not even close to the same scale as Apple. NO WAY.

    It doesn't matter how big or small a company is. It is still taking software development resources from other projects to implement this issue which should have been implemented at the API level in the first place.

    What happens if there is a bug in Apple's implementation of these security checks?
    What happens if like you said it will be a relatively small table but suddenly became larger than what they were planning and unforeseen bugs started to show up?

    This is the problem with most software development these days. You think some of this stuff never happens, but it does.
     
  2. ipponrg macrumors 68000

    Joined:
    Oct 15, 2008
    #102
    DevOps scaling is fine. Redis/Mongo/Cassandra etc can be built to scale. This is nothing out of the ordinary for anyone with DevOps experience. If your intent is to develop a solution using persistent storage, then I'd say your architecture is flawed for this use case.

    You keep referring to tables. There are other types of data stores that don't use tables. The schema for a preliminary gated check is fairly straight forward if you have dabbled with anything outside SQL.

    I think there is some confusion here. I am not talking about the back end architecture. I am only talking about the gate that would be sitting on the Apple side before it goes to the Tmobile APIs. Also, sounds like you're using a SQL database here. In other memory stores, your lookup parameters are using unique string keys and not numbers. Performance is done in-memory (e.g. volatile).

    What are you talking about? The worst case scenario here is Apple allows attackers to type PINS without restriction.

    The initial size of the tables here don't really matter because it's assumed they will grow/shrink as necessary. Redis tables are the size of your memory. Now imagine if you had a cluster of Redis servers. You can grow that cluster via memory expansion for each instance dynamically with ease.

    The worst case scenario here is you have 72M temporal records.

    https://redis.io/topics/faq#what-is...ber-of-elements-in-a-hash-list-set-sorted-set
     
  3. bjoswald macrumors regular

    bjoswald

    Joined:
    Jul 21, 2016
    Location:
    Florida
    #103
    Not good. Not good at all. However, Apple always takes these issues seriously and will fix them promptly.
     
  4. Mascots, Aug 27, 2018
    Last edited: Aug 27, 2018

    Mascots macrumors 68000

    Mascots

    Joined:
    Sep 5, 2009
    #104
    Don't get me wrong Apple should have a form like this protected from brute force - but not because it allows unlimited guesses at a PIN - that should have never been a possibility from the carrier.

    That responsibility lies with the entity handling the data and authentication, which is T-Mobile since they are the ones hosting that data. They should have their APIs for this kind of authentication locked at the very base point at which it accesses that information internally.

    It's another failure of T-Mobile to handle, transit, and store sensitive information. If they're pushing that responsibility to those plugging into their system and seemingly not enforcing anything at all, that's the definition of unaccountability. "It's not my problem" isn't an answer I want to hear from those hosting my senesitive data.

    Shame on Apple, but Tmo is hardly an innocent party.
     
  5. 69Mustang macrumors 604

    69Mustang

    Joined:
    Jan 7, 2014
    Location:
    In between a rock and a hard place
    #105
    Aaaaand there's the trifecta. The 3rd let's breeze by Apple and focus on TMo comment. No one claimed TMo to be an innocent party. But if the 3 comments I've replied to are any indication, one could almost believe the attack vector was TMo's website, not Apple's. Spread the blame. Good thing it's some of Apple fans and not Apple who feel the need to point at everybody else. Apple just slapped on big boy pants, fixed the issue, and said thanks for letting us know. Certain fans can't seem to abide Apple being at fault for anything. They have to make sure the bus wheels roll on everybody's neck. It's all good.
     
  6. Tech198 macrumors G5

    Joined:
    Mar 21, 2011
    Location:
    Australia, Perth
    #106
    There is no such thing as perfect security..... You only got perfection, until it breaks. I would also argue social engineering is making it too easy now-a-days, (*because*) of users plastering personal info on social sites...

    The more info others know about us, the easy it will be to use it against us later, if they want.
     
  7. fairuz, Aug 27, 2018
    Last edited: Aug 27, 2018

    fairuz macrumors 68020

    fairuz

    Joined:
    Aug 27, 2017
    Location:
    Silicon Valley
    #107
    Yes, I am doing the same thing as zacharino. It's Tmo's API for the PINs, Tmo's fault if that can be abused. I hope Apple gets Tmo to fix their stuff instead of just sweeping it under the rug on their side. Anyone with experience in computer security or software design will agree.
     
  8. fairuz, Aug 27, 2018
    Last edited: Aug 27, 2018

    fairuz macrumors 68020

    fairuz

    Joined:
    Aug 27, 2017
    Location:
    Silicon Valley
    #108
    Postgres will handle millions of records straight out of the box (idk about MySQL cause I never use it), and Google's Spanner can scale much further if you can partition the data, but actually the other guy is right about in-memory data stores.

    Anyway, they could have a prebuilt rate limiting service to plug into any web service without much effort. I don't blame Apple for this PIN issue but think they should do their own rate limiting anyway for other reasons.
     
  9. I7guy macrumors Core

    I7guy

    Joined:
    Nov 30, 2013
    Location:
    Gotta be in it to win it
    #109
    It just couldn’t be T-MOBILE website shared in the blame, could it. The TMO web service couldn’t possibly be coded better, could it?
     
  10. Mascots, Aug 28, 2018
    Last edited: Aug 28, 2018

    Mascots macrumors 68000

    Mascots

    Joined:
    Sep 5, 2009
    #110
    You literally said that T-Mobile have their issues, but this is just an Apple problem. I disagree that this is just an Apple problem. I never said this isn't an Apple problem. I think there are multiple levels of failure, but the biggest falls on the one supplying authentication, which is T-Mobile.

    If you can't put ANY blame on T-Mobile for this issue because "it was on Applez site therefore it must be them!1!!", then you're just as bad as those who are only putting fault on T-Mobile.

    Apple fixed their end, my concern is that T-Mobile isn't fixing theirs for other vendors with hooks into the unprotected service because of the emphasis on Apple and Asurion (in which I also find AT&T, the data owner, more at fault). Who will be the next entity with this vulnerability to point to when it's should be the data hosts for not doing their damn due diligence?
     

Share This Page