Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twilio incident: What Signal users need to know

support.signal.org

Post reply on HN
Print view View original

111–120 of 512 posts

Re: Twilio incident: What Signal users need to know

#111

Post by xorcist »

A4ET8a8uTh0 wrote: post #70
uncomputation wrote: post #47

Yes, Signal’s phone number requirement is bad. But, given that, the fact that they don’t store any messages on their side and everything is client side is still a huge benefit over a lot of other apps and still a huge step forward for privacy! Criticism is definitely important but I just wanted to put that out there that all things considered, Signal is still very much a good thing.

I will admit that this requirement always confused me. What is there to benefit from by requiring it?

Beside the technical reasons, tech companies are valued from their access to contact information, and Signal has had huge investments made. This despite the obvious fact that it is highly unlikely that Signal would benefit directly from that data in any way. But much Signal's design is taken from the companies that came before, which did.

Re: Twilio incident: What Signal users need to know

#112

Post by dijonman2 »

A4ET8a8uTh0 wrote: post #70
uncomputation wrote: post #47

Yes, Signal’s phone number requirement is bad. But, given that, the fact that they don’t store any messages on their side and everything is client side is still a huge benefit over a lot of other apps and still a huge step forward for privacy! Criticism is definitely important but I just wanted to put that out there that all things considered, Signal is still very much a good thing.

I will admit that this requirement always confused me. What is there to benefit from by requiring it?

It also pushes fraud detection up the pipeline to mobile operators.

Re: Twilio incident: What Signal users need to know

#113

Post by marshray »

beefee wrote: post #21

Please, stop using phone numbers. There is no reliable way to hold a phone number. The messaging protocols are insecure. If your service uses phone numbers or SMS, that means it's not secure or reliable.

What identity token would you prefer?

Would it be bound to the mobile device in any way?

Would it require that a canonical list of registered identities be stored server-side?

How would you impose a cost on spam accounts without burdening users?

Just a few considerations.

Re: Twilio incident: What Signal users need to know

#114

Post by dont__panic »

emmelaich wrote: post #62

The phishing against Twilio looks very much like the attempt on Cloudflare. I wonder how many other companies have been successfully phished that we don't know about.

It certainly makes me wonder: it Twilio more competent because they noticed a phishing success? I assume there are plenty of people at every company who could fall for social engineering scams, so I think it's safe to say most companies aren't totally safe -- they just haven't noticed a major breach.

Re: Twilio incident: What Signal users need to know

#115

Post by dvzk »

tialaramex wrote: post #98
dvzk wrote: post #53

Earlier quoted context omitted.

It was because of over-represented complaints about phone number requirements that Signal implemented the mistake that is SGX and server-side contact lists. Now the social graph of millions of Signal users is instead centrally protected by Intel's attestation obfuscation and a weak 4-digit PIN. All to eventually support usernames, which normies won't use.

> 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.

Re: Twilio incident: What Signal users need to know

#116

Post by xorcist »

spullara wrote: post #54
teraflop wrote: post #38

Earlier quoted context omitted.

After countless discussions of Signal on HN, I have yet to see an explanation for why Signal can use phone numbers from a client-side contact list, but not email addresses from a client-side contact list. Surely, in either case the identifier can be treated as an opaque string, right? Or in other words: suppose the definition of "phone number" was expanded to include alphanumeric characters and @. What aspect of Sign…

People don't have email addresses in their contact lists because all their email contacts are stored on Google servers.

Having the ability to identify by other strings than "phone number" wouldn't take away any functionality, just add it. It would be possible to communicate with devices that have email but not phone numbers (children without SIM cards, for example).

But this is all moot because phone numbers aren't just opaque binary strings. They are more useful than other forms of identification.

Re: Twilio incident: What Signal users need to know

#117

Post by tialaramex »

emmelaich wrote: post #62

The phishing against Twilio looks very much like the attempt on Cloudflare. I wonder how many other companies have been successfully phished that we don't know about.

Yes, Cloudflare pointed out the similarity and they suppose it's a single attacker with multiple targets.

If you have access (I don't in my current role and I don't care enough to spend money to do this on my own account) you can ask a passive DNS system about names like cloudflare-okta.com that were used in the Cloudflare attack, identify patterns (same registrar, same hosting, that sort of thing) and also the IP addresses Cloudflare listed.

You should probably assume that anywhere which doesn't actually have FIDO or similar and was actively targeted is screwed, because it only takes one lapse to let the bad guys in.

Re: Twilio incident: What Signal users need to know

#118

Post by daneel_w »

niel wrote: post #107
daneel_w wrote: post #86

Earlier quoted context omitted.

Every inbound message is authenticated, and credentials are stored somewhere . Correct me if I am wrong, but I'm betting that it's with the same credential/channel as for logging-in a user (aka "sender"). Also, wasn't "sealed sender" broken (again) earlier this year by a group of researchers?

No, sealed sender messages are not authenticated. The sender's client uploads two things: 1) an encrypted message (with sender id encrypted), and 2) a zero-knowledge proof that the sender's client knows the recipient's delivery token. There is no authentication by the sender, and the sender does not upload any credentials.

I guess I have to rephrase myself: the API calls are authenticated, because the API endpoints will not consume anonymous requests. I'd be glad if you could point me to documentation proving that the messaging API uses completely different credentials than those for user login, and that the two are also disassociated.

Re: Twilio incident: What Signal users need to know

#119

Post by notpushkin »

godelski wrote: post #82
AdmiralAsshat wrote: post #3

Maybe this will make Signal re-think their hard requirement of a phone number to register for Signal. ...eh, who am I kidding?

I think they are. I just also think the problem is a lot harder than people give it credit for. If they just go with a standard username (as in some form of a database lookup) then I'll be upset. But I'll be upset because this effectively doesn't solve any issue, and introduces others that have big privacy impacts and requires Signal to be a trusted source (which is antithetical to Signal's proposed mission). I do wi…

Signal is a trusted source already – you trust them telling you which number is which user.

Re: Twilio incident: What Signal users need to know

#120

Post by lxgr »

ajmurmann wrote: post #81
dvzk wrote: post #53

Earlier quoted context omitted.

It was because of over-represented complaints about phone number requirements that Signal implemented the mistake that is SGX and server-side contact lists. Now the social graph of millions of Signal users is instead centrally protected by Intel's attestation obfuscation and a weak 4-digit PIN. All to eventually support usernames, which normies won't use.

Why are server-side contact lists needed to support identities not linked to phone numbers?

Signal (or, more accurately, one of its predecessors) used to use client-side private set intersection for contact discovery, but this scales poorly [1].

Now they use a solution based on Intel SGX and server-side trusted computing [2].

[1] https://signal.org/blog/contact-discovery/

[2] https://signal.org/blog/private-contact-discovery/

Post reply on HN