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

451–460 of 512 posts

Re: Twilio incident: What Signal users need to know

#451

Post by sandgiant »

g_sch wrote: 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…

Interesting idea. The number could also be an attempt to cover up their actual intention of targeting specific users.

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.

Re: Twilio incident: What Signal users need to know

#452

Post by lrvick »

dcow wrote: post #223
lrvick wrote: post #154

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. If you learn a contact phone number then you can buy their location history. Requiring phone numbers and requiring you share them with everyone you contact is brain dead. This alone is bad enough to abandon Signal but then consi…

How does signal allow you to learn someone's phone number from message history? As far as I understand the only thing one can learn by inspecting signal's protocol is that: 1. generally, a certain phone number uses signal (1) happens once, upon registration of your phone number. You don't see history of which phone numbers are communicating, do you? In other words, you don't need Signal to buy someone's location hist…

Sadly the protections you mention are only true if we ignore the last decade of security research and dragnet surveillance activity. Metadata protection in Signal has major asterisks they do not like to talk about which could be activated covertly by warrant, threats, or money.

1. Google, Apple, or Signal could, compile a malicious Signal binary that generates weak keys and deliver it to specific users, or all users, via app stores.

2. Signal sysadmins or third party datacenter techs could use any of a pile of SGX exploits to dump all their centralized metadata in plain text.

3. Signal aggregates all IP metadata to one place making it easy for their cloud providers and ISPs to work out who is talking to who.

4. Carriers see SMS activations and know who uses Signal. They also know all of the cellular data IPs. An entity that buys this along with data from other ISPs would quickly learn the identities of most conversation participants and their current locations. Enrich that with data widely sold from drivers license office and you also get race, home address, etc, etc.

Centralized PII requiring services that claim to be promoting security and privacy should be met with extreme scrutiny.

Re: Twilio incident: What Signal users need to know

#453

Post by dcow »

dcow wrote: post #425
stormbrew wrote: post #400

Earlier quoted context omitted.

> I genuinely believe there is a lot of commentary on this thread from people who have never designed a secure system. Gosh that's quite the conclusion. I hope my employer never finds out about this discovery of my competency based on some comments on a message board. I think you've very much lost the thread of what I'm saying here, because at no point have I suggested anything about 100% security or 100% privacy. It…

That comment wasn't directed at any single individual. There's just been a lot of "I imagine you can just type in a username and that would all work, QED. Duh." type of comments across the board, hence my broad statement. I agree Signal could add email addresses specifically, if verified and it wouldn't affect the threat model outside of introducing the network to more spam-able identifiers. Like I've said, if they f…

I've been reading up on the state of things. So Signal actually is working to remove the phone number requirement: https://twitter.com/moxie/status/1281353114063257600?s=20&t=...

They've been working on it for years. Their solution is that they have to take client-side ownership of your contacts list, keep it associated with your "account" and sync it across your devices so that when you correspond with someone by username, it becomes available to you everywhere. They have to be your contact book. I can find nothing on how they plan to verify usernames, perhaps in the traditional style with email.

So yeah, absolutely not some trivial change that they just don't want to do because fuck the few people that don't have a phone number (or don't want to use it). They're working toward supporting usernames and at every turn keep getting reamed by HN because, in their effort to solve a problem that only exists on HN, they have to deploy a solution that means you have to trust them in a teeny tiny way you didn't previously IF you set a weak pin on your account. It's mind boggling. It must be so disheartening to see that type of response.

But, that's my point. Signal can't add short names without changing the fundamental trust model which appealed to everybody initially. No amount of hiding a password as a pin, will change that. I really hope they don't kill their product along the way...

(Also man WTF they're running Raft on SGX enclaves just so they can rate limit attempts to brute force users' weak pins. While super cool, technically, what an incredible waste of resources just to try and make weak passwords okay. Probably the most backwards thing I've seen a security company attempt like ever. Just tell your users if they want a username they need a strong password. Or just generate the entropy for them and only allow the username option to people who also want to take custody of their new 32-bytes of entropy and have a signal-managed synced contact book.)

Re: Twilio incident: What Signal users need to know

#454

Post by baby »

int_19h wrote: post #354
dublinben wrote: post #306

Earlier quoted context omitted.

>Numbers are like dynamic IPs Maybe for you. For other people who have had the same phone number for years or decades, they're the one of the most persistent forms of communication or identification available.

The ability to transfer phone numbers when changing mobile provides has been around for a very long time in US, but it wasn't the case in some other countries until recently.

Even then personally I moved abroad so many times that it just doesn't make sense to use phone numbers. Not everyone stays in the same place all their life

Re: Twilio incident: What Signal users need to know

#455

Post by scbrg »

vgel wrote: post #337
gsdofthewoods wrote: post #194

Earlier quoted context omitted.

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.

380 devices / minute would imply Signal is adding 547,200 users / day, or 199,728,000 users / year. That seems way too high. Granted some could be multiple devices per user, but still...

If by some you mean... quite a lot?

I've registered dozens of devices, since the account pairing expires after five minutes (ok, slight exaggeration).

Re: Twilio incident: What Signal users need to know

#456

Post by mikro2nd »

tptacek wrote: post #233
Iv wrote: post #214

Earlier quoted context omitted.

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 t…

Interesting work in this space is being done by OpenPrivacy with their "cwtch" app. An express design goal is to minimise side-channel leakage of information.

Re: Twilio incident: What Signal users need to know

#457

Post by hayst4ck »

hammyhavoc wrote: post #374
hayst4ck wrote: post #338

Earlier quoted context omitted.

I installed signal and it worked. I told a friend to install signal and it worked. I told my mom to install signal and it worked. The interface was basically the same. Any friend who installed it appeared the same way they would appear in WhatsApp. I didn't have to teach any of these people anything to get them to use it. I didn't have to talk them into making an account to use it. That is what I mean by drop in. It'…

This is as daft as Googling "email" and expecting a de facto client. You're on HN, it's nerdville, expect more interest in the protocol than clients. People search for "email clients. Try searching for "Matrix clients". Element is the best thus far, IMO. "Widespread adoption" includes the EU's military, healthcare and government, so I wouldn't be so certain you'll end up being right. It's hit 60m publicly addressable…

I think we meant different things when we said "drop in replacement" and therefore were referencing different ideas of what makes something a "drop in replacement," which is why it sounds like there are feelings of goal posts shifting.

If the messages are still sent via Facebook servers, that is not a WhatsApp replacement, it's an alternative WhatsApp Client, it's still at it's core "performing" WhatsApp. It is not a WhatsApp replacement, but a WhatsApp client replacement. I moved to signal specifically to sever my relationship with Facebook because I don't trust Facebook. Not communicating with Facebook is the feature that made signal appealing and made me want to replace WhatsApp (not the client, but the service as a whole) with something else.

I think conflating the idea of replacing "WhatsApp the service" and replacing "the WhatsApp Client" is the crux of our talking past each other and why my focus is on how it's UI compatible and ignoring the idea of protocol compatibility.

> You're on HN, it's nerdville, expect more interest in the protocol than clients.

We are on HN, and it's nerdville, it's true. It is the place where the very same comment (rsync files around) I am using to criticize the hubris of nerds (myself included) was made. (https://news.ycombinator.com/item?id=8863). Plug and Play (referenced in the HN link) is a winning idea. The crux of my statements here is how amazingly plug and play signal is, specifically for WhatsApp users.

> This is as daft as Googling "email" and expecting a de facto client.

I am saying this in good faith and I hope you take it as a good faith comment and not an aggression, but have you googled "email"? I understand the point you were making and I think it applies to a lot of other protocols, but googling "email" returns gmail 1st and 2nd, then outlook 3rd. Wikipedia is the 4th result...

> Try searching for "Matrix clients". Element is the best thus far, IMO.

I hate to respond so directly to this too, but have you googled "matrix clients" because I did, and I am pretty confident the results don't prove the point you wish to be proven. The number 1 result is the matrix website matrix client page I had already found by searching "matrix app". The second and third results are top 10 lists. The 4th result which you have to scroll down to see is Element. How do top 10 lists outperform clients themselves? That paints a pretty bleak picture for the difference in quality between the best app and the worst app.

Engineers have a way of being arrogant when they think the thing they have is technically superior or have a grand vision. Betamax was better right? Being protocol first over customer first, to me, is a form of hubris. The customer experience is what wins, everything else is just an implementation detail for the vast majority of people, even engineers.

> Widespread adoption" includes the EU's military, healthcare and government, so I wouldn't be so certain you'll end up being right. It's hit 60m publicly addressable accounts, which doesn't include any private servers or any kind of healthcare, gov or military: https://news.itsfoss.com/matrix-sixty-million-users/

This is definitely interesting and something I find worth considering. I certainly have an American-centric view. Clearly it's in every countries best interest not to have all their communication going through foreign servers, so the idea of Europe migrating to their own chat, much like Korea chose Kakao, doesn't surprise me. I kind of suspect that the idea of federating chat before the balkanizing of it might be too forward thinking/pre-mature.

> EU is forcing interoperability standards.

It will be interesting to see if American fights this or embraces it.

> I have a gut feeling that you will look silly in five years time

I would not be surprised to see Element, for example, become the most popular client and obvious choice. All the comments, FAQ's, etc, already seem to acknowledge Element is the right choice, but the structures that make it easy to download (google ranking result, links from the main matrix page, people saying "use Element," not "use Matrix") are not yet in place. When Element eclipses Matrix or Matrix starts being talked about outside the context of chat apps I'll start to take matrix seriously. Certainly my criticisms are not based on immutable flaws, but what I think are strategic blunders.

As a final note this is directly from the matrix website:

  Empowering the end-user
    The user should be able to choose the server and clients they use
    The user should be able to control how private their communication is
    The user should know precisely where their data is stored
This means the user has to be informed about servers and clients, the user has to be informed about communication privacy levels, and the user needs to be informed about what data is and where it lives. While that might be nice, it's even more nice to trust someone to solve these problems for you so you can best think about how to spend quality time with the people you appreciate in your life, not the security level of your data.

`sum(dilemma) + sum(onboarding/required knowledge) <= resistance`. anything for which `reward < resistance` will probably not succeed. That's my calculus. Minimize choice, minimize required knowledge/onboarding, maximize reward. That is a winning combo. I don't think matrix is optimizing for that. I guess we'll see if I have to find the flaw in my reasoning or not in 5 years.

Re: Twilio incident: What Signal users need to know

#458

Post by autoexec »

dcow wrote: post #450
autoexec wrote: post #418

Earlier quoted context omitted.

Basically, they planned to get around much of the problem by depending on a very insecure secure enclave to make up for a lack of basic sound security practices. The scheme they came up with to store user data in the cloud was described here: https://signal.org/blog/secure-value-recovery/ The code is here: https://github.com/signalapp/SecureValueRecovery This site does a pretty good job of explaining why this isn't a…

They definitely do not encrypt your data with a 4 digit pin. They use Argon2 (a slow hash, not that it matters specifically here since the security depends largely on the entropy) to derive a 32-byte key. Then they derive subkeys: an auth key, and part of a final encryption key. The other part of the encryption key is 32-bytes of entropy. You store your entropy in an SGX enclave with a limited number of attempts allo…

I did oversimplify their encryption scheme, but the issue is that in the end you still only need a pin to get the unencrypted data. I agree that if they'd been honest about passwords and the need for a strong one this wouldn't be as big an issue. It's because they were not honest that I don't think it's fair to expect their users (even the security nuts) to do it. Their target demographic will include whistleblowers and journalists who aren't necessarily all that tech-savvy.

The strengths and weaknesses of SGX are debatable, I may lean on the pessimistic side, but as you say it impacts the security model of Signal users and to me that means they (and new users) should be clearly informed. The first line of their privacy policy says "Signal is designed to never collect or store any sensitive information." which is demonstrably false.

As for opting out, unless something has changed they still store your data on the cloud, it's just handled differently:

https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin...

I don't know what options someone has after they've already created a pin, if there's a way to remove your data from the cloud, I stopped using signal before they forced the pin (back when you could still just ignore the notice) and getting real answers to these kinds of basic questions is way more difficult than it should be. This is, again, a service targeting very vulnerable people whose lives and freedom may be on the line.

I was one of those Signal users who wanted them to move away from requiring a phone number too. That said, what I was looking for was something more like Jami. They managed to create a system with usernames and passwords but without phone numbers or accounts keeping your data in the cloud.

I'm not shitting on Signal's efforts overall. A lot of great work went into Signal and I'm pissed I still haven't found a good replacement for it, but the changes they made hurt the security and safety of the people who depend on Signal. They are a massive intelligence target and I can't blame them for anything they were forced to do, and if their goal was to subtly drive people away by raising a bunch of red flags I thank them, but if this is their best effort at communication and building trust how charitable can they expect us to be when two years later so many of their users don't have a clear idea of what's being collected and stored or what that means for their safety?

Re: Twilio incident: What Signal users need to know

#459

Post by hammyhavoc »

hayst4ck wrote: post #457
hammyhavoc wrote: post #374

Earlier quoted context omitted.

This is as daft as Googling "email" and expecting a de facto client. You're on HN, it's nerdville, expect more interest in the protocol than clients. People search for "email clients. Try searching for "Matrix clients". Element is the best thus far, IMO. "Widespread adoption" includes the EU's military, healthcare and government, so I wouldn't be so certain you'll end up being right. It's hit 60m publicly addressable…

I think we meant different things when we said "drop in replacement" and therefore were referencing different ideas of what makes something a "drop in replacement," which is why it sounds like there are feelings of goal posts shifting. If the messages are still sent via Facebook servers, that is not a WhatsApp replacement, it's an alternative WhatsApp Client, it's still at it's core "performing" WhatsApp. It is not a…

FWIW, everybody has different results on Google. They vary between mobile and desktop, regionally, and can even be personalized.

Re: Twilio incident: What Signal users need to know

#460

Post by hayst4ck »

hammyhavoc wrote: post #459
hayst4ck wrote: post #457

Earlier quoted context omitted.

I think we meant different things when we said "drop in replacement" and therefore were referencing different ideas of what makes something a "drop in replacement," which is why it sounds like there are feelings of goal posts shifting. If the messages are still sent via Facebook servers, that is not a WhatsApp replacement, it's an alternative WhatsApp Client, it's still at it's core "performing" WhatsApp. It is not a…

FWIW, everybody has different results on Google. They vary between mobile and desktop, regionally, and can even be personalized.

Are you saying your results are different?
Post reply on HN