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.

> they defaulted to not do any check at all?

That would be a very unsafe default.

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.

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?