Live data from Hacker News

Twilio incident: What Signal users need to know

support.signal.org

311–320 of 512 posts

Re: Twilio incident: What Signal users need to know

#311

Earlier quoted context omitted.

Allowing the Signal client to access your contact list is literally the premise of Signal; it's the core security UX trade it makes: no durable logs of who's talking to who on the servers, and contact lists stored exclusively on the client.

That may be their product management premise, but it's not why I use it. I use it because people I need to talk to are there and it has proper e2e messaging. I'm not beholden to their expectations of why I want to use their product. Also I'm not advocating for anything to be kept server side, nor do I see any reason why other identifiers couldn't be kept client side. An address book is just a list of identifiers, it'…

Signal replaces messaging services that were all keyed by phone number. Use something else. I don't think anybody can do better than explaining why Signal works this way, and what the benefits are, vs. the (amply articulated) liabilities.

This is one of the most boring repeated conversations that occurs on HN. It's incessant. Avoiding these incessant superficial conversations is, in fact, part of the premise of HN.

Re: Twilio incident: What Signal users need to know

#313
post #115

Earlier quoted context omitted.

> weak 4-digit PIN Are you sure that it makes sense to require people to pick something longer and non-numeric for a PIN? Or is your claim (wrongly) that people don't have longer non-numeric PINs (lots of us do) ?

Most people will choose weak passwords given the option. And so I think it's the responsibility of the developer to enforce strong requirements ( edit: when dealing with data encryption susceptible to brute-force attacks ): entropy estimations, 128(+)-bit static keys, etc. If any user has chosen a weak passphrase, and still believes it to be secure, the developer has likely failed.

> when dealing with data encryption susceptible to brute-force attacks

The "brute-force attacks" imagined here are a bad guy somehow controls Signal's systems, or else the US government seizes them and then decides to try to brute force them, right ?

But these are attacks where for various rival systems it was already game over. So your assumption is that Signal's casual users, people who maybe were also considering Whatsapp or iMessage or something, should be required to have a cryptographically strong passphrase so as to defeat this unlikely circumstance, as a minimum?

Moxie's whole deal is that this stuff only works when it's for everybody. If there are a five people in your country who use Signal, guess what, the Secret Police can round them up as suspected terrorists and execute them. Were they planning to bomb the President For Life? Or just organising a pizza party? Don't care, it's just good policy. But if there are five million people who use Signal that's a different matter.

Even if all five million are terrorists, that's numbers where you're going to have to tear up your "no negotiating with terrorists" policy, 'cos there are just too many of them.

Re: Twilio incident: What Signal users need to know

#314
post #200

Earlier quoted context omitted.

I am aware. For one it still works just as well is it ever has, the Zoom acquisition didn't change anything there. So if you care about features, there shouldn't be any problem. For sure it seems to be in maintenance mode, but nothing they were doing of late with Lumens was that exciting anyway (trying to become a crypto wallet like everyone and their mothers). I would pay $/mo for a Keybase reboot with the goal of b…

I've replied in a sibling comment about Peergos which is trying to do just that.

Definitely checking it out, thanks!

Re: Twilio incident: What Signal users need to know

#315

Cloudflare was attacked with the same attack but they were able to prevent any harm since they use hardware keys for 2-step instead of OTP. This is a very simple phishing attack and I am surprised it has proven to be effective.

No post body was provided.

Re: Twilio incident: What Signal users need to know

#316

The attack Twilio suffered is almost identical to the recent attack against Cloudflare: https://blog.cloudflare.com/2022-07-sms-phishing-attacks/ (even down the wording of the text messages, which are nearly identical). Cloudflare’s use of security keys prevented the attackers getting access to any accounts in that case. These attacks are sophisticated and are capable of bypassing TOTP or mobile-app-based MFA. If thi…

> These attacks are sophisticated and are capable of bypassing TOTP or mobile-app-based MFA.

To be honest, I wish people would stop parroting that these attacks were "sophisticated". In my opinion, I'd call something like Pegasus spyware "sophisticated". I don't think these attacks were that sophisticated at all - they were just standard issue, MITM attacks using targeted text messages - and they just took advantage of what is always the weakest link in security: people. I think of myself as a general middle-of-the-road software developer but I think I could have easily replicated this attack myself.

Re: Twilio incident: What Signal users need to know

#317

This incident points to something much more severe. What role was this employee(s) whose credentials were compromised? How did these credentials allow even an employee to get plain text auth codes being sent out to end users? Such a permission should be extremely limited in who it is granted to.

Totally agree. The message content should be private and not accessible by employees. Kind of scary when you think that so many 2FA codes are sent via Twilio.

Re: Twilio incident: What Signal users need to know

#318

Earlier quoted context omitted.

So they are tech-literate enough to use a smartphone, and apps for it, and they are tech-literate enough to type in their Signal password reminder in a hidden text field (and probably also passwords on dozens of web pages because password/keychain apps are "hard") but typing in e.g. an anonymized "user token" to add a buddy would be too "tech" for them? I refuse to believe a word of what you're saying.

> anonymized "user token" to add a buddy would be too "tech" for them? I refuse to believe a word of what you're saying. How do you transmit said anonymous user token securely? Using the secure messaging app you're already using? Meeting up in real life? Posting it on keybase? Each of these has downsides that are all solved by a phone number.

I don't see why the user token ("account name") has to be secret in every conceivable way. It just needs to be anonymous. What's wrong with meeting in real life, or exchanging account names in whatever way you initially exchanged phone numbers? You don't seem concerned over the security problem of account activation codes being sent over SMS, so I don't see why you should be concerned over exchanging anonymous account names in the same or more secure ways.

Re: Twilio incident: What Signal users need to know

#319

Earlier quoted context omitted.

Anonymity isn't part of Signal's risk model. If you need to stay anonymous, then there are more suitable options.

It is not about being anonymous (though this also could be nice in some situations), it is about identity theft and credentials theft. There are numerous ways to steal my phone number and then impersonate me on Signal. For me, it is not a big deal (though a dedicated hater can probably ruin my life with that). For many people in sensitive positions, this is literally a matter of life and death.

On average, stealing a phone number is much more difficult than stealing someone's password, because of the frequency of password reuse and data breaches.

If someone were to do that, it would be blocked by registration lock (which it prompts you to do). If they were to guess that, all your contacts would be notified that your identity has changed.

Re: Twilio incident: What Signal users need to know

#320
post #243
post #23

Earlier quoted context omitted.

No. When you sign up to Signal, they send you a text message verification code. This is done via a service called "Twilio." The attackers were able to view outgoing Twilio messages, so they could enter your number on the registration screen, read the code that Twilio sent to you, then use that cod to complete the sign up process. Attackers were not able to view information about your current Signal account (if presen…

But attackers are able to impersonate you to your contacts no?

If an attacker successfully registered your phone number, and if your contact either never checked the Safety Number for your conversation† or they ignore the fact that Signal says the number has changed, then yes, the attacker would be able to impersonate you to that contact.

Twilio says 1900 Signal users are potentially affected (attackers saw the confirmation code or could have seen the confirmation code) so Signal disabled those accounts pending re-registration.

† For any particular conversation pair, Signal has a large unique number it calls a Safety Number calculated from the long term cryptographic identities, if you got a new phone (or if I'm pretending to be you on a new phone), messages you send will have a different number because the new phone won't know the old phone's cryptographic keys. The phone app can display the number (so you can compare them) or scan a QR code from another phone to check they match without the boring work of comparing numbers.

Post reply on HN