4 ms·

We wouldn't even need to worry about this dumb stuff if we had actual cryptographic PKI for payments. Honestly at some point fraud is 100% the card issuer's fau

We wouldn't even need to worry about this dumb stuff if we had actual cryptographic PKI for payments. Honestly at some point fraud is 100% the card issuer's fault when the tech to prevent it is here and now. Why I still can't register a public key with my bank and say "do not under any circumstance honor a transaction unless it's signed with my private key" is beyond me.

thelastparadise 3y ago
> Why I still can't register a public key with my bank and say "do not under any circumstance honor a transaction unless it's signed with my private key" is beyond me. What you are describing is Bitcoin.
- callalex 3y ago
  No, a bitcoin wallet is not a bank.
  - sanex 3y ago
    You are the bank
throwaway42968 3y ago
What you are describing is essentially EMV, except that your bank has gone to the trouble of picking your private key and embedding it in a card you carry around and insert into payment terminals.
crote 3y ago
That's EMV, and it is still not 100% foolproof because the card itself doesn't have a display and Allow/Deny button.
- Nextgrid 3y ago
  > still not 100% foolproof because the card itself doesn't have a display and Allow/Deny button. I'm assuming you are thinking about an attack where a compromised terminal processes an attacker-issued transaction (relayed from elsewhere) instead of the genuine one. It seems like a solution to this would be for the card to issue a challenge to the reader and only provide a very short timeframe to answer, so that relaying it elsewhere is impossible due to speed of light and all that.
teddyh 3y ago
The credit card number is both your public key and your private key: https://www.icanbarelydraw.com/comic/2702 https://www.icanbarelydraw.com/comic/2702
exabrial 3y ago
Guys i appreciate the comment about EMV, I’m aware but it misses the point. They need to be _my_ keys, and ones _I_ can pick and verify. If you don’t generate the key, it’s not actually secure. At minimum, EMV would need to be verifiable. Ideally rotatable. Best case: chooseable.
- none_to_remain 3y ago
  I feel like if you want that, what you have to do is make a social change such that a number of people sufficient to form a marketable niche would even understand what you are talking about. Like, I understand what you are talking about, most of the readers here understand what you are talking about, but I also understand that almost everyone else doesn't.
- spopejoy 3y ago
  Until the UX problem is solved making it infallible for noobs to manage PKI, it's probably better for the bank to manage it. Your ideal world at a minimum requires: - an on-card UI. Yubikey-style one-button-tap is not enough, you actually need to verify the transaction details. - integration with backend systems to support rotation and recovery because otherwise folks will screw this up and lock themselves out There's a reason webauthn passkey has obfuscated PKI to oblivion, because they simply can't figure out how to entrust end users with keys. To be clear, I'm a PKI fan and want all of these things to exist, but we're very far from it. In the interim, a bank-managed PKI is a welcome improvement.

thelastparadise 3y ago

> Why I still can't register a public key with my bank and say "do not under any circumstance honor a transaction unless it's signed with my private key" is beyond me. What you are describing is Bitcoin.

callalex 3y ago
No, a bitcoin wallet is not a bank.
- sanex 3y ago
  You are the bank

throwaway42968 3y ago

What you are describing is essentially EMV, except that your bank has gone to the trouble of picking your private key and embedding it in a card you carry around and insert into payment terminals.

crote 3y ago

That's EMV, and it is still not 100% foolproof because the card itself doesn't have a display and Allow/Deny button.

Nextgrid 3y ago
> still not 100% foolproof because the card itself doesn't have a display and Allow/Deny button. I'm assuming you are thinking about an attack where a compromised terminal processes an attacker-issued transaction (relayed from elsewhere) instead of the genuine one. It seems like a solution to this would be for the card to issue a challenge to the reader and only provide a very short timeframe to answer, so that relaying it elsewhere is impossible due to speed of light and all that.

teddyh 3y ago

The credit card number is both your public key and your private key: https://www.icanbarelydraw.com/comic/2702 https://www.icanbarelydraw.com/comic/2702

exabrial 3y ago

Guys i appreciate the comment about EMV, I’m aware but it misses the point. They need to be _my_ keys, and ones _I_ can pick and verify. If you don’t generate the key, it’s not actually secure. At minimum, EMV would need to be verifiable. Ideally rotatable. Best case: chooseable.

none_to_remain 3y ago
I feel like if you want that, what you have to do is make a social change such that a number of people sufficient to form a marketable niche would even understand what you are talking about. Like, I understand what you are talking about, most of the readers here understand what you are talking about, but I also understand that almost everyone else doesn't.
spopejoy 3y ago
Until the UX problem is solved making it infallible for noobs to manage PKI, it's probably better for the bank to manage it. Your ideal world at a minimum requires: - an on-card UI. Yubikey-style one-button-tap is not enough, you actually need to verify the transaction details. - integration with backend systems to support rotation and recovery because otherwise folks will screw this up and lock themselves out There's a reason webauthn passkey has obfuscated PKI to oblivion, because they simply can't figure out how to entrust end users with keys. To be clear, I'm a PKI fan and want all of these things to exist, but we're very far from it. In the interim, a bank-managed PKI is a welcome improvement.