“Super secure” messaging app leaks everyone's phone number
275 comments
·December 15, 2025josh2600
heavyset_go
I don't think it's cool at all, a secure messaging app should not require personal/tracking identifiers like phone numbers in the first place.
maqp
The sad part is, that's what's keeping Signal safe from spam.
Also, average Joe is not using proxy to hide the IP-address of their device so they leak their identity to the server anyway. Signal is not keeping those logs so that helps.
Messaging apps cater to different needs, sometimes you need only content-privacy. It's not a secret you're married to your partner and you talk daily, but the topics of the conversation aren't public information.
When you need to hide who you are and who you talk to (say Russian dissident group, or sexual minorities in fundamentalist countries), you might want to use Tor-exclusive messaging tools like Cwtch. But that comes at a near-unavoidable issue of no offline-messaging, meaning you'll have to have a schedule when to meet online.
Signal's centralized architecture has upsides and downsides, but what matters ultimately is, (a) are you doing what you can in the architectural limitations of the platform (strong privacy-by-design provides more features at same security level), and (b), are you communicating the threat model to the users so they can make informed decision whether the applications fits their threat model.
coppsilgold
If you intend to use SMS (phone numbers) as a resource constraint (sign up requires 'locking up' a resource that is worth at least a few cents) then at least you can offer a ZKP system where the 'consumed' phone number is not tied to an account. You could also offer to accept cryptocurrency for this function - call it a donation.
That Signal did none of those things implies that privacy was not their objective. Only secure communications was.
It's possible that the reason behind their anti-privacy stand is strategic, to discourage criminal use which could be used as a vector of attack against them. Doesn't change the fact that Signal is demonstrably anti-privacy by design.
kragen
If you wanted to keep it safe from spam, you'd use a proof-of-work scheme using a memory-hard hash function like scrypt, or a Captcha, or an invite-code system like lobste.rs or early Gmail. Signal's architects already knew that when they started designng it.
overfeed
Security and usability are frequently at odds. The ease with which users can discover and exchange messages with their contacts is a major usability issue. Phone number as a proxy for identity mostly works, at the cost of some privacy risks.
soulofmischief
This made sense when Signal/TextSecure allowed users to send regular SMS, making it easy to convince others to set it as their default messenger.
Now that this crucial adoption feature has been removed, it makes zero sense for Signal to continue to rely on phone numbers. Since that feature has been removed, the utility of Signal has been lost anyway and many in my groups returned to regular SMS. So the system is already compromised from that perspective. At least forks such as Session tried to solve this (too bad Session removed forward secrecy and became useless)
robot-wrangler
Signal blasted my whole contacts list the day I signed up so that I was surprised to see lots of people saying "finally you got signal". That was also the moment I uninstalled the app. Leaking contact info appears to be part of the design.
Should have deleted my account instead of just removing the app, because it turns out the difference between using signal and using SMS is obscured for most phones, and when people thought they were texting me they weren't. I was just out of contact for a long time as people kept sending me the wrong kind of messages. I suppose one could argue protecting contact/identity is not a real goal for e2e encryption, but what I see is a "privacy oriented" service that's clearly way too interested in bootstrapping a user base with network effects and shouldn't be trusted.
mmooss
> Leaking contact info appears to be part of the design.
Those people already had your contact info, probably.
Also, I think there is a setting in Signal to prevent that - and via the OS you can block Signal's access to your contacts, of course.
guizadillas
The people that already had your contact info in their devices were notified that you joined Signal via that contact info?
Seems like it was working as designed, if you don't want any app to get your contact info don't share your contact info to anyone ever. Eventually they will share that info with any app.
immibis
When someone on your contacts list gets Signal, Signal displays this in its UI. I don't think this is a privacy violation. Signal aims to hide your messages, but it does not have its own contacts system, and piggybacks on your existing phone number and phone number contacts. Nor does it attempt to hide the fact you have Signal.
stavros
What's more secure? A moderately secure messaging app all your friends have installed, or a very secure messaging app nobody else has?
K0balt
I agree, but since a messaging apps utility is some fraction of the square of the # of users on the platform, a facile way to propagate virally is a de facto requirement for an app targeting wide spread adoption / discovery rather than targeted cells of individuals focused around a pre shared idea.
It’s a compromise meant to propagate the network, and it has a high degree of utility to most users. There are also plenty of apps that are de-facto anonymous and private. Signal is de facto non-anonymous but private, though using a personally identifiable token is not a hard requirement and is trivial to avoid. (A phone number of some kind is needed once for registration only)
immibis
Signal's security model does not include metadata, and this is a valid design.
0x1ch
There's no alternative to reduce spam and fake accounts, unless we collectively are fine with blocking Russia, India, China, and friends from the internet.
codedokode
Does Signal protect from the scheme when the government sends discovery requests for all existing phone numbers (< 1B) and gets a full mapping between user id and phone number?
While slightly unrelated, I thought, how we can fix this for truly secure and privacy-aware, non-commercial communication platforms like Matrix? Make it impossible to build such mapping. The core idea is that you should be able to find the user by number only if you are in their contact list - strangers not welcome. So every user, who wishes to be discovered, uploads hash(A, B) for every contact - a hash of user's phone number (A) and contact's phone number (B), swapped if B < A. Let's say user A uploaded hashes h(A,B) and h(A,C). Now, user B wishes to discover contacts and uploads hashes h(A, B) and h(B, D). The server sees matching hashes between A and B and lets them discover each other without knowing their numbers.
The advantages:
- as we hash a pair of 9-digit numbers, the hash function domain space is larger and it is more difficult to reverse the hashes (hash of a single phone number is reversed easily)
- each user can decide who may discover them
Disadvantages:
- a patient attacker can create hashes of A with all existing numbers and discover who are the contacts of A. Basically, extract anyone's phone book via discovery API. One way to protect against this would be to verify A's phone number before using discovery, but the government, probably, can intercept SMS codes and pass the verification anyway. However, the government can also see all the phone calls, so they know who is in whose phone book anyway.
- if the hash is reversed, you get pairs of phone numbers instead of just one number
Arathorn
There's some really interesting stuff we've been looking into on the Matrix side to solve this - e.g. https://github.com/asonnino/arke aka https://eprint.iacr.org/2023/1218 or https://martin.kleppmann.com/2024/07/05/pudding-user-discove....
Meanwhile, Matrix for now does support hashed contact lookup, although few clients implement it given the privacy considerations at https://spec.matrix.org/unstable/identity-service-api/#secur...
heavyset_go
The hash space for phone numbers is so small that you can enumerate them all.
godelski
Signal publicly shares government requests AND the data that they send them
The data Signal has is: 1) registration time for a given phone number, 2) knowledge of daily login (24hr resolution). That's it. That's the metadata.
They do not have information on who is communicating with who, when messages are sent, if messages are sent, how many, the size, or any of that. Importantly, they do not have an identity (your name) associated with the account nor does that show for contacts (not even the phone number needs be shared).
Signal is designed to be safe from Signal itself.
Yes, it sucks that there is the phone number connected to the account, but you can probably understand that there's a reason authorities don't frequently send Signal data requests; because the information isn't very useful. So even if you have a phone number associated with a government ID (not required in America) they really can only show that you have an account and potentially that the account is active.
Like the sibling comment says, there's always a trade-off. You can't have a system that has no metadata, but you can have one that minimizes it. Signal needs to balance usability and minimize bots while maximizing privacy and security. Phone numbers are a barrier to entry for bots, preventing unlimited or trivial account generation. It has downsides but upsides too. One big upside is that if Signal gets compromised then there's can be no reconstruction of the chat history or metadata. IMO, it's a good enough solution for 99.9% of people. If you need privacy and security from nation state actors who are directly targeting you then it's maybe not the best solution (at least not out of the box) but otherwise I can't see a situation where it is a problem.
FWIW, Signal does look to be moving away from phone numbers. They have usernames now. I'd expect it to take time to completely get away though considering they're a small team and need to move from the existing infrastructure to that new one. It's definitely not an easy task (and I think people frequently underestimate the difficulty of security, as quoted in the article lol. And as suggested by the op: it's all edge cases)
codedokode
> Phone numbers are a barrier to entry for bots, preventing unlimited or trivial account generation.
What's wrong with account generation? Nothing. The problem is if they start sending spam to random people. So we can make registration or adding contacts paid (in cryptocurrency) and the problem is gone.
mmooss
That doesn't answer the GP question:
> Does Signal protect from the scheme when the government sends discovery requests for all existing phone numbers (< 1B) and gets a full mapping between user id and phone number?
Signal does have the phone numbers, as you say. Can they connect a number to a username?
ruined
yes. users can disable phone number discovery
Groxx
can they disable it before or after it tells other people that they joined, if those other people had their number in their synced contacts list?
(I would be thrilled to learn that this changed, but it has been in place for many years and it's kinda hard to personally test)
wizzwizz4
And it's trivial to reverse a hash in such a scenario. This scheme is completely broken.
jazzyjackson
Still lame that they require phone number at all, it took them a long time to add usernames so you don't have to expose your phone number to a new contact. Still skeeves me out that the account is associated with a SIM at all.
nanomonkey
I agree, but you can mitigate that to some extent by using a phone number that is not linked to your identity.
Phreeli [https://www.phreeli.com/] allows you to get a cell number with just a zip code. They use ZKP (Zero Knowledge Proofs) for payment tracking.
codedokode
In my country, you cannot legally get a phone number not linked to the identity, and the prices are relatively high on the black market. Also, the phone discloses your location with pretty good precision, especially in US where everyone is living in their own house.
HNisCIS
We need an established secure anonymous/subpoena-resistant chat app at this point. Signal is great for a minimal threat model but we're kinda past that now given everything going on.
Simplex was a decent option but they're going down the crypto rabbit hole and their project lead is...not someone who should be trusted by anyone in the crosshairs right now.
integralid
Can you explain more about simplex? I remember reading about it a while ago and being really impressed. Sad to hear the project is going downhill.
01HNNWZ0MV43FF
Maybe DeltaChat?
sneak
Signal accounts do not require a SIM. There is no requirement that the phone you use for running the app Signal has the phone number you use for Signal login.
My Signal number is a Google Voice number that has nothing to do with any mobile phone. The Google account has advanced protection turned on so you can’t port it or get the SMSes without a hardware login token.
the_gipsy
In my country I cannot buy a SIM card / phone number without giving my full identification.
HNisCIS
It's still associated with a credit card and your google account requires another phone number to create.
codedokode
But has something to do with a bank card you used to pay for it?
ronsor
> The server uses a bitwise xor when querying for numbers using hardware encrypted ram. The result is that even if you’re examining the machine at the most basic levels you can’t tell the difference between a negative or positive hit for the phone number unless you’re the phone requesting the api.
Do you have further reading on this?
dathinab
This article https://signal.org/blog/building-faster-oram/ has some details but is more focused on improving their solution other blogs from the are "we want to build this soon" kind of blogs. It seems that most articles about this topic either have too little content to be of interest or are technology previews/"we maybe will do that" articles about things Signal wants to implement, where it's unclear if they did do that or something similar.
To cut it short they use Intel SGX to create a "trusted environment" (trusted by the app/user) in which the run the contact discovery.
In that trusted environment you then run algorithms similar to other messengers (i.e. you still need to rate limit them as it's possible to iterate _all_ phone numbers which exist).
If working as intended, this is better then what alternatives provide as it doesn't just protect phone numbers from 3rd parties but also from the data center operator and to some degree even signal itself.
But it's not perfect. You can use side channel attacks against Intel SGX and Signal most likely can sneak in ways for them to access things by changing the code, sure people might find this but it's still viable.
In the end what matters is driving up the cost of attacks to a point where they aren't worth in all cases (as in either not worth in general or in there being easier attack vectors e.g. against your phone which also gives them what they want, either way it should be suited for systematic mass surveillance of everyone or even just sub groups like politicians, journalists and similar).
LunaSea
I believe that the search term you can look for is constant time equality.
m4rtink
Do we relly know the server actually does this when you can't run your own Signal server instances you have compiled yourself from source code ?
maqp
Short answer is no.
Signal provides content-privacy by design with E2EE. Signal provide metadata-privacy by policy, i.e. they choose to not collect data or mine information from it. If you need metadata-privacy by design, you're better off with purpose-built tools like Cwtch, Ricochet Refresh, OnionShare, or perhaps Briar.
master-lincoln
I thought you could compile from source and run Signal server instances, but there is no federation, so you would need a client that points to your server and you could only talk to other people using that client.
GranPC
They use remote attestation based on SGX. So, assuming SGX can be trusted, yes. See https://signal.org/blog/private-contact-discovery/
dathinab
and assuming you have a practical way to
- verify the attestation
- make sure it means the code they have published is the attested code
- make sure the published code does what it should
- and catch any divergence to this *fast enough* to not cause much damage
....
it's without question better then doing nothing
but it's fundamentally not a perfect solution
but it's very unclear if there even is a perfect solution, I would guess due to the characteristics of phone numbers there isn't a perfect solution
codedokode
> What’s going on in that user object? The pin field seems suspiciously related to the PIN we were asked to input after creating our account
This might be the fault of opt-out serialization library (by default it serializes the whole object and you need to manually opt-out fields from it). So a programmer adds a field, forgets to add opt-out annotation and voilà.
Or they are just using plain JS dicts on the server and forgot to remove the key before using it in a response.
> The vulnerability they’re talking about was presented in a paper by researchers at the University of Vienna.
This vulnerability (mapping phone numbers to user id via rendevouz API) is old and was exploited in 2016 in Telegram [1] and allowed Iranian govt to build a phone book of 15M Telegram users. The paper also mentions that the vulnerability was known in 2012, still not fixed.
Yoric
> This might be the fault of opt-out serialization library (by default it serializes the hole object and you need to manually opt-out fields from it). So a programmer adds a field, forgets to add opt-out annotation and voilà.
In a previous job, on my first audit of the code, I spotted such vulnerabilities pretty much everywhere.
Developers simply need to stop using these libraries.
SchemaLoad
This is such a common issue I've seen in so many API backends, where sensitive fields on a record are getting sent to the client and no one notices because it's invisible in the UI.
Sardtok
The fact that the PIN is leaked is bad enough, but it also happens to be plaintext. This is a password. It should not be stored unhashed, and it should be hashed with strong algorithms.
cbsks
It’s a 6 digit pin. Doesn’t seem worthwhile to hash. What are the best practices here? I’m not sure
dietr1ch
Yeah, you can only delay attacks by a tiny little bit, but the search space of 10^6 is just too small. Salting it doesn't give you much more security.
null
ericmcer
It's crazy how many security vulnerabilities are just people pinging http endpoints in ways they didn't expect. You would think in order to "hack" a system in 2025 you would need to be doing some crazy computer science wizardry but it really is just lazy engineers. Like how do you ship an API and have no rate-limiting. It literally takes a line to implement in Nginx.
thesuitonym
> It literally takes a line to implement in Nginx.
"Yeah but it wasn't in the docker tutorial I skimmed so I have no idea what it means."
verdverm
Soon to be... "Yeah, it was the Ai, I have no idea how any of this works"
serial_dev
Though once s hits the fan, you can just tell AI “I have no idea how any of this works andI don’t really even care but I need rate limiting, so do what you must, I trust you”.
SchemaLoad
At least on the flipside. Code scanning tools are getting increasingly good. We finally moved to github at work and it's scanned the whole repo and pointed out tons of concerning security issues in the code. Not sure if it's powered by AI in any way (I assume not since they would scream from the rooftops if it was) but it's pretty useful.
rainonmoon
Obviously software development in general has become more ingenious (by some metrics) over the past few decades but very little of its growth has involved secure development principles. Often the primary goal is efficiency and scalability with as little friction for the customer. The priority is enabling commerce, not protecting user data (slightly more so company data, but not by much). I speak to devs every week who are unfamiliar with things like JavaScript injection and SSRF, things that can be exploited by virtually complete beginners. From their perspective they were just building a neat feature, that it could be used to render external scripts or internal file paths literally did not occur to them. This isn’t a judgement of them, I appreciate the chance to help them, but just to say development has unfortunately always had other priorities.
Ardren
> It literally takes a line to implement in Nginx.
Lots of things are really simple. But you have to know about them first.
arcfour
I would hardly consider someone that doesn't even know what rate limiting is to be a "developer."
notesinthefield
I once went to a B-Sides talk of a person that paid off their mortgage via API related bounties - you wouldve confused their presentation with a Postman 101 video if you were only half listening.
dathinab
for quite a while I through many of those dump "internal network scanning automatized pentests" where pretty pointless
but after having seen IRL people accidentally overlooking very basic things I now (since a few years) think using them is essential, even through they often suck(1).
(1): Like due to false positives, wrong severity classifications, wrong reasoning for why something is a problem and in generally not doing anything application specific, etc.
I mean who would be so dump to accidentally expose some RCE prone internal testing helper only used for local integration tests on their local network (turns out anyone who uses docker/docker-compose with a port mapping which doesn't explicitly define the interface, i.e. anyone following 99% of docker tutorials...). Or there is no way you forget to set content security policies I mean it's a ticket on the initial project setup or already done in the project template (but then a careless git conflict resolution removed them). etc.
MangoToupe
> You would think in order to "hack" a system in 2025 you would need to be doing some crazy computer science wizardry
Never heard of the wrench technique? It's always gonna work out great. Way cheaper and easier than "wizardy" too.
murderfs
Ratelimiting doesn't solve anything, you can just parallelize your queries across IP addresses.
overfeed
The whole "defense in depth" principle disagrees. Having a layered defense can not only buy defenders time, but downgrades attacks from 100% data exfiltration to <10%
arcfour
Increasing the barrier to entry from "trivial" to "less trivial" is always a good start.
pragma_x
Yup. This is some of the stuff that gets missed when understanding Security.
Ultimately, you're just buying time, generating tamper evidence in the moment, and putting a price-tag on what it takes to break in. There's no "perfectly secure", only "good enough" to the tune of "too much trouble to bother for X payout."
ben_w
> but I like to provide only the best blog posts to my tens of readers
It may not be pertinent to the subject, but clearly I have found a kindred spirit in this author.
password-app
This is why I'm skeptical of any app claiming "super secure" without open-source verification.
The real lesson: assume every service will eventually leak something. Use unique passwords everywhere, enable 2FA, and rotate credentials after breaches.
The tedious part is the rotation. I've seen people skip it because manually changing 50+ passwords is brutal. Automation helps but needs to be done securely (local-only, zero-knowledge).
hypeatei
Does Freedom Chat® have a feature to prevent journalists from joining your group chat? Asking for a friend that works at the DoD (sorry, DoW)
Arch485
If I had a nickel for every "secure" app that handled sensitive user data and then subsequently leaked that data this year...
I'd only have 20 cents, which I guess is good. But I'm sure there's more I'm forgetting.
Related:
[1] https://news.ycombinator.com/item?id=44684373
sigwinch
For this specific movement, venturing outside Facebook Messenger is an important cue.
null
lawlessone
and these are just the ones we know about
CodingJeebus
I stumbled upon a GOP jobs board a year ago that stored submitted job applications in the same search index as the job listings themselves, so all you had to do was search "bob" and find a bunch of resumes and application answers for people who had applied, I couldn't believe it.
tonymet
Which one ?
CodingJeebus
gopjobs.com, looks like it’s been fixed though
tonymet
i tried to see if it has any ties to the actual GOP national or any state parties and it's unclear. I'm guessing it's not affiliated and GOP is not trademarked.
I asked because both political parties have chapters at national, regional, state & local levels so "GOP job board" on the face wasn't clear which organization was running it. Some parties cover rural counties of just a few thousand people.
sigwinch
Since Anom, we need a new word than “honeypot”. The next secure messenger will not be created by these types. But many will be incrementally marketed, and each campaign will succeed in reaching a new batch of near-hit recruits.
agentifysh
we have so many failure-as-a-feature ops these days im surprised we aren't discussing it more. something that consistently happens with enough frequency without any repercussions ultimately just becomes a feature of its own.
we consistently have data breaches in institutions we trust is converging to a point where its literally just a data harvesting ops and everybody stops caring. They won't even bother to join class action lawsuits anymore because the rewards enrich the lawyers while everybody gets their twenty bucks in the mail after providing more personal data to the law firm its like a loophole.
we now have legalized insider trading in the form of "prediction markets", legalized money laundering and pump and dump through crypto, all of these always lead to failures for the participant disguised as wins.
burnt-resistor
"Petepot"
pavel_lishin
> 2025-12-09: Freedom Chat notifies us issues have been patched
Have they?
fn-mote
I’m glad “super secure” is in scare quotes.
I’m glad I have never heard of this app.
Security and trust go hand in hand.
higginsniggins
When you go the website the first line is literally “Say hello to Freedom Chat—a next-generation messaging app that keeps your conversations actually private
Bengalilol
... and then you encounter things like "Privacy’s been lost. We’re here to take it back." or "World-class security".
It looks like "Freedom" is a sure thing.
This is why signal’s encrypted phone number lookup system is so cool. The server uses a bitwise xor when querying for numbers using hardware encrypted ram. The result is that even if you’re examining the machine at the most basic levels you can’t tell the difference between a negative or positive hit for the phone number unless you’re the phone requesting the api.
Obviously ratelimiting is a separate and important issue in api management.
The thing about building secure systems is that there are a lot of edges to cover.