Hacker News Reader

Comment by redwine11 | Hacker News Reader

Sounds like Twillo was actively helping hackers "That allowed them to see which users had moderator rights and this in turn allowed them to reset passwords of existing users with simple “forgot password” function. Since Twilio no longer authenticated emails, hackers were able to access admin accounts with ease."

View on HN

Maybe Parler should have done their due diligence and planned for if their email verification service stopped working.

The logic doesn't even make sense. Twilio goes down for them and then they just allow anyone access to user accounts.

Or maybe self-host.

As I'm reading it, Twilio simply shut down the account, Parler is the one who reacted to that by assuming everything is authenticated if the API doesn't work.

Seems implausible. Why would anyone design a system that way. I suspect it must be a more complicated combination of circumstances as it often is.

"The truth is, these are not very bright guys, and things got out of hand." - Deep Throat, during Watergate

I could only find "All the President's Men" (1976) as the source for that quote. While googling that, it seems like he never said "Follow the money" either :)

https://en.wikiquote.org/wiki/All_the_President%27s_Men_(fil...

https://en.wikiquote.org/wiki/W._Mark_Felt

Because you want your users to be able to access the service if Twilio is having downtime rather than your service being essentially down for them. Twilio killing their account was probably not an assumed use case. The biggest expected impact was new user SMS authentication which you could run after the downtime is over. Better some spam users than losing those potential users was their thought I'm guessing. I suspect password reset also failing open wasn't thought of as deeply because it's a rarer path but it got bundled together with the SMS auth code path.

edit: I'm sure we've all had really stupid requirements pushed on us by the business side for the sake of user experience or increasing metrics. Or written bad code at 3am during crunch time.

This assumes it was by design, likely someone unfamiliar with the security implications thought they were improving the customer experience by not failing hard.

Or just oversight, could actually be embarrassingly easy to mess up:

    if not twilio_authenticate(user, pass):
        return Err()

    return User(user)

and:

    def twilio_authenticate(user, pass):
        try:
            return twilio.verify(user)
        except:
            return False

Might independently look reasonable enough.

Many businesses today still grapple with the decision to fail-open or fail-closed for things they build in-house.

>Why would anyone design a system that way

Because they knew that, being a save haven for violent white supremacists, it was likely one or more of their service providers would terminate service and wanted to continue to operate despite any termination.

fail open heh

That's like saying Amazon was actively helping hackers when your app allows anyone to log in when it can't connect to a passwords table in a shut down DynamoDB instance.

Twilio shut down the account and Parler decided to pass all verification attempts instead.

Reply on news.ycombinator.com