(And the authentication protocol would be changed to verify possession of that hash rather than the password itself.) That way, not only do you avoid leaking the password itself, you ensure the hash can’t be used to connect to any other machines that use the same password. Right, but that means that what you actually want to do is store a hash of the password salted based on the identity of the machine you’re connecting to.
I'm going to research if I can get a CVE assigned to that. And don't leave backups of your saved passwords in insecure locations. My security advice here is simple: Don't save passwords to your local machine if you don't want them saved to your local machine. So my question would be: Describe the scenario where a bad actor has the ability to arbitrarily read data within a user's execution context, but not manipulate the TeamViewer Client also running in that same user's context? Because I got nothing. injected DLL, UI hooks, other misc memory hooks, etc). It works essentially the same way as their current method, but Windows is responsible for protecting the encryption key (and has a broker than can house it at a higher privilege level).īut ultimately if you have a process running in the user's context and can manipulate the TeamViewer client, you can bypass the Data Protection API pretty trivially (e.g.
How to hide teamviewer panel upgrade#
One potential upgrade might be to use Windows' Data Protection API. Storing it in the user's registry hive instead of a higher privilege allows the TeamViewer client to run in the user's context, instead of needing to run as administrator, have a broker, or similar. It is still marginally better than storing the actual plain text even if it is security through obscurity (using a hard-coded key in this case).
Using reversible encryption is unavoidable, because they ultimately need plain text to send to the TeamViewer remote service. The rules that apply to servers/services aren't the same as those for clients/saved logins. A hashed password cannot be stored, otherwise that hashed password becomes the plain text password anyway (essentially destroying any benefit hashing would have here). When the user hits "save password" on the client-side, the client needs to save the actual (plain text) password in order to replay it for future logins. They're doing nothing too wrong, the person criticising them doesn't understand basic computer security.