[Barrera]

> 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.

[spinny]

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]

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]

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]

The UX is similar to buying something with Apple Pay from a website in my experience.

[Phlarp]

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?

[patch_cable]

The distinction between “browser extension” and “baked into Safari” didn’t seem like an important distinction for this discussion.

The similarities are that in both use cases the user is presented with a request to approve or deny.

[xwolfi]

I work in a 100yo investment bank and am quite familiar with how it all works and yet, even if I didnt just work in a technical-centric company like you but a business and finance-centric one at that, I still think it's gibberish.

Worse, I learned to decode what they refer to talking like that and I still dont see a point: to the gibberrish or to the whole concept.

[justsomeguy123]

I bet a whole lot of your day to day technical and administrative work is gibberish. Your yearly evaluation alone probably would require training for an outside person to understand.

Which is to say... don't assume jargon is pointless.

[DonHopkins]

Unless it's crypto jargon, in which case it's carefully designed to be pointless and indecipherable. That's the whole point.

https://mashable.com/article/multiple-slurp-juices-single-ap...

>'Multiple slurp juices on a single ape' meme perfectly captures the stupidity of NFT culture

>If I know anything to be true is this mixed-up world, it's that ape holders can absolutely use multiple slurp juices on a single ape. Any fool knows that. It's as simple as two plus two equals four. An ape holder can use multiple juices on a single ape; this is fact.

[Kye]

It's reminiscent of conspiracy theories. You can sit there and untangle the jargon until you understand all the oblique references to events, and it's still nonsense.

[justsomeguy123]

There's crypto "pop-jargon" and cypto technical jargon.

The technical jargon does make sense like any kind of niche technical jargon.

[Yeahsureok]

Some js code makes a popup window appear for user to enter a transaction address (like bank details) so they can clicky click on it. Then it shows those details to confirm.

Is that simple enough for a senior FAANG engineer?

[dcolkitt]

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]

Where do the private keys reside in this scenario?

[cdiddy2]

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]

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).

[rattlesnakedave]

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

[Barrera]

I looked at it for 30 seconds and am deeply skeptical of the scheme.

[t_mann]

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.

[gowld]

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.

[peyton]

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/202...

[lupire]

> 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.

[yieldcrv]

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.

[seanhunter]

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.

[iamacyborg]

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