Open cmdruid opened 2 years ago
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.
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.
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.
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.
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.