Nostr Web Client

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

If I ask to verify a finalized event but change content and/or created_at, anything at all actually... shouldn't the verification return false?

Or am I missing something huge? :/

```js

const secretKey = generateSecretKey()

const now = Math.floor(Date.now() / 1000)

const event = finalizeEvent({

kind: 1,

created_at: now,

content: 'hello',

tags: [],

}, secretKey)

const isGood = verifyEvent({...event, created_at: now - 10, content: 'something else'})

expect(isGood).toBe(false)

```

fiatjaf 1y ago

It should indeed return false, but what the library does is it stores a thing in the object saying it is verified. You are not supposed to edit it afterwards.

nostr:nprofile1qyt8wumn8ghj7un9d3shjtnddaehgu3wwp6kytcprfmhxue69uhhyetvv9ujuumgd96xvmmjvdjjummwv5hszxthwden5te0dehhxarj9e3k76twve6kuepwv9c8qtcqypuu9jhpzn4z32vpua2eknl8s49ywdfp4rfz5e4m4w06yj8tsg8lvxxqdcn this is your fault! Can we fix it using TypeScript magic or better not even try?

Do you have an actual use case here or were you just playing with the library and saw this craziness nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsqgy7r0g9a4q7023dmg0fke9chfytdxasl266yt2y9fy4kxlef2dsxqpm0qt2 ?

Reply to this note

Please Login to reply.

Discussion

Daniele 1y ago

I was giving for granted that it behave that way, then today I made an integration test over my signup API to see taht it would fail under an "attack" with a modified event.

The test failed and I got scared so I did dig deeper and wrote that test.

The whole library assembles in the "finalized event" both the original event and the sig/pub/hash properties. So when you call verifyEvent it uses the hashes that one pass as "id" rather than recalculate the hash from scratch from the original event properties.

I am no security expert but that look *very* bad to me.

Daniele 1y ago

TBC: the integration test "failed" means that the signup HTTP worked despite the modified event being sent through, while it should have returned 401.

fiatjaf 1y ago

What? No. "verifyEvent" checks that the actual hash matches the id. What is bad there?

Daniele 1y ago

If it does that, as one would expect, why the check returns true while it should be false?

fiatjaf 1y ago

I just explained it three notes above.

Daniele 1y ago

The note starting with "It should indeed return false"? :)

My point is that the library should not assume that everything has been done properly, quite the opposite.

"You should not change the event" is one thing. Assuming that will not happen and returning that an altered event is verified is another.

The semantic of "verified" here becomes: there is a property set as verified: true in the json. While it should not what it should be or at least what I was expecting.

Solomon 1y ago

Even if you Object.freeze the verified event, nothing in JS will stop you from destructuring it into a new object like that. verify can be a function on the prototype but nothing can guarantee *its* immutability.

Daniele 1y ago

The implementation must follow the nip46 signer protocol, right? https://nostr-nips.com/nip-46#signer-protocol

Solomon 1y ago

The event signature is described in NIP-01. 46 is a spec for external signing providers on top of that format. Code interfaces into verification are completely up to implementors.