1. 20
  1.  

  2. 5

    The problem is more that the infosec community doesn’t understand the purpose of this password storage. Arguably they should have used the OS level secret store API, but if any program can access it, any script or exploit can access it. TeamViewer probably chose to use passwords for consumer security, not enterprise level security. It ends up having about as much privacy as memfrob(3), but at some level it’s hard to secure secrets so that the right programs can access them and the wrong programs cannot.

    1. 4

      not hashed

      If the password needs to be used again later, how will the hash be useful?

      1. 4

        Raw passwords shouldn’t be needed again. Best practice to keep them salted and hashed, and compare the user’s input to the hash, not a raw password.

        1. 6

          If the server does the hashing, then the client has to cache the raw password.

          1. 4

            The blog post isn’t extremely clear, but it’s my understanding that this issue is related to a kind of “remember my password”-type feature; the client remembers your password for you. If that’s the case, the fact that it’s “encrypted, not hashed” is a red herring; when you need to get the plaintext back, you obviously can’t store the password hashed.

            The blog post is so full of irrelevant details that it’s hard to figure out what the actual problem is, and the CVE mentioned (CVE-2019-18988) doesn’t seem to be public yet - but the problem certainly isn’t that TeamViewer didn’t store the password hashed, because hashing isn’t applicable here.