Live data from Hacker News

Twilio incident: What Signal users need to know

support.signal.org

231–240 of 512 posts

Re: Twilio incident: What Signal users need to know

#231
Unrelated to this current focus on the weakness of using a phone number as a contact reference, I have experienced a different problem. If a user has ever used Signal previously and for whatever reason revert back to SMS, if another user sends them a message via Signal it is lost with no indication. This is a growing problem as people try out Signal and when they get a new phone just forget or don't care to install it again.

Re: Twilio incident: What Signal users need to know

#232

Unrelated to this current focus on the weakness of using a phone number as a contact reference, I have experienced a different problem. If a user has ever used Signal previously and for whatever reason revert back to SMS, if another user sends them a message via Signal it is lost with no indication. This is a growing problem as people try out Signal and when they get a new phone just forget or don't care to install i…

[deleted]

Re: Twilio incident: What Signal users need to know

#233
post #214
post #160

This is a weird thread. There's a product that does secure messaging with usernames and only requires user/pass. It's called Keybase. If this is the product you want, then go use it. I don't understand why everyone wants Signal to be something it's not. I quite like Signal as they are and this "incident" demonstrates exactly what happens if a carrier gets compromised: nothing. Nothing happens. Signal decides not to t…

Matrix is the protocol I think one should go to if Signal's requirement of phone numbers is a turn down.

Matrix is great. Just remember that the Matrix threat model isn't the Signal threat model: you're usually telling a Matrix instance --- or, really, anyone who can compromise or suborn that instance --- a lot more about your communication patterns than you are with Signal.

Matrix, right now, is a lot more amenable to the kinds of messaging that people on HN tend to want to do than Signal is. The problematic thing is that HN people tend to believe that their workflows are (1) the most important and (2) the ones with the most sophisticated threat models. Neither are true; (2) is very un-true.

For, like, talking to team members about a shared dev project, I'd always use Matrix in preference to Signal --- of course, for that kind of work, what I'd really do is just use Slack or Discord. Which gets at something about what HN wants from Signal.

Re: Twilio incident: What Signal users need to know

#234
post #190

Earlier quoted context omitted.

There's a horrible conflation of concepts here. A pretty big one. When people talk about cloud services, they generally mean part of an application that runs on the cloud that participates as a trusted actor in the application's trust model. What people in the linked thread are realizing is that "signal has a server" and they are confused because they thought signal didn't have a server, or something. So, what's impo…

Signal has a "cloud" a server where they collect and store your name, your phone number, your photo, and list of every person you've contacted using Signal. That data isn't some ephemeral encrypted string that is only present when you "sync your profile picture" or when you send a message. It is collected and stored on their server where it will sit for at least as long as you have an account. The justification for i…

You should assume every bit of information sent on the internet is archived in a massive warehouse somewhere, because it is.

Thus, we have to trust the cryptography itself. Sending an encrypted message to a peer is no different from sending an encrypted message to yourself (other than the use of symmetric vs asymmetric crypto). The fact that you send a message to yourself which is stored persistently on signal's server doesn't change anything (and it's even opt in AFAIU). Sure, there are concerns about the implementation, but until someone can decrypt the blobs in storage (the crypto is broken) I don't see reason for outrage.

Pretty simply, if you don't trust the crypto then you have a very different threat model to pretty much everyone else. If you don't trust crypto you can't use the internet because you can't use TLS. You're relegated to networks where you trust every single node (where you don't need crypto) and other such stuff. Most of us trust the crypto because it's really the only practical option. I don't see the problem.

Re: Twilio incident: What Signal users need to know

#235
post #213

Earlier quoted context omitted.

>I refuse to use or recommend Signal due to blatantly bad design choices that put people that need privacy most at risk like security researchers, journalists, abortion seekers, or dissidents. I understand your concerns, and if I was a security researcher, journalist, abortion seeker or dissident, I wouldn't use Signal either. But, like the vast majority of us, I am not any of those things. As such, for my (and most…

With Matrix you can use F-Droid build of the client. And you don't really need to trust the server too much, right? Maybe it's not enough for Snowden, but it's better. I'm not saying "don't use Signal", in fact I still recommend it to non technical people, since it's just much simpler. But pointing at the flaws is a necessary requirement for them to be fixed

>With Matrix you can use F-Droid build of the client. And you don't really need to trust the server too much, right? Maybe it's not enough for Snowden, but it's better.

And why should I trust F-Droid's build of Matrix over Signal's build of Signal?

Please understand, I agree with your point. Mine was orthogonal: If you are under threat from motivated and/or state-level actors, using someone else's servers (or clients, for that matter) is a bad idea.

And that includes Matrix. I run my own Matrix server and the users of that server can interact (especially via voice/video) without any fear of being intercepted -- even by me.

What's more, I can't decrypt the conversations folks have in Matrix "rooms" that don't include me without a long process of brute-forcing.

No one is coming to my house to confiscate my server. That scenario is much more likely with a public/commercial service hosted at a data center/cloud provider.

So yes, Matrix is likely more secure than Signal if, and only if you build and install your servers and clients from source with a compiler/linker you built yourself using a trusted tool chain on hardware whose components you've personally confirmed to be free of compromise[0].

[0] https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-tho...

Re: Twilio incident: What Signal users need to know

#236
post #167

Earlier quoted context omitted.

With your username?

How do you text a username?

Why do you need to text? Sending messages without the arcane UX and unreliability of old school SMS or the tries at improving it(RCS) is simply better.

Re: Twilio incident: What Signal users need to know

#237
post #202

Earlier quoted context omitted.

> still the #1 IM app that I recommend to "normal people" What app do you recommend to HN types? (I'm getting ready to switch messaging platforms. All my friends use iMessage and I'm so tired of typing on my phone at them. They can be lured over to something else with the promise of encryption.)

Try Element. Effectively the same crypto as Signal but you can be anonymous as needed. Also decentralized with many app options.

And if Element is not the desired application to use matrix, then there are plenty of others, and available across many device and OS platforms: https://matrix.org/clients/

...Of course, Element remains the oldest and likely still most feature-full app.

Re: Twilio incident: What Signal users need to know

#238
post #4

>Among the 1,900 phone numbers, the attacker explicitly searched for three numbers, and we’ve received a report from one of those three users that their account was re-registered. I wonder if this was a curious attacker trying to see what they could do with their access, or a targeted attack.

The page is also quite vague about how the attacker got these 1900 phone numbers. It seems to imply that they were just the ones around when the attacker got access. But it doesn’t actually state that clearly. Were they 1900 random numbers or were they chosen somehow? The latter is of course far worse. They also apparently have logs of the attacker searching out three specific accounts within these 1900. That seems o…

The attacker sought out 3 specific numbers. The 1900 number is the amount of registrations that occurred during the time the attacker had access to re-register their Signal account – but likely mostly didn't.

Re: Twilio incident: What Signal users need to know

#239
post #71

This info gives us an interesting opportunity to estimate the rate at which Signal is adding new users. They've been very tight-lipped (understandably) about their usage stats but anecdotally they seem to be an increasingly common presence on my friends' phones, even the non-techies. As far as I can tell, Signal uses Twilio only to send SMS for phone number verification. Verification happens when a user registers a n…

Signal's SMS registration codes expire after a few minutes, so you wouldn't even need to know the duration of the incident. Let's be conservative and say the codes expire after 5 minutes (it's probably shorter), then Signal is registering 380 devices a minute.

My reading of the post is that they determined the "1,900 users" figure by the number of users who had requested a code during the duration of the Twilio incident, as the attacker could have accessed their SMS messages at any point during the compromise:

> During the window when an attacker had access to Twilio’s customer support systems it was possible for them to attempt to register the phone numbers they accessed to another device using the SMS verification code. The attacker no longer has this access, and the attack has been shut down by Twilio.

Re: Twilio incident: What Signal users need to know

#240
post #160

This is a weird thread. There's a product that does secure messaging with usernames and only requires user/pass. It's called Keybase. If this is the product you want, then go use it. I don't understand why everyone wants Signal to be something it's not. I quite like Signal as they are and this "incident" demonstrates exactly what happens if a carrier gets compromised: nothing. Nothing happens. Signal decides not to t…

It's interesting to me that you used Keybase as the example. My brain doing its guessing ahead thing assumed you were going to say Matrix. I've seen several popular instances of it, and run in to people actively using it at least monthly where I haven't seen anyone use Keybase in years (since the Zoom acquisition). Do you see a lot of people _actively_ using Keybase still?

I personally use it for LOTS of stuff, both personal and commercial (as a Slack replacement). Other than a couple bugs (pinch to zoom on Android, media playback), it's fine - I don't feel like I need any more features, though I'd love it to be a bit snappier. KBFS has been excellent for stuff like secrets in CI pipelines.

Disclaimer: I'm one of the ex-Keybase, now Zoom people. I'm definitely in a bubble. The non-Keybase people I talk with are my consultancy's employees + a couple clients.

Keybase's security model is excellent in protecting you from attacks like the one described in the OP. If you can't sign your device with another one, you can only recover a username if:

- it's not in [lockdown mode](https://book.keybase.io/docs/lockdown)

- it has a verified email / phone number

- you either click a reset link in the email / SMS _or_ know the password

- _and_ the user fails to cancel the reset over many days of warnings.

And if you manage to go through all that trouble, all your contacts will get blasted with warnings about your identity. Fun!

Post reply on HN