5 ms·

How would disabling Twilio disable authentication entirely? From what I see it is used to send SMS and maybe Email as well. So I could understand that it would

How would disabling Twilio disable authentication entirely? From what I see it is used to send SMS and maybe Email as well. So I could understand that it would prevent login, registration and password reset if that service is offline, but it shouldn't allow any of these without authentication. Unless the software skipped authentication entirely when this service was unavailable, which I find hard to imagine. But that seems to be what is claimed right now.

brobdingnagians 6y ago
It appears Okta also banned them, they must have default succeeded instead of default fail, maybe an interaction between the two?: https://twitter.com/okta/status/1348191370528256002?s=20 https://twitter.com/okta/status/1348191370528256002?s=20
- fabian2k 6y ago
  That would be extremely careless, and I find it very hard to believe that this happened. An unlikely, but more plausible option to me would be that after removal of the Parler account, someone else was able to register the same account and gain access that way. But that doesn't fit the description all that well, and I'd also expect that this would not work at all if the authentication service is not very careless.
  - Mindwipe 6y ago
    Parler's infrastructure was extremely carelessly built in lots of ways, so it doesn't shock me.
  - audunw 6y ago
    Maybe another explanation is that they quickly hacked around the lack of these services just to get things working again? I can imagine them quickly making a bunch of ill-advised code changes just to get their platform working.
benmmurphy 6y ago
They make a request to twilio and their logic checks for a failure response instead of looking for a success response. They are not getting back a different failure response and this causes the requests to be incorrectly be marked as success. For example here is how something like that might break: /auth -> returns {"success": true} and 200 on success -> normally returns {"success": false, "error": "BLAHLBAH"} and 200 on failure developer checks if response["error"] is null to check if it was successful or not after your account is disabled /auth starts returning empty json: {} with a 500 error code oops. now all the requests are incorrectly marked as success. i know this happens because i've seen similar things happen in real life. the error could also be more obvious and the code just fails open. someone has a try/catch and returns true either because of an accidental mistake or because they don't want users to be locked out when the provider is down.
- nathan815 6y ago
  > the error could also be more obvious and the code just fails open. someone has a try/catch and returns true either because of an accidental mistake or because they don't want users to be locked out when the provider is down. Failing open would be a catastrophic mistake either way. "The auth provider is down, just let everyone in!"

brobdingnagians 6y ago

It appears Okta also banned them, they must have default succeeded instead of default fail, maybe an interaction between the two?: https://twitter.com/okta/status/1348191370528256002?s=20 https://twitter.com/okta/status/1348191370528256002?s=20

fabian2k 6y ago
That would be extremely careless, and I find it very hard to believe that this happened. An unlikely, but more plausible option to me would be that after removal of the Parler account, someone else was able to register the same account and gain access that way. But that doesn't fit the description all that well, and I'd also expect that this would not work at all if the authentication service is not very careless.
- Mindwipe 6y ago
  Parler's infrastructure was extremely carelessly built in lots of ways, so it doesn't shock me.
- audunw 6y ago
  Maybe another explanation is that they quickly hacked around the lack of these services just to get things working again? I can imagine them quickly making a bunch of ill-advised code changes just to get their platform working.

benmmurphy 6y ago

They make a request to twilio and their logic checks for a failure response instead of looking for a success response. They are not getting back a different failure response and this causes the requests to be incorrectly be marked as success. For example here is how something like that might break: /auth -> returns {"success": true} and 200 on success -> normally returns {"success": false, "error": "BLAHLBAH"} and 200 on failure developer checks if response["error"] is null to check if it was successful or not after your account is disabled /auth starts returning empty json: {} with a 500 error code oops. now all the requests are incorrectly marked as success. i know this happens because i've seen similar things happen in real life. the error could also be more obvious and the code just fails open. someone has a try/catch and returns true either because of an accidental mistake or because they don't want users to be locked out when the provider is down.

nathan815 6y ago
> the error could also be more obvious and the code just fails open. someone has a try/catch and returns true either because of an accidental mistake or because they don't want users to be locked out when the provider is down. Failing open would be a catastrophic mistake either way. "The auth provider is down, just let everyone in!"