Comment by DecoPerson | Hacker News Reader

Comment by DecoPerson | Hacker News Reader

User asks (human) Assistant to login to their online banking and make a transfer. No problem. No digital security system can stop this (bar requiring true biometrics on every sign-in, which isn’t happening soon).

User asks Company (with human staff) to login and do the same thing. Perhaps the company is an accounting firm, a legal firm, or a “manage my company for me” kind of firm. No problem.

User asks Company which makes self-hosted business management tools to login to their online banking. Oh shit!!! This is a violation of the ToS! The Company that makes this tool is violating the bank’s rights! The user doesn’t understand how they’re letting themselves get hacked!! Block block block! (Also some banks realise that can charge a fee for such access!)

Everyone on HN sees how that last case — the most useful given how great automation is these days — should be permitted.

I wish the governing layers of society could also see how useful such automation is.

These Device-Bound Session Credentials could result in the death of many good automation solutions.

The last hope is TPM emulation, but I’m sure that TPM attestation will become a part of this spec, and attestation prevents useful emulation. In this future, Microsoft and others will be able to charge the banks a great deal of money to help “protect their customers” via TPM attestation licensing fees, involving rotation, distribution, and verification of keys.

I’m guessing the protocol will somehow prevent one TPM being used for too many different user accounts with one entity (bank), preventing cloud-TPM-as—a-service being a solution to this. If you have 5,000 users that want to let your app connect to their Bobby's Bank online banking, then you’ll need 5,000 different TPMs. Also Microsoft (or whoever) could detect and blacklist “shared” TPMs entirely to kill TPMaaS entirely.

Robotic Process Automation on the user’s desktop, perhaps in a hidden Puppeteer browser, could still work. But that’s obviously a great deal harder to implement than just “install this Chrome extension and press this button to give me your cookies.”

Goodbye web freedom, and my software product :(

There's nothing in this spec that says there needs to be a restriction of one session per TPM. There isn't even anything that forces the client to use a TPM. It just requires the client to generate a key pair, and then use that to sign challenge responses. There's no way for the server to know which TPM was used to store that private key, nor whether one was even used.

> There's no way for the server to know which TPM was used to store that private key, nor whether one was even used.

I was all ready to disagree with you but apparently you're correct. Color me surprised.

> DBSC will also not prevent an attack if the attacker is replacing or injecting into the user agent at the time of session registration as the attacker can bind the session either to keys that are not TPM bound, or to a TPM that the attacker controls permanently.

This is a very pleasant surprise. I've grown accustomed to modern auth protocols (and other tech stacks as well) having DRM functionality baked into them where they can attest the vendor of the device or the software stack being used to perform the auth. It's become bad enough that at this point I just reflexively assume that any new web technology is hostile to user autonomy.

> self-hosted business management tools

As long as banks are held accountable or generally blamed for people handing over their savings to foreign scammers, any kind of external access will be considered a threat. Every single time people get scammed by fake apps or fake websites or fake calls, a large section of society goes "the bank should've prevented this!!!".

Here, one particular bank is popular because of their pro-crypto stance, their high interest rates, and their app-only approach. That makes them an extremely easy target for phishing and scamming, and everyone blames the bank for the old men pressing the "yes I want to log in with a QR code" button when a stranger calls them. Of course, banks could stop scams like that, so the calls to maybe delay transferring tens of thousands for human review aren't exactly baseless, but this is how you get the situation where businesses struggle to integrate with banking apps.

There are initiatives such as PSD2, but those are not exactly friendly to the "move fast and break things" companies that you'll find on HN (because moving fast and breaking things is not a good idea when you're talking about managing people's life savings).

The TPM is used here because it's the most secure way to store a keypair like this. But, as the spec says:

> DBSC will not prevent temporary access to the browser session while the attacker is resident on the user’s device. The private key should be stored as safely as modern operating systems allow, preventing exfiltration of the session private key, but the signing capability will likely still be available for any program running as the user on the user’s device.

In other words, if a more secure alternative than TPMs comes into play, browsers should migrate. If no TPM is available, something like a credential service would also suffice.

As for TPM emulation: it already exists. Of course, TPMs also contain a unique, signed certificate from the TPM manufacturer that can be validated, so it's possible for TPM-based protocols to deny emulated TPMs. The Passkey API supports mechanisms like that, which makes Passkeys a nice way to validate that someone is a human during signup, though the API docs tell you not to do that.

How dull life must be without FINTS and PSD2

EU has many issues, but sometimes it pulls nice tricks.

Honestly what's going to happen is you're going to have an ai do this via the phone.

Anything that can be done via phone will be done via ai talking to ai.

Reply on news.ycombinator.com