LUD-21: pinLimit for withdrawRequest - resolves #201 #200
Conversation
titusz
changed the title
|
This is great. One thought though, I think there should be a way to provide a human readable response for failure. The pin may be incorrect, it could be that the card is locked after too many attempts. These are good to tell the customer, but I guess it could be given covertly via their app too. Not sure if a reason response has been discussed, what was the outcome? |
That is already possible as specified in LUD 03 section 6 |
titusz
changed the title
add Bolt Card Wallet & Bolt Card PoS with support for PIN LUD
|
I am happy to see that the "pinLimit for withdrawRequest" proposal is gaining some traction from the Bolt Card community. It has been implemented by https://github.com/boltcard/boltcard-wallet & https://github.com/boltcard/bolt-card-pos. I would love to see this merged. |
|
@SwissBitcoinPay will also implement that in the coming weeks. |
I'm really not sure about this one. This is a breaking change and need to better understand the motivation for doing it now. |
Yes, users are asking for it: https://twitter.com/HOLLEPENJO/status/1675011134343069697
It is not meant for gift cards with a fixed budget but for contactless payment cards (Bolt Cards) that are connected to a users lightning node and can generate a potentially unlimited number of withdraw tokens.
I agree that 15 digits is probably a bit exzessiv. But 4 might be a bit weak for some use cases. Why not let the user/SERVICE decide on PIN security level.
Why? User could still retry with a new URL after a new scan. We could also let SERVICE decide the limit for invalidating a given withdraw URL.
Maybe we could specify 4-8 digits which are more realistic.
I wouldn´t call this a breaking change. Its an optional extension like LUD-19 and others. If a WALLET/CLIENT does not implement it the request to the withdraw callback to SERVICE may return an error with for example "PIN required for amount above x.y" |
|
These references don't suggest a real issue (or real users). They suggest a potential issue which I agree exits. I'm still not convinced by the internal twitter discussions. We need to have a serious conversation about the motivation here. This change also goes against the payment simplication trend (tap to pay). Designing a UI for 4 or 15 digits is very very different. The client can't accommodate the service AND provide a good UX for all cases. There's always a tradeoff which is unnecessary here. 4 or 6 I don't care (I don't understand why 4 isn't enough if the service has brute force protection), but it needs to be a fixed number if we want a good UX. By breaking change I mean lnurlw will stop working even with an explicit error. |
|
Links shouldn't invalidated after the first try: because it's likely users will enter the wrong pin sometimes. Having them to rescan isn't ideal and doesn't exist in the other "enter pin" systems, so why? |
Lets assume a user sets a |
I agree. 3 times try before invalidation is probably the most familiar to people. What would you recommend? |
Yeah, so the optional pinLimit is breaking 50k+ payments. What I mean is that it's not really optional. Clients will HAVE TO implement this is provide an operational service. |
3 is ok |
|
This is not a breaking change as far as I can see. Bolt card users have requested the PIN function as part of the Praia Bitcoin Brazil project and also in the https://t.me/bolt_card group. It looks like the requirements from the LUD spec for listing are covered:
|
I think I explained why I see it as a breaking change. I understand you guys want this merged, and I think I'm well aware of what's going on in the ecosystem including the Praia project. Yes, I'm being conservative with changes because I understand what it means to implement and maintain them. Feel free to ignore me, but I would advise you to try to provide some tangible data on what this is needed if you want to achieve some kind of a consensus. Meanwhile, let's address the digit, retries and get more people to review this PR. |
|
I updated the spec to 3 retries before link invalidation and set the pin length limit to 8 digits. I can also set a fixed number of digits (4, 5, 6?) for the PIN if there is consensus among reviewers. I agree with @kingonly that it would be helpful to get more people to review this PR. |
Fixed digit spec is simpler and will allow wallets to define a fixed UI which is easier for users. The alternative is to implement an open input field (or dynamic UI if the backend returns the digit number). This is what I'm thinking and I suggest to KISS. I don't see the value in a variable digit.
|
Co-authored-by: Andrei <[email protected]>
Co-authored-by: Andrei <[email protected]>
|
To add my two cents shared so far only on telegram: I completely oppose this being added to the spec. Right now the merchants are barely tolerating the complexity of the offline payment pin. If I now have to tell them that they need to train their staff that there can be two pins with exactly the same structure, but obtained by the user in two completely different ways, this will hurt adoption. We need to find either a different solution for offline payments or for additional Boltcard security (is that even needed?). And offline payments from our experience happens at least 1000x more than Boltcard, let alone big Boltcard payments that need a pin, so that functionality is more important I think. |
|
I agree with you 100%
…On Tue, Aug 20, 2024, 8:13 PM MichaelAntonFischer ***@***.***> wrote:
To add my two cents shared so far only on telegram:
I completely oppose this being added to the spec. Right now the merchants
are barely tolerating the complexity of the offline payment pin.
If I now have to tell them that they need to train their staff that there
can be two pins with exactly the same structure, but obtained by the user
in two completely different ways, this will hurt adoption.
We need to find either a different solution for offline payments or for
additional Boltcard security (is that even needed?).
And offline payments from our experience happens at least 1000x more than
Boltcard, let alone big Boltcard payments that need a pin, so that
functionality is more important I think.
—
Reply to this email directly, view it on GitHub
<#200 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4F74S5HSAXRKELD7JLEADZSOINHAVCNFSM6AAAAABMZSND46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJZGU3TQOJYGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Why the restriction to a four-digit PIN? As the possibility of an OTP scheme is mentioned in the document, a variable length PIN, like between 4 and 8 digits to allow compatibility. |
|
Counterproposal: What is the use case of a PIN? To prevent fraudulent use of a card. What types of fraud can happen?
In a nutshell, boltcards are already way better than credit cards and pins have very little added value. So why don’t we work on better algorithms to detect and block suspicious transactions instead? |
|
Im with Mike, and much more into it being off spec server logic, being able to temp raise max spend. As well as more server logic for general security, again, off spec, that's how tap/pay works already. I think security and ux is better, users being able to easily set max amount in the card host software rather than a pin. Going over maxspend is an unusual event, so doesn't need extra spec bloat. Tap/pay with cards currently doesn't have pin UX, prob for good reasons. |
|
Optional PIN support improves security in cases of lost or maliciously scanned NFC payment devices. In both cases the user may not be aware what´s happening and does not deactivate his/her card. |
NFC BotlCards and BoltRings support offline usage (on the user side). It´s about not having to have a mobile device or internet connection. How would the user change their card host settings on the go? |
But what improvement in security offers the pin? The thieve will be able to spend max transaction max daily limit regardless. It might allow you to set slightly smaller limits that’s it. But then you have to trust the card reader not to log your pin, so you would need all the convoluted ineffective guardrails from the fiat system, certify pos devices, etc. |
This is not the place to argue if a PIN makes sense for you. Dont use NFC on your device if you dont like it then. NFC card and PINs are a common UX and theres absolutely no reason to oppose common practices that users expect when being the card processor. |
|
The fact that cards with a PIN and a UX for it is already out there without a standard being set is the reason why this PR exists. NFC payments on offline devices dont work, Boltcards only work in online-mode.. If online the card-user knows he needs a pin. In offline-mode the device needs another pin by another logic (that you said you want adapted to prevent confusion). Communicate the difference on the display and address the changes for offline-mode. |
|
The PIN offers a second factor authentication. It can be used to set different payment rules. These can be more than just a per-transaction limit, although that makes sense as well as some kind of rate-limit. In the situation where a user loses their card, the amount of funds at risk can be limited, even down to zero, if required. It may be possible to discover a user's PIN by watching over their shoulder, with a camera or compromising the PoS device. My opinion is that these are fairly obvious and understandable risks that can be managed by the card user. I don't see a downside other than a bit of added complexity, but this has been kept to a minimum. |
|
Here's my opinion on this proposal:
In general, I don't think a PIN entered on a separate device provides a major security benefit, so I don't like the idea, but the current spec would, if the idea is accepted, need these improvements in my opinion. |
Retry limits / ratelimit needs to be done on the Boltcardhub/card issuer side. Theres already a deactivate-status implemented that is already mentioned above. Heres e.g. the changes proposed for LNbits which has both |
LUD 3 point 6 is very specific about the response schema where
Again I wanted to keep it simple and only introduce one new field to the withdraw schema. But I am fine with both additions if there is consensus that they are needed.
I would argue that the PIN offers major security benefits in at least 3 cases:
|
|
my 2 cents is, i get the use cases and i kinda like the idea, but i think one issue with this that it should be in the withdraw response and not the request, this makes the flow kind of weird. my proposal would be to have something similar like this would not so much disrupt the lnurl flow and also would be very similar to card payments today. |
|
maybe also a more general |
|
We have implemented it on https://github.com/SwissBitcoinPay/boltcard-tools-terminal thanks to the work of @X-Hades-X with SwissBitcoinPay/boltcard-tools-terminal#33 |
|
which wallet does support this? |
it does not make sense, the pin is not encrypted or encoded. |
|
@zzzhan The Boltcard Tools Terminal (https://github.com/SwissBitcoinPay/boltcard-tools-terminal) is a backend agnostic helper app. It simply can scan/read invoices, display the amount and description and will read the bolt card to pay for it. Regarding encryption I was also confused why no requirements about hashing the pin or so exists. I figured HTTPS is enough since these things are probably self hosted and you own the server anyway. But if you know of a standard I missed I would be glad to know. |
But there are some custody lightning wallets and services, it should be hashed before creating a pin. The pin protocol should be supported ASAP. I propose a pin hashed with the uid of card. |
|
The PoS has the PIN and the bolt card host server has the PIN. |
The plaintext of pin is being stored in the third party services(custody lightning) |
I agree that the pin protocol should be supported ASAP :) Regarding PIN hashing/encryption: The PIN is entered by the user on an untrusted payment terminal. Maybe I am missing something but I cannot imagine any way of preventing the leak of the PIN to the merchant without some closed hardware certification infrastructure on the terminal side (which I guess we don´t want). The spec mentions the limitations: https://github.com/bitcoin-ring/luds/blob/withdraw-pin/21.md#security-considerations Any suggestions on security improvements of the protocol are welcome. |
The protocol does not make any assumptions about how PINs are stored by |
Considering that you have enough trust in the On the client side a leaky pin is probably the least of our problem. I would be more annoyed if people use PoS that show wrong values to be paid. Gametheory is probably the only thing that helps there. |
The basic principal is the pin or password should be encrypted or hashed when it is sent to the 'SERVICE'. It is the first step to make sure the leaky. For example, some finance APP will use a special keyboard to input the pin and get an encrypted pin.For trade-off , I propose to hash the pin with UID of the card. |
The PIN is already encrypted when sent to the 'SERVICE' because LNURL requires HTTPS for transport. Who would hash the pin and why? The card UID can be read by the terminal but it may be a random UID (changing on each read of the card). |
Please check our project https://lifpay.me , we will support the feature soon. We know the https is security, but we should not store and verify with the plaintext PIN.
|
|
Hi Guys，I hope you are doing well! LifPay has implemented this feature. The PIN is compatible from 4~12, hashed before saving to the backend, but verified with the plaintext PIN this moment. @titusz @X-Hades-X |
LNURL-withdraw is increasingly used for convenient contactless payments via NFC devices that do not require a battery and do not have a user interface.
While these devices can produce unique one-time LNURLw-links with replay protection there is still the risk of losing the device or maliciously scanning the device without knowledge of the owner.
This LUD seeks to improve security of tap & pay experiences by optionally requesting a second factor PIN for
withdrawRequestcallbacks.