Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We're once again one step closer to losing whatever little autonomy we have left when interacting with online services. Why the hell did we have to put TPMs in every computer?? They bring essentially no benefit for the vast majority of users, but companies keep finding new ways to use TPM capabilities to the user's detriment.


Don't you think if banks and email providers supported this, they would be a significant security benefit to most users?

I don't think this will be a worthwhile security benefit for most sites, and comes with trade-offs, but we already have trade-offs for higher security around sensitive things like banking and email where most users need a lot of protection.


>higher security around sensitive things like banking and email

There are no guard rails built in to make sure this isn't used by everyone and their dog as long as it makes site automation just a bit more difficult. Also kiss goodbye to browsing the internet without a governement/bigcorp™ approved TPM.


If you check the spec [0] you will see that unlike most new web tech this one doesn't provide any DRM-adjacent functionality. There's absolutely no technical measure in the spec that could be leveraged to force an implementation to use a TPM. If user choice is disrespected that is squarely on the implementation (ie the browser) and has nothing to do with either the protocol or the server.

Honestly this fairly simple scheme looks a lot like what I wish webauthn could have been.

[0] https://w3c.github.io/webappsec-dbsc/


hah you are right. They address this concern specifically in 2.1:

>DBSC is not designed to give hosts any sort of guarantee about the specific device a session is registered to, or the state of this device.

Nevermind then. Also makes it more or less useless as a security measure but atleast not outright harmful like the famous WEI proposal.


> makes it more or less useless as a security measure

Define "security". This is incredibly useful for mitigating bearer token exfiltration which is the stated purpose. It's also the same way ssh keypairs work and those are clearly much more secure than passwords.

It's only "insecure" from the perspective of a service host who wants to exert control over end users.

Even webauthn leaves attestation as an optional thing. Even in the case that the service operator requires it, so long as they don't engage in vendor whitelisting you can create a snakeoil authority on the fly.

The main advantage this has over webauthn is that it is so much simpler.


TPM does not support the proof-of-presence functionality (except for the key import in BIOS), so there's nothing stopping you from automating it.

You might need to build a custom version of Chrome that supports bypassing the user interaction requirements.


No TPMs are not going to stop your grandma from getting scammed over the phone.


What is the scenario that this is supposed to help with? Allowing you to browse malicious sites slightly more securely? Slightly less chance that running malware will steal your money?


The point of this is to prevent a readout of credentials from a machine so that the credentials cannot be used on another machine.


To what end? It's still very likely that malware on your machine will find some other way to exfiltrate this data / impersonate you while using your machine and exfiltrate the important parts (e.g. your money).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: