Nostr Web Client

I would say it is not due to it is security, rather than privacy itself.

the auth request (challenge) is sent from a relay to the client, this value is meaningless to anyone else

only the client can sign it, and anything else in the message is irrelevant

nobody can sign with the valid public key and challenge except the holder of the private key, so why does the relay address matter?

i already got one ack on this proposal and i am pretty confident the rest will ack also

and it solves the problem that makes your project more or less useless if you care about not exposing your nsec to remote attackers to hardware not in your direct physical control

this will mean that you can add one small feature to your project where it forwards AUTH messages back and forth to the relays, it only needs to keep track of the challenge and relay address so it forwards the auth response to the relay that will recognise it (and btw, typically these live for only 20 seconds at best).

Reply to this note

Please Login to reply.

Discussion

Yonle 1y ago

I am still disagree with this proposal anyway.

https://github.com/nostr-protocol/nips/issues/1013#issuecomment-1921424702

Yonle 1y ago

And if you want to solve this problem just because of my project bostr, We do not need to change the current NIP. That proposal is stupid.

The fix is basically just implement nsecbunker for handling NIP-42 in bostr. However i do not have plan to do it anyway as people is still rarely using nsecbunker feature.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

no, i want to change the nip42 because i think it's an irrelevant feature and constriction of the thing and i have been dreaming of nostr proxies since like 3 months

so i don't know why you are saying this is a bad thing

do you have a reason based on cryptography and network security theory why it's important to send a challenge and then require that be constrained by some arbitrary government registered address?

Yonle 1y ago

Relay spoofing.

Aside of revealing who are people talking to with PMs, it also breaks paid relays.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

so you mean a replay attack, send a challenge without this

ok, then i am gonna revise this because the second problem is that the challenge should have this in the string or relay spoofing

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

in most challenge/response auth protocols you actually sign ONLY on the challenge string

in this nip42 you sign on a heap of other things, it's not relevant, there is no reason why the relay tag has to be there, at all.

Yonle 1y ago

Of course that tag was to validate that the client actually talks to the relay DIRECTLY.

Yonle 1y ago

Faked / sniffer: Auth please

Client:

Upstream relay to faked: The client AUTH response is not even having a match URL as mine. Ignoring.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

i've amended my proposal to add the relay address to the challenge and to giftrap the response so that the MITM doesn't see the response signature

Yonle 1y ago

The effective one is still on hostname validation. Even we do with giftwrapping, Raw event (encrypted message content) will still be seen anyway.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

*sigh*

the message should not just have a challenge but a challenge pubkey, and then the response can be encrypted, and it can be done over a proxy

TLS has been broken several times before, it's not immune to various kinds of MITM and side channel attacks, and enabling proxy relays opens up a heap of options for relay services

Yonle 1y ago

What do you want to encrypt?

The challenge message?

It won't work anyway.

If you try to encrypt the entire event JSON, You are making things harder than nostr promised.

Yonle 1y ago

What NIP-42 actually does is basically this:

Relay: Who are you?

Client: I am connected to .

Relay: Hello . Yes is me.

And then the relay know who the client was, and allows some certain events to be retrieved.