Comment by loginatnine

Comment by loginatnine 4 days ago

6 replies

I've been working with an app that uses Google to login for the past 10 years, and I've had problems with sub changing when these situations happened : - Domain change - Company being bought by another one and being integrated in their Google Workspace - Employee leaving and coming back

To us, it's very very far from the quoted 0.04% which is to me very high. I had to deal with it 5-6 times in the past 10 years but of course that number will vary depending on the usage of your app and I'm not gonna venture and put a percentage on it.

herczegzsolt 4 days ago

In my opponion, all of those cases very well justify a manual check, or some sort of extended identification before the user is let in.

It indicates a deeper cultural issue of "convenience/profit over security" if those are sufficient reasons to not check the sub parameter.

  • chavesn 4 days ago

    > all of those cases very well justify a manual check, or some sort of extended identification before the user is let in.

    Just curious, what would that check look like that's not open to the same vuln?

    • herczegzsolt 4 days ago

      For example a call to the registered owner or contact person of the organizaton (not the user).

      Any out-of-band communication should work which checks for the legal entity, not just something that eventually relies on DNS.

      Alternatively, you can always just not let them access the old user, and create a new one instead.

    • ycombinatrix 4 days ago

      "Your account seems to have changed hands and is locked for your security.

      The person paying for your subscription must contact us to verify your account is still legit."

      • chavesn 4 days ago

        Right, and how would you further verify “the person paying for your subscription”?