659 sats \ 1 reply \ @ek 27 Feb \ parent \ on: Have you connected an external wallet on SN? meta
Mhh, I see now what you are talking about, thanks!
I was confused since LUD-03 mentions that k1 should be ephemeral:
Note that service will withdraw funds to anyone who can provide a valid ephemeral k1.
So aren't "persistent withdrawals links" non-standard behavior? All the other sources in your screenshot, do they accept the same k1 over and over again?
Also, can you elaborate on this part:
so they aren't accidentally sniped
What do you mean with "sniped"?
write
preview
2205 sats \ 0 replies \ @justin_shocknet 27 Feb
We haven't run into any other expiring K1's yet
Per the spec "k1": string, // Random or non-random string, so it's not opinionated either way
On the subject of sniping, that foot note on the spec is related and @k00b actually mentioned this before too...
When you go to the stacker wallet and click on QR Code, the QR just displays on your screen and contains the k1... any cameras behind you could potentially sweep funds before you do.
The expiring of the k1 is a mitigation for a camera behind you doing a replay attack later.
2 simple ways to fix both problems:
One is to instead of the QR code, provide the LNURL as a clickable link so that only the designated protocol handler can see the k1 parameter.
The other is to keep the QR code, but blur it out and make the user click off a warning to be sure they have privacy first, this would mitigate the existing sniping vulnerability.
Personally I think both would be good.
The flow in ShockWallet, when it gets an LUD03, is it asks the user if they want to sweep the balance... or add it as a source so they can subject it to continued automation in accordance with their trust preferences and budgeting rules.
reply