4 ms·

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

by franga2000 1y ago

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.

danpalmer 1y ago
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.
- deleted 1y ago
  [deleted]
- archerx 1y ago
  No TPMs are not going to stop your grandma from getting scammed over the phone.
- no_time 1y ago
  >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.
  - cyberax 1y ago
    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.
  - fc417fc802 1y ago
    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/ https://w3c.github.io/webappsec-dbsc/
    - no_time 1y ago
      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.
      - fc417fc802 1y ago
        > 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.
- simiones 1y ago
  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?
  - imtringued 1y ago
    The point of this is to prevent a readout of credentials from a machine so that the credentials cannot be used on another machine.
    - simiones 1y ago
      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).

danpalmer 1y ago

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.

deleted 1y ago
[deleted]
archerx 1y ago
No TPMs are not going to stop your grandma from getting scammed over the phone.
no_time 1y ago
>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.
- cyberax 1y ago
  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.
- fc417fc802 1y ago
  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/ https://w3c.github.io/webappsec-dbsc/
  - no_time 1y ago
    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.
    - fc417fc802 1y ago
      > 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.
simiones 1y ago
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?
- imtringued 1y ago
  The point of this is to prevent a readout of credentials from a machine so that the credentials cannot be used on another machine.
  - simiones 1y ago
    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).