4 ms·

> Victim connects their wallet to “mint”. It's not clear exactly what's going on here. The word "connect" by itself implies two modes: (1) present public keys;

> Victim connects their wallet to “mint”. It's not clear exactly what's going on here. The word "connect" by itself implies two modes: (1) present public keys; or (2) present private keys. But the loss of property suggests it's (2). If so, then the people falling for this are hopelessly incompetent. Of course, this has been a problem from the start of Bitcoin. Users "buy" something they have no clue how to secure. They don't understand at all how public key cryptography works, or worse, they bring truly bad mental models from their experience with their online bank or Facebook. Then they get burned. Nothing new here. It's for this reason that central bank digital currencies are one the the worst ideas ever to come out of central banks. The average person is in no position to even think about managing cryptographic material let alone securing life-changing amounts of money with it. Idiot-proofing CBDC will mean that the central bank just becomes an actual, central, bank. No crypto required. A real one where people actually keep their money. So long to private banks.

rattlesnakedave 4y ago
No it doesn’t suggest 2. Google “token approvals.” Or just look at metamask for like 30 seconds.
- Barrera 4y ago
  I looked at it for 30 seconds and am deeply skeptical of the scheme.
dcolkitt 4y ago
All connecting a wallet does is allow the app to see your public keys. Private keys are not directly exposed. The app can then request the user sign transactions, but they must be explicitly approved by the user. Where fraud typically happens is when a user thinks they're signing an innocuous transaction, when in fact they're signing a malicious one. This is generally a hard problem, but it's very clear from the wallet the address of the smart contract your transaction interacts with.
- Barrera 4y ago
  Where do the private keys reside in this scenario?
  - cdiddy2 4y ago
    Depends on the type of wallet. If its a web wallet the keys are in the browsers data store that the wallet extension handles. The keys could also be on a separate hardware wallet that is completely separate from the computer you interact with and requires physical button presses on the hardware device. Could also be that you are in a view only mode and just connecting with an address and you don't even have the keys on you.
  - 3np 4y ago
    Most common three subscenarios: A hardware wallet connected by USB/Bluetooth; locally on disk/memory; in a third-party application. Only on the second case does the browser extension handle primitives like private keys and in no scenario do they get exposed to a site. The more common crypto-thefts are phishing (user gives away their recovery phrase) or malware (scanning for on-device keys and recovery phrases).
spinny 4y ago
the wallet in question is probably metamask, a browser extension. it injects a web3 provider in `window.ethereum`. connecting the wallet is done by calling `window.ethereum.enable()`, this pops up a dialog asking you to connect an address to the website. it just tels the extension that the website is allowed to interact with the extension This article is about phishing in the context of cryptos. Silent signing doesn't happen (unless there is some kind of bug in metamask). the user is always presented with the contract address and call data (the args to the contract call)
- mrep 4y ago
  I have a CS degree and have worked at FAANG for 6 years and that was straight gibberish to me. I guess maybe because I have only worked at FAANG using traditional tech and not crypto startups?
  - AgentME 4y ago
    I think that explanation was just a little too jargony. If you have the Metamask browser extension (or another compatible web3 extension) and press its browser button to enable it while on a webpage, then the webpage can see your wallet address and suggest transactions for you to make. When that happens, the browser extension then shows a window under its own control explaining the transaction and allows you to choose to sign or reject the transaction. The webpage never sees anything about your wallet if you don't activate the extension on the page specifically, it never sees your private keys, and it can never silently sign a transaction from you.
    - patch_cable 4y ago
      The UX is similar to buying something with Apple Pay from a website in my experience.
      - Phlarp 4y ago
        Apple Pay doesn't run as a browser extension with a nasty habit of granting bad actors full access to drain your funds in a totally irreversible way. Does any of that fall under "user experience" for you?
gowld 4y ago
CBDC has never been about blockchain or cryptocurrency. That's what the first "C" means, and why the "D" isn't a C". It's Venmo or Zelle but run by the government bank.
- junofan 4y ago
  Here's the Fed's Project Hamilton experiment [1]: > In our design users interact with a central transaction processor using digital wallets storing cryptographic keys. Funds are addressed to public keys and wallets create cryptographic signatures to authorize payments. The transaction processor, run by a trusted operator (such as the central bank), stores cryptographic hashes representing unspent central bank funds. Each hash commits to a public key and value. Wallets issue signed transactions which destroy the funds being spent and create an equivalent amount of new funds owned by the receiver. The transaction processor validates transactions and atomically and durably applies changes to the set of unspent funds. In this version of our work, there are no intermediaries, fees, or identities outside of public keys. That doesn't sound like Venmo to me. [1]: https://www.bostonfed.org/news-and-events/press-releases/2022/frbb-and-mit-open-cbdc-phase-one.aspx https://www.bostonfed.org/news-and-events/press-releases/202...
  - lupire 4y ago
    > transaction processor, run by a trusted operator > there are no intermediaries Except the transaction processor. Which part doesn't sound like Venmo? "Signed transactions" is essentially SSL/SPIF/I don't know the details but it's regular Internet security encryption and signatures. The only difference from Venmo is that users get a proper PK instead of phone or email address id, and it's vertically integrated.
iamacyborg 4y ago
CBDC’s don’t have to be crypto currency though.
seanhunter 4y ago
There are two attack vectors described in the article. 1) When you "connect a wallet" what you are actually doing is signing a message from the site using your private key. They can verify it using your public key to prove you control that wallet (ie it is just a normal message signing process). This process involves your wallet (often via a browser extension) popping up a message giving you details of what you are signing and buttons to approve or reject. Because lots of sites send a very unhelpful message that is just a big json token for people to sign, and because browser extensions are wonky leading to lots of requests to connect and reconnect and re-reconnect your wallet, people often get in the habit of not checking carefully what they are signing. The fundamental UX problem arises because the flow for authorizing a transaction is exactly the same - you sign a transaction approval using your wallet. Can you see the problem here? It's easy to accidentally approve a transaction which drains your assets when you think you're just approving a message to connect your wallet. 2) Secondly there is a classic phishing attack against the private key. If an attacker can pretend to be a legitimate site they can apparently sometimes persuade people to paste in their recovery phrase which is equivalent to their private key. If the attacker has the private key of course they don't need anyone else to approve the transactions which drain the wallet, they can do it themselves. There's another attack vector I have heard about which I don't think is in the article but is more pernicious. I'm not 100% sure of all the details but it's sort of a variant of #1 with extra tabasco. It starts by sending someone a token with malicious code in some of its methods (say the 'transfer()' method which is used to send the token to another address). This code is set up to drain the wallet of the owner of the token. So say the recipient of the token attempts to transfer the token to another wallet (or 'burn' it, which is just a transfer to a specific black hole address), they will be presented by their wallet with a normal-looking transfer approval method to authorize but unbeknownst to them (because they are approving untrusted code) they are actually authorizing the attacker to drain their wallet. The attacker can make it more likely a person will attempt to burn a token by either promising that burning will turn the token into something else (this is common in this world as a method of transforming things) or by making the content of the token really unpleasant so people want it out of their wallet (I think someone tried this with me - that is I got sent an unsolicited token with a pretty horrible animation that any sane person would want out of their wallet and it can't be burned because it is unverified code so there's no way of knowing whether the transfer method is trustworthy). The same attack can be run using different methods and it will operate should the recipient try to list their new token on an exchange. The remedy for this is that legitimate issuers can "verify" their code by publishing it and since the resulting bytecode checksum is the same as the checksum of the token people can be confident that they are seeing the real code. You would still need to actually check whether the code was doing anything bad to know whether it was safe to interact with such a token.
yieldcrv 4y ago
Its just a phishing site, you're extrapolating way too much. People rush to buy a new thing, and send their money to an unrelated thing that looks like the new thing.
t_mann 4y ago
Your entire response is based on false assumptions. "Connecting a wallet" and "signing a transaction" have defined meanings, and are not related to revealing a private key. Also, CBDCs are in no way related to cryptocurrencies, they don't even aim to be.

rattlesnakedave 4y ago

No it doesn’t suggest 2. Google “token approvals.” Or just look at metamask for like 30 seconds.

Barrera 4y ago
I looked at it for 30 seconds and am deeply skeptical of the scheme.

dcolkitt 4y ago

All connecting a wallet does is allow the app to see your public keys. Private keys are not directly exposed. The app can then request the user sign transactions, but they must be explicitly approved by the user. Where fraud typically happens is when a user thinks they're signing an innocuous transaction, when in fact they're signing a malicious one. This is generally a hard problem, but it's very clear from the wallet the address of the smart contract your transaction interacts with.

Barrera 4y ago
Where do the private keys reside in this scenario?
- cdiddy2 4y ago
  Depends on the type of wallet. If its a web wallet the keys are in the browsers data store that the wallet extension handles. The keys could also be on a separate hardware wallet that is completely separate from the computer you interact with and requires physical button presses on the hardware device. Could also be that you are in a view only mode and just connecting with an address and you don't even have the keys on you.
- 3np 4y ago
  Most common three subscenarios: A hardware wallet connected by USB/Bluetooth; locally on disk/memory; in a third-party application. Only on the second case does the browser extension handle primitives like private keys and in no scenario do they get exposed to a site. The more common crypto-thefts are phishing (user gives away their recovery phrase) or malware (scanning for on-device keys and recovery phrases).

spinny 4y ago

the wallet in question is probably metamask, a browser extension. it injects a web3 provider in `window.ethereum`. connecting the wallet is done by calling `window.ethereum.enable()`, this pops up a dialog asking you to connect an address to the website. it just tels the extension that the website is allowed to interact with the extension This article is about phishing in the context of cryptos. Silent signing doesn't happen (unless there is some kind of bug in metamask). the user is always presented with the contract address and call data (the args to the contract call)

mrep 4y ago
I have a CS degree and have worked at FAANG for 6 years and that was straight gibberish to me. I guess maybe because I have only worked at FAANG using traditional tech and not crypto startups?
- AgentME 4y ago
  I think that explanation was just a little too jargony. If you have the Metamask browser extension (or another compatible web3 extension) and press its browser button to enable it while on a webpage, then the webpage can see your wallet address and suggest transactions for you to make. When that happens, the browser extension then shows a window under its own control explaining the transaction and allows you to choose to sign or reject the transaction. The webpage never sees anything about your wallet if you don't activate the extension on the page specifically, it never sees your private keys, and it can never silently sign a transaction from you.
  - patch_cable 4y ago
    The UX is similar to buying something with Apple Pay from a website in my experience.
    - Phlarp 4y ago
      Apple Pay doesn't run as a browser extension with a nasty habit of granting bad actors full access to drain your funds in a totally irreversible way. Does any of that fall under "user experience" for you?

gowld 4y ago

CBDC has never been about blockchain or cryptocurrency. That's what the first "C" means, and why the "D" isn't a C". It's Venmo or Zelle but run by the government bank.

junofan 4y ago
Here's the Fed's Project Hamilton experiment [1]: > In our design users interact with a central transaction processor using digital wallets storing cryptographic keys. Funds are addressed to public keys and wallets create cryptographic signatures to authorize payments. The transaction processor, run by a trusted operator (such as the central bank), stores cryptographic hashes representing unspent central bank funds. Each hash commits to a public key and value. Wallets issue signed transactions which destroy the funds being spent and create an equivalent amount of new funds owned by the receiver. The transaction processor validates transactions and atomically and durably applies changes to the set of unspent funds. In this version of our work, there are no intermediaries, fees, or identities outside of public keys. That doesn't sound like Venmo to me. [1]: https://www.bostonfed.org/news-and-events/press-releases/2022/frbb-and-mit-open-cbdc-phase-one.aspx https://www.bostonfed.org/news-and-events/press-releases/202...
- lupire 4y ago
  > transaction processor, run by a trusted operator > there are no intermediaries Except the transaction processor. Which part doesn't sound like Venmo? "Signed transactions" is essentially SSL/SPIF/I don't know the details but it's regular Internet security encryption and signatures. The only difference from Venmo is that users get a proper PK instead of phone or email address id, and it's vertically integrated.

iamacyborg 4y ago

CBDC’s don’t have to be crypto currency though.

seanhunter 4y ago

There are two attack vectors described in the article. 1) When you "connect a wallet" what you are actually doing is signing a message from the site using your private key. They can verify it using your public key to prove you control that wallet (ie it is just a normal message signing process). This process involves your wallet (often via a browser extension) popping up a message giving you details of what you are signing and buttons to approve or reject. Because lots of sites send a very unhelpful message that is just a big json token for people to sign, and because browser extensions are wonky leading to lots of requests to connect and reconnect and re-reconnect your wallet, people often get in the habit of not checking carefully what they are signing. The fundamental UX problem arises because the flow for authorizing a transaction is exactly the same - you sign a transaction approval using your wallet. Can you see the problem here? It's easy to accidentally approve a transaction which drains your assets when you think you're just approving a message to connect your wallet. 2) Secondly there is a classic phishing attack against the private key. If an attacker can pretend to be a legitimate site they can apparently sometimes persuade people to paste in their recovery phrase which is equivalent to their private key. If the attacker has the private key of course they don't need anyone else to approve the transactions which drain the wallet, they can do it themselves. There's another attack vector I have heard about which I don't think is in the article but is more pernicious. I'm not 100% sure of all the details but it's sort of a variant of #1 with extra tabasco. It starts by sending someone a token with malicious code in some of its methods (say the 'transfer()' method which is used to send the token to another address). This code is set up to drain the wallet of the owner of the token. So say the recipient of the token attempts to transfer the token to another wallet (or 'burn' it, which is just a transfer to a specific black hole address), they will be presented by their wallet with a normal-looking transfer approval method to authorize but unbeknownst to them (because they are approving untrusted code) they are actually authorizing the attacker to drain their wallet. The attacker can make it more likely a person will attempt to burn a token by either promising that burning will turn the token into something else (this is common in this world as a method of transforming things) or by making the content of the token really unpleasant so people want it out of their wallet (I think someone tried this with me - that is I got sent an unsolicited token with a pretty horrible animation that any sane person would want out of their wallet and it can't be burned because it is unverified code so there's no way of knowing whether the transfer method is trustworthy). The same attack can be run using different methods and it will operate should the recipient try to list their new token on an exchange. The remedy for this is that legitimate issuers can "verify" their code by publishing it and since the resulting bytecode checksum is the same as the checksum of the token people can be confident that they are seeing the real code. You would still need to actually check whether the code was doing anything bad to know whether it was safe to interact with such a token.

yieldcrv 4y ago

Its just a phishing site, you're extrapolating way too much. People rush to buy a new thing, and send their money to an unrelated thing that looks like the new thing.

t_mann 4y ago

Your entire response is based on false assumptions. "Connecting a wallet" and "signing a transaction" have defined meanings, and are not related to revealing a private key. Also, CBDCs are in no way related to cryptocurrencies, they don't even aim to be.