Nostr Web Client

⚠️Nostr practical security — attack vulnerabilities ⚠️

Researchers’ quote:

" Our results on Nostr show that their use of cryptographic technologies is simple and immature, showing a sharp difference from the modern messaging applications that the research community has scrutinised.

We think there is a significant lack of understanding on the secure design and analysis of distributed SNSs: what security property should be set, and what about the security of popular growing services other than Nostr, such as Mastodon and BlueSky? "

A new research paper (Aug 2025) analysed Nostr and found basic cryptographic and design weaknesses that allow attackers to abuse the protocol in ways that real users and services should be concerned about.

👉In plain terms:

attackers can trick clients and servers, steal funds or impersonate users in practical scenarios unless fixes are applied.

👉Key impacts everyone must know

1) Financial risk — attackers can hijack or manipulate keys or requests, causing loss of funds (wallet integrations, invoice relays, LN payflows).

2) Account and reputation risk — impersonation and message forgery can damage user identity, enable scams, or undermine trust models.

3) Ecosystem availability and privacy risk — attacks can de-anonymise users or flood/poison relays, degrading service and exposing metadata.

👉Call to action for developers and users

- Developers: audit signing and verification flows, wallet integrations, relay filtering and threat models; prioritise fixes for key handling and message-authentication weaknesses.

- Users: assume higher risk for money-related actions; avoid new integrations until maintainers publish mitigations; verify payments and identity out-of-band.

Looping in relevant parties below. Regardless of whether the source is trustworthy, the attacks described are worth investigating.

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955 nostr:npub16vjln603hfsfhremp627jle4ycm6p23grjjqrm04rrdwupldyfnsjx88a2

Link to the research listing (paper referenced): 👉 https://eprint.iacr.org/2025/1459.pdf

#asknostr #plebchain #plebs #nostr nostr:note1s2tnt9zenqegldv6uvyc5pmf5hdrzhx9faatqmyhlpu7lnredy8q2lmu76

Reply to this note

Please Login to reply.

Discussion

ཀռօֆ🝤ʀǟɖǟʍɨᶻ 𝗓 𐰁 2mo ago

A times I have a feeling its per design.

Lady Mae - Growth Teacher 2mo ago

let's hope it's not. hence, copying those people. ☺️

ابو مريم 2mo ago

CC: nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8 nostr:npub175nul9cvufswwsnpy99lvyhg7ad9nkccxhkhusznxfkr7e0zxthql9g6w0

alp 2mo ago

Thanks! That’s really valuable. I’ll go ahead and implement the checks and steps mentioned in it right away.

Lady Mae - Growth Teacher 2mo ago

ty and would love to hear your thoughts on the vulnerabilities/fixes for the wider audience too. 🫂 as this is publicly available, we are not sure how many people did the testing and the feasibility of it. we appreciate your help and hard work. ☺️

ابو مريم 2mo ago

I think it is mostly older. Some of this stuff with nip4 and Damus patches is known. Figured it would be good to review though as you build

Lady Mae - Growth Teacher 2mo ago

indeed. there is no harm checking and be vigilant than sorry. esp if given enough time and resource, it will only take 1 malicious act to screw things up for the network 😬

Vitor Pamplona 2mo ago

Old paper, but this is why we don't use NIP04 DMs anymore. Also, I don't understand why would anyone say that Nostr has an issue if they only test a couple clients, mostly Damus. Clients might have a lot of problems. But those are not Nostr problems. They are that specific clients issue. They should have said that. They seen to think the way Damus does things is Nostr itself, which is dumb. Either they don't know how the Nostr ecosystem works or they are intentionally misleading people.

Lady Mae - Growth Teacher 2mo ago

I can see your point. Out of curiosity, there are few practical attacks in there mentioned both in client and server imolementations and protocol specifications. Regardless whether the paper is old, it would be interesting to know if the dev community looked into them esp the nip01 manadatory implementations. The bigger risk mentioned is the vulnerability 1 which is in protocol level and this paper is open for public to view. 😬

Vitor Pamplona 2mo ago

Thats not a problem of nostr. In order to pull of that attack, they will need to change the event and recreate the event ID that matches the signature. That is impossible with today's computers. So much so that they could not create ANY event to explore that vulnerability.

They are only describing it because of vulnerability 2, when Damus wasn't verifying events they receive. That was fixed a while back on the Damus clients.

To this date, nobody was able to actually do Vulnerability 1. Even if you use the entire hash power of the Bitcoin network, you still cannot do it.

Lady Mae - Growth Teacher 2mo ago

I see. the paper claimed that nostr relay operators can do this type of attack bcoz of lack of verification from the server end. genuinely curious to understand, are we saying that each event are verified in the server end (relay side) therefore, this attack cannot be done? Eg. No way relay operators can forge an event in the server side? ty

Vitor Pamplona 2mo ago

Even if they don't verify, we all verify on the client side and discard if the signature doesn't match.

But no, relay operators cannot do this. If they could, they would also be able to create Bitcoin transactions on the blockchain, since nostr uses the same cryptography tool. There is 2 trillion dollars of money to anyone that can do that. :)

Lady Mae - Growth Teacher 2mo ago

that is a relief ppphhheeewwww sweat averted ty as always 🫂

Garbage nsec 2mo ago

An example of a protocol (and not client) concern is that if someone has your nsec you generally have no way of knowing. I could have your nsec right now, I could be reading your DMs (unless MLS), and I could continue to do for the next months or years, you'd have no real way of knowing I'm doing this unless I slip up and publish something with your nsec and you see that (which, if I was using a special client, would be unlikely) or some elaborate relay sting.

This sucks because the moment you suspect your nsec mave have been exposed, even if just a small chance, you then have to assume it has been and start on a new one, since there's no way to check the history as you can do with other platforms.

The more Nostr moves to Web of Trust the more it benefits the attacker (the knower of the exposed nsec) to just wait and let you build trust on your compromised account, over months or years, because that trust will be useful to cash out as some point in future.

fiatjaf 2mo ago

You do have a way of knowing: if your DMs are going to a semi-trusted relay and you have to AUTH to it in order to read them (as you should under NIP-17) that relay may inform you about who has read them, when and from what IP address.

If we implement https://github.com/nostr-protocol/nips/pull/1647 that will also kill the attacker ability's to read anything in the first place unless he wants to reveal himself by registering his bogus device or publishing new encryption keys.

Garbage nsec 2mo ago

Agree those are potential fixes for NIP17 DMs, albeit they rely on all the things you mentioned. How many people are going to exclusively use auth-enabled relays with IP access alerts? And those alerts could also work backwards and inform the attacker of the true holder's IP, which needs to be accounted for. I mean it's all doable but these dumb relays sure are getting pretty smart.

fiatjaf 2mo ago

Clients should nudge users towards using such relays for DMs, and that is happening right now in every client.

Relays were never meant to be dumb in the sense that they wouldn't have any internal logic, that was an unfortunate choice of words and a huge misunderstanding that damaged Nostr a lot, it's a surprise to me that people could have thought a relay would be really that dumb, do no filtering, no access control etc and Nostr would still work? Nostr would never work if it was like that.

Garbage nsec 2mo ago

That's fair.