Maybe it was more complex: Create new acct 1 using valid email. Request users by username and see privilege. Find likely phone # and likely email for user : arroganttechfounder1 (admin). Create new acct 2 using likely phone number (fail, account exists). Change (add) new acct 1 phone # to match likely phone number (normally, the twilio validation step here would prevent duplicate phone numbers for multiple accounts?). Request pw reset for phone number (pw reset key saved to both accts?), no sms sent. Request pw reset for email (new acct 1) and logic sees non-expired key from previous request, emails you same key. Modify url to reset pw for arroganttechfounder1 using phone # and key.

> And somehow, without access to Twillio's API, they defaulted to not do any check at all?

I guess you could imagine user accounts being created with `authenticated=null`, and then having `authenticated=False|True` set in the in the success handler for some Twillio API call. Having null as the default would allow you to see in the database where authentication emails hadn't been sent out, so you could resend them.

And then I guess you could imagine a developer checking authentication by looking for cases where `!authenticated`, rather than `authenticated == True`. Granted I don't think this hack is real, but if it were then that's probably how it would play out.

That, or Twillio was reporting authenticated emails, without actually authenticating them?

It seems to involve some skipped auth steps on someones part though, not just a fail-safe/fail-dead mixup. It's not clear.

Maybe Parler was deciding based on HTTP status codes returned from the Twilio API, or the presence of some expected "error" field in the response (if it's not there, consider it ok), and one side screwed up the handling of an unexpected case? Pure speculation.

Instead of having "if explicitly ok, proceed", they maybe had "unless it's an explicit negative response in an expected format (or a connectivity issue, timeout, etc.), proceed"?

Which would be a pretty dumb thing to do, but I've seen worse.

> they defaulted to not do any check at all?

That would be a very unsafe default.

They wanted more users to register - they were urging users to invite friends and family - so they may have changed the safe default to the unsafe one thinking on verifying later without realizing the full consequences of what they did.

Nope it was totally realistic.

I tried to create an account on Parler last night to check which services were turned off by AWS. I entered dummy data into their form. The POST to their auth service timed out...but the auth flow took you to the success page anyway?