LUD-03: withdrawRequest k1 should be signed using same key derived from LUD-04

[cmdruid]

Hello. I think the k1 value used during withdrawRequest process should be signed using the same key derivation process outlined in LUD-04. That way, requests from the same domain are signed by the same key used in LUD-04, and a stored user session can also verify a wallet responding to a withdrawRequest.

This will solve the problem outlined in LUD-03 where anyone with the k1 value can submit their bolt11 invoice to be paid. With the proposed change above, sites could reuse a user's authenticated session from LUD-04 to verify a signed k1 value for processing a bolt11 withdraw.

Thank you for reading. Let me know what you think.

[cmdruid]

I should add: the problem I am worried about is an "over-the-shoulder" attack (for lack of a better term). Basically that if someone were to scan another user's withdraw code, there wouldn't be much way to prevent the attacker from cashing out on a code meant to go to a specific user. The k1 value in step 2 of LUD-03 only links the wallet to step 3: it does not ensure the wallet which scanned the initial QR code is valid.

[fiatjaf]

I agree with you, and it worked this way in the beginning, but that part was removed by our late protocol master and it is what it is now.

[cmdruid]

What would be the formal process for proposing an update to the lnurl spec?

I'd like to put together a proposal and maybe approach some of my favorite wallet providers to see if they will implement it.

[fiatjaf]

I think you can just open a pull request. The problem with this is that we can't break backwards-compatibility, so it's hard, but maybe there is a way.