5 ms·

No not really. It highlights how incompetent Valve is at security. If you cannot trust the webserver or whatever is being served to you, JS crypto isn't going

by codexon 11y ago

No not really. It highlights how incompetent Valve is at security. If you cannot trust the webserver or whatever is being served to you, JS crypto isn't going to do anything. They could just send you a login script that sends your unencrypted password elsewhere.

ejcx 11y ago
It highlights how incompetent Valve is at security. Adding one feature shows they are incompetent at security? Great real. Without more information about the scheme there's nothing to know. Whether useful or not it is still neat and can be used for benefit, but not for something TLS like.
- codexon 11y ago
  Yes, it does. It was a complete waste of time and does nothing useful except chew more CPU cycles. This is why all the security experts say that JS crypto is useless.
  - ejcx 11y ago
    I'm not going to argue but I might as well explain some of the uses here. For example, encrypting clientside and not decrypting serverside will mean it's impossible to have a plaintext password leak in the future, which decreases risk. It also forces passive MITM to become active. Turning Eve into Mallory gives theoretical attackers much more work. There are more benefits beyond this. What you're thinking of is using this for actual password protection, which it won't provide. It can't be used as a TLS replacement. If you've actually read tptacek's big blog post about this you would notice it has to do with using js crypto being used to protect something, which this won't provide, but it can successfully be used to protect a service from itself and many other things. It's impossible to know all the details and benefits and pitfalls of their scheme though, without all the code from the server too.
    - phlo 11y ago
      > encrypting clientside and not decrypting serverside [...] ...will also enable anyone with the encrypted password to log in, in a sort of pass-the-hash scenario. To protect against plaintext password leaks, you'll want to run PBKDF/*crypt on the server, not encrypt the password. See the Adobe password leak for the gory details.
- danparsonson 11y ago
  Adding a feature that feels like security but actually isn't, would not be a good sign that they have a good understanding of web security. What's the difference between 'client sends plaintext password' and 'client sends encrypted password' from the point of view of an attacker? All you're aiming to prevent is client-side interception but in reality it doesn't matter what you do to the password locally - if what you send is what the server expects then you still get in; the encrypted plaintext effectively becomes the password. Thus an attacker who can intercept a plaintext password is at no disadvantage intercepting an encrypted or hashed password instead, since it's still valid password data as far as the server is concerned. If you as a service provider want to deal with an encrypted password at all times then why not just do that at the server end? And as the parent said, if as a client you can't trust the intentions of the server with respect to your password then encrypting it locally does nothing when they hold the keys to decrypt it, and provide the software you're using to do the encryption and transmission.
  - TheDong 11y ago
    It actually is a feature that adds value though. The way it worked was valve provides the RSA mod, exponent, and a timestamp. You rsa-encrypted your password with that information and send it. They double checked server-side that you encrypted it with that information, decrypt it with their private key, and get on with checking against the hash in the database. What this buys you is that if an attacker intercepts that login, it can't be re-used. Next time, valve will give a different mod and exp. Next time the valid encrypted password will be different. It turns the user typing the same password every time into a new encrypted value each time with each being valid for a short amount of time. So that's what RSA buys you here.
    - codexon 11y ago
      TLS already ensures that the attacker cannot intercept the login. If you cannot trust the TLS connection, all bets are off.
      - TheDong 11y ago
phlo 11y ago
> [...] JS crypto isn't going to do anything. It may have provided a little bit of extra protection in some scenarios. For example, many trojans will grab any HTTP(S) POST data from your browser. If such a trojan is not specifically configured to grab Steam data, hashing/encrypting client-side will provide some protection.

by codexon 11y ago

ejcx 11y ago

It highlights how incompetent Valve is at security. Adding one feature shows they are incompetent at security? Great real. Without more information about the scheme there's nothing to know. Whether useful or not it is still neat and can be used for benefit, but not for something TLS like.

codexon 11y ago
Yes, it does. It was a complete waste of time and does nothing useful except chew more CPU cycles. This is why all the security experts say that JS crypto is useless.
- ejcx 11y ago
  I'm not going to argue but I might as well explain some of the uses here. For example, encrypting clientside and not decrypting serverside will mean it's impossible to have a plaintext password leak in the future, which decreases risk. It also forces passive MITM to become active. Turning Eve into Mallory gives theoretical attackers much more work. There are more benefits beyond this. What you're thinking of is using this for actual password protection, which it won't provide. It can't be used as a TLS replacement. If you've actually read tptacek's big blog post about this you would notice it has to do with using js crypto being used to protect something, which this won't provide, but it can successfully be used to protect a service from itself and many other things. It's impossible to know all the details and benefits and pitfalls of their scheme though, without all the code from the server too.
  - phlo 11y ago
    > encrypting clientside and not decrypting serverside [...] ...will also enable anyone with the encrypted password to log in, in a sort of pass-the-hash scenario. To protect against plaintext password leaks, you'll want to run PBKDF/*crypt on the server, not encrypt the password. See the Adobe password leak for the gory details.
danparsonson 11y ago
Adding a feature that feels like security but actually isn't, would not be a good sign that they have a good understanding of web security. What's the difference between 'client sends plaintext password' and 'client sends encrypted password' from the point of view of an attacker? All you're aiming to prevent is client-side interception but in reality it doesn't matter what you do to the password locally - if what you send is what the server expects then you still get in; the encrypted plaintext effectively becomes the password. Thus an attacker who can intercept a plaintext password is at no disadvantage intercepting an encrypted or hashed password instead, since it's still valid password data as far as the server is concerned. If you as a service provider want to deal with an encrypted password at all times then why not just do that at the server end? And as the parent said, if as a client you can't trust the intentions of the server with respect to your password then encrypting it locally does nothing when they hold the keys to decrypt it, and provide the software you're using to do the encryption and transmission.
- TheDong 11y ago
  It actually is a feature that adds value though. The way it worked was valve provides the RSA mod, exponent, and a timestamp. You rsa-encrypted your password with that information and send it. They double checked server-side that you encrypted it with that information, decrypt it with their private key, and get on with checking against the hash in the database. What this buys you is that if an attacker intercepts that login, it can't be re-used. Next time, valve will give a different mod and exp. Next time the valid encrypted password will be different. It turns the user typing the same password every time into a new encrypted value each time with each being valid for a short amount of time. So that's what RSA buys you here.
  - codexon 11y ago
    TLS already ensures that the attacker cannot intercept the login. If you cannot trust the TLS connection, all bets are off.
    - TheDong 11y ago

phlo 11y ago

> [...] JS crypto isn't going to do anything. It may have provided a little bit of extra protection in some scenarios. For example, many trojans will grab any HTTP(S) POST data from your browser. If such a trojan is not specifically configured to grab Steam data, hashing/encrypting client-side will provide some protection.