Google has introduced a new feature called Restore Credentials which saves your app login info and restores it seamlessly on new devices.

  • Varyk@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    1 month ago

    that sounds… vulnerable.

    is that why Apple devices perpetually get broken into and all the pictures/info shared?

    because their login information is held by a third party?

      • Varyk@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 month ago

        I feel like I read a new article with Apple IDs being leaked every year.

        looks like there there have been six major apple data leaks since the 2014 incident you’re talking about, so a major leak based on exploits every year and a half, and then there’s also all the individual articles that pop up with someone saying they received notification that they’re iCloud data or Apple ID was leaked, which I don’t know the frequency of but I see all the time.

        https://firewalltimes.com/apple-data-breach-timeline

        https://discussions.apple.com/thread/254140360?sortBy=rank

        seems to happen fairly often.

        • coherent_domain@infosec.pub
          link
          fedilink
          English
          arrow-up
          0
          ·
          edit-2
          1 month ago

          I think these are different. They mostly find vulnerability in the iOS system as opposed to try to crack the backup system.

          I think iOS or Android backup system are rather secure compared to other components because of the following: hacker will also need to break into a cloud drive to retrieve them, which adds extra work; the backup is simple, just bunch of files and a password, apple/google can use standard well-tested encryption to encrypt them.

          However, guaranteeing there is no way to break into an operating system, especially with all the features that a modern system requires, is much harder.

          • Varyk@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            0
            ·
            edit-2
            1 month ago

            yeah, these data leaks are all about break into iOS specifically to access iCloud data and accounts, I don’t know about their backup servers.

            If they can get the data up front, why go around the back?

            The iCloud leak from 2014 was all leaked login information also, it’s why they finally implemented encryption.

            oh but Apple officially says that the 2014 attack was only due to fishing and brute Force attacks.

            idk, enforcing encryption directly after that was a good idea, but I doubt they would do it unless it was necessary or vulnerable.

        • Deckname@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          0
          ·
          25 days ago

          Thanks for the links! apparently apple seems to deal with breaches quite well, and at least in the firewall times article most of the Breaches were not on really caused by apple and they reacted anyways. Exceptions are the pegasus hack, but no software is secure, and the exploit got patched.

          • Varyk@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            0
            ·
            25 days ago

            surr… that’s how breach timelines go in general, it’s a lot easier to “hack” lax security procedures directly or for third parties that Apple or Microsoft shares sensitive information with than it is to attack any database directly.

              • Varyk@sh.itjust.works
                link
                fedilink
                English
                arrow-up
                0
                ·
                18 days ago

                hasn’t worked yet, 2fa doesn’t help with third-party breaches, and apparently doesn’t help secure Apple’s back end either.

                they’ve got to invest more in basic security infrastructure instead of placing the burden on the consumer, but I don’t think that’s going to happen either, since apple consumers are still happy getting breached every year.

                • Deckname@discuss.tchncs.de
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  18 days ago

                  and what do you personally use? which company is up to your high security standards?

                  because i read the same breaches with android powered phones, web browsers, windows… etc.

  • kolorafa@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 month ago

    No thanks, sounds like security and privacy nightmare.

    The part about “no user interaction required” doesnt feel right secure.

    Especially as it is stored at google servers, it says it is encrypted but it is encrypred using keys that google has access to as they are unlocked with you logging in into google account.

    • coherent_domain@infosec.pub
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      1 month ago

      it says it is encrypted but it is encrypred using keys that google has access to as they are unlocked with you logging in into google account.

      First it uses lock screen password, so google do not have access to this password.

      Even if your lock screen is unfortunately your Google password, I think proper authentication protocol do not send your password to Google to authenticate, but only the hash, which cannot be reverted to derive your password.

      Obviously, the above is assuming that Google is not malicious. Otherwise it can just use play service, which is privileged and closed source, to get all your data. If your threat model including Google itself trying to steal your key, you will probably need to install a trusted rom or use iOS (however, apple and the rom developer can also steal your key).

      • kolorafa@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        1 month ago

        proper authentication protocol do not send your password to Google to authenticate

        That is not true for 99% services including google. Google have a plain text password at the time you are logging in, they just store hashed+salted version in storage.

        (Almost) No website (or app) is hashing the password before sending it to server, so if you hack the login screen you can dump RAW passwords anytime.

      • kolorafa@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 month ago

        assuming that Google is not malicious

        Previously they would need to push malicious code to your device to steal your login data, that is a risk that someone would do reverse engineering on that and expose it, now they will have the data on their servers and they can abuse it any time they want, I doubt they will use it to login as you, but they will use it as metadata to connect all your accounts for marketing.

    • u/lukmly013 💾 (lemmy.sdf.org)@lemmy.sdf.org
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 month ago

      Aren’t they encrypted with the phone’s lockscreen password? You very much need that to restore cloud backups. Not that it has much value if you’re a 4 digit PIN person…

      Anyway, I cans use a search engine:

      Some data is further encrypted with your device’s screen lock. Photos and videos stored in Google Photos, and MMS media received from your carrier are not encrypted by your device’s screen lock.

      Well, what is some data?

      Anyway, I wish for something universal for offline backups. I mean, without root.

    • atocci@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 month ago

      It’s only stored with Google if cloud backup is enabled it says. Otherwise, the keys are transferred along with all the other data directly from device to device when switching.