[x1798DE]

>So...I don't know what the "flaw" is...but it doesn't seem to me that the OP learned the biggest lesson of all about security: that pretty much everything is a tradeoff.

The flaw is side-channel data leakage about the authentication process and about the user data - they're revealing private information to someone who has not successfully authenticated. Just because the guy published his password doesn't mean it's not a flaw - if someone got his password from a compromised database they shouldn't be able to leverage that into finding out his phone number or anything else about him, if he's already arranged with Twitter (or any other service) to a protocol which basically says, "Don't believe anyone saying they are me unless they both know my password and have my phone."

Frankly, a well-designed 2FA system shouldn't even reveal whether or not you've successfully authenticated using one of the factors. For TOTP this is possible because you can enter in the username, password and TOTP code all at the same time (though it's rare to see this implementation). Even if TOTP is not enabled for most accounts, you'd still want to show the box and say, "Leave this blank if you don't have TOTP enabled". For this SMS-based second-factor, I'm not sure how to design it so that there are no side-channel attacks other than sending an SMS with an authentication token every single time, whether or not the password was entered correctly (which allows random people with your login to just randomly send you authentication spam).

[danso]

OK, I see that the flaw was that the phone number was revealed to a user when, after installing the Twitter for iPhone app, wanted to specify that the code be sent via text to a phone number...And the Twitter app reminds the user -- who again, has successfully entered the password -- what number the message goes to.

So, if you're thinking, what kind of dumbass would need to be reminded what phone the code was going to?...well, the OP for starters. In fact, he recommends readers to get Google Voice numbers (ooh, another attack vector/dependency, but let's ignore that for now)...so, if you're such a user, who has a phone and some burner numbers, and you tell the Twitter app to send a reminder to your phone number...and nothing comes...that's going to seem like a point of failure.

And IMO, that situation is going to be much more likely than the case of a user telling the world his password and username. Also, it seems more likely than phishers doing something more damaging than getting phone numbers after manually going through the phone app for each password stolen...My impression is that such phishers do not typically rely on manual methods, especially if by doing so, they don't get access to the target account...seems like a low return on investment of effort.

[x1798DE]

The threat model isn't "what if someone tells everyone their username and password", it's "What if someone gets your username and password". I think most of the time people have one number they connect to, and everything else will be fringe cases. If you're worried they'll forget what phone number it's sent to, you can do the same thing you do with other verification/reset loops - "Enter your e-mail address and we'll send you an e-mail with the phone number you used". It might not always be the best authentication method, but at this point almost all authentication falls back to "I control the e-mail address that I controlled when I started the account" at this point anyway.

Plus, at the very least you could just reveal the last 2 digits of the phone number upon request. That's still side-channel data leakage, but at least it's much more contained.