TeamViewer stores user passwords in registry, encrypted with hard-coded key

> A hashed password cannot be stored, otherwise that hashed password becomes the plain text password anyway (essentially destroying any benefit hashing would have here).

The plaintext password may be re-used by the user on other systems, so yes hashing would still benefit here.

A smart use of "save password" is where you authenticate and store the login token locally. You can then log in without a password, but also your session can be invalidated any time you say... change your password, or ask for a session to be kicked off.

We have to do this with web apps all the time. Nobody stores passwords in local browser store.

What you normally do in this scenario (which is similar to a cookie), is to have an "Remember me" option that generates a unique token you can use to log in with. It's not your password, and ideally you can look in your online account and see what devices has such a token and revoke access.

> When the user hits "save password" on the client-side, the client needs to save the actual (plain text) password in order to reply it for future logins.

Since there's a central server involved in this authentication (as far as I understand how TV works), that's not the only way to do this, nor is it the best way. A better way is to store some other token that can be used to verify that the user has logged in before and has a valid session, one way to do that is to sign and encrypt data saying which user they were logged in as. This prevents the password itself from ever being retrieved even if they can still use it to impersonate the user to TV

Tokens were introduced to avoid saving passwords anywhere and they have the benefit of expiration.

Don't save plaintext passwords. Ever. It's really that simple. Why is this still an issue in 2019/2020?

Do I understand correctly - it's the same reason why browsers keep plain text passwords locally when the users selects to save them?

[0] https://security.stackexchange.com/questions/170481/how-secu...

Storing a hash would be better because it wouldn't leak the actual password. People have a tendency to use the same password over again as well as sharing them between logins, so this is bad.

Not using the Data Protection API makes it easier to extract the password.

So while you're right that storing the password has some consequences, they should have done better, especially since their product is focused towards non-techs as well.

> 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.

It's still insecure to store a user password as-is. TeamViewer should create an session key of some sort that is unique to this machine instead of replaying the username/password.

I am not familiar with Team Viewer but you’re correct: any software that allows you to “save passwords for later use” is writing your password to disk/cloud — maybe reversibly encrypted but decipherable all the same, especially if the keys are held locally for offline use.

IIRC Chrome used to do this until 2013, for example, and resisted fixing it saying your OS account should protect you[1]. I suspect these days it’s encrypted to your Google Account as it’s synced, and additionally requires you to re-enter your OS password.

[1] https://news.ycombinator.com/item?id=6166793

PS. Does anyone know what Firefox does these days with their master password, especially now that they too ship a password manager? Their master password approach was similarly criticised [2].

[2] https://nakedsecurity.sophos.com/2018/03/20/nine-years-on-fi...

They also used CBC over EBC for the encryption mode. Which is good. Looks like they were at least trying to keep it safe.

Storing password encrypted or a function of the original password (hashed) is all wrong and the entire premise of the post follows suit.

After a successful authentication with username/password - store a one time token (randomly generated) on the client. Each time the token is used - generate a new one. That's it. On the server store a hash of that token, so getting the database of tokens does nothing, either.

The user retains ability to revoke any tokens at any time and also to know where they have been stored and used (if they choose to name a device/storage)

The article doesn't say anything about hashing the password, this is a perfect case of the title having a large influence on how we read the article.

@dang This title is misleading.

FWIW, it's still better that the thing you save is a hash, because that's less useful for cracking other related passwords than the raw password itself.

E.g. If you make your password to access your home computer "eb49wsrew-home" ... what are the odds that the password for your work computer is "eb49wsrew-work"?

In an ideal world passwords would be independently selected, but we write software for non-ideal users in a non-ideal world.

> 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.

If there was a system service which you could hand a read only secret and then it could perform challenge response queries of the form response = H(secret||challenge), and had the server send a fresh random challenge on every every connection then you could have a setup where even if the attacker could run as teamviewer (but not the system admin) he couldn't steal the credential he could only make use of it.

When you save your credential you'd hash the password, the server would also store the same hashed password. You'd send the hashed password to the system service, and the server could challenge your knowledge of it. For bonus points, have the service implement some simple ZKP (such as SRP) so being able to observe the challenge-responses doesn't allow you to grind offline attack the password.

This would be at least a small improvement.

The normal thing to do here is to use the credential just once to generate a (revocable) token, and to store that (reversibly encrypted). Especially if you own both sides of the connection, it is in fact a bad idea to store user passwords; they're irrevocable and inevitably shared across services.

As security advice for developers, the writeup you're commenting about isn't especially useful. But that's not the point. It's a standard consulting war story post, about how they managed step-by-step to exploit a weakness in an application. As a war story, it seems plenty competent.

I agree with your arguments.. however the unanswered question is why the passwords need to be stored locally at all?

The passwords are saved to your Teamviewer profile which exists on their servers. It seems like it would be safer to request and decrypt only when needed by an authorized user, rather than storing it for someone else to find.

Storing a bearer token in the registry means that anyone who compromises the registry once gets persistent access. There are multiple solutions:

1. Store a token that is replaced with a new token on every successful connection. This makes it very obvious if the token is stolen: either the stolen token stops working quickly or your connection stops working.

2. Store a key using a privileged service (TPM, Microsoft KSP, etc) that provides only the ability to use the key, not to read it.

3. Both 1 and 2.

The solution is to hash the password once, salted, and store and use that as a plaintext equivalent instead of storing the real password. This way if the password is reused on other services and an attacker retrieves it from the store it isn’t as much of a disaster.

See also:

https://www.nirsoft.net/password_recovery_tools.html

As you say, if you have to save the passwords locally, you have to save them locally. Web browsers that save passwords and password managers like LastPass all have to do this.

If you look in the Windows "Control Panel" app you'll see something called "Credential manager" that provides an API for saving passwords.

Well, the key isn't hardcoded in the browser implementation. (It's unique per-install)

And I think browsers generally do a better job using OS security mechanisms to restrict access to that key, too.

Browser have no other choice - but if you control the server and the client - there are ==a lot== better mechanism to store auth. info.

No- Chrome actually uses the Windows DPAPI, which encrypts passwords using your user login credentials. 3rd party password managers use a master password with a PBKDF.

IIRC, in the case of firefox, a key is generated at profile creation, and then the password saved are encrypted using this key.

It's basically security through obscurity as the key stays clear text UNLESS the profile is protected by a password a human must type every times he opens Firefox.

'Cause a whole bunch of people don't know how to do security.

You'd be surprised how many people come up with this then don't think any further.

This is the kind of solution I see from new grads with no crypto/security experience, but whom with a quick frown, think about it a little more and suggest why this is a bad idea. Many can do that even when they don't know how exactly to do it correctly.

This was just lazy/rushed or dare I say it, negligent.

It was the quick thing to do. I bet the have a "technical debt" story on the backlog that they're never able to get to.

$employer has recently been acquired by a big international corp. As part of the acquisition they have been "auditing" (really checkbox ticking and superficial API scans) our applications. One of the issues that came up is that we were using bcrypt as password hashing algo and our new overlords had a whitelist policy that only included sha2 variants and perhaps ripemd or something like that. We argued that their whitelist was totally inadequate for password hashing and pointed to multiple national standards bodies. The people doing the audit just ignored everything we explained to them and repeatedly pointed at the policy (which they weren't in charge of themselves).

Several people on my team were opining to just comply because it's the easiest way to do and they were concerned about their job security if they would go "against security".

My takeaway from that experience was that the people in charge of corporate security policies and audits are not experts in security, they are experts in reshuffling responsibility and covering asses. And many developers are easily cowed by them.

The result is compliant software, not secure software.

> and then use a hardcoded key to encrypt them

Ask this question instead: Why bother to encrypt them in the first place?

What is the attack scenario you are trying to defend against? This is local software - it need to be able to decrypt the key and use it to login.

So at the end of the day it's the same machine with the password and the key to decrypt the password. It seems pretty pointless to even encrypt them in the first place.

So why do it? I don't know, maybe just to make it marginally harder to see the password. If that's the entire goal, there isn't really any reason no to use a hardcoded key - it accomplishes that goal just fine.

Ask yourself this: What attack scenario would a different key per machine defend against that a hardcoded key would not?

So that that if you're browsing your registry and someone looks at your screen, that person doesn't get your password.

>Send email to the Director of Security November 14th, 2019

>Send email to Director of Security notifying them there is now a CVE assigned to this November 18th, 2019

>Receive first and only email back from vendor “We’re looking into it” email January 13th

Good one TV.

Yeah just checked Anydesk, 100 Euros a Year and no online address book really?

VNC?

Not all AES implementations will use AESNI instructions. Support for those instructions is relatively new -- many systems in productions still lack them -- and they're hardly necessary for a non-performance-critical implementation like this one.

A better signal is the presence of the S-box tables (63 7C 77 7B...). Even that won't detect applications which use an implementation from a shared library, though.

I guess when you've used those credentials on a windows machine?

I've taken a crack at rewriting the title. If anyone can suggest a better one (i.e. more accurate and neutral, preferably using representative language from the article), we can change it again.

“I don’t like dark themes” would have been an adequate critique.

IMHO, the website was a wonderful and easy-on-the-eyes experience to read.

I am visually impaired. I need sites to look like this just to consume them.

This was my experience and yours was different. Being able to let the viewer choose is critical so that everybody can use the web.

I also can’t read it as is, but it’s even worse than that: the page is not compatible with Reader View on iOS Safari.

Why is that demoralizing? Even if you're a mediocre programmer, you're miles ahead of the industry standard. It's a good time to earn money.

It isn't a lost cause. The lessons are:

  Security is high stakes
  Security is hard

https://blog.codinghorror.com/youre-probably-storing-passwor...

This particular issue reeks of "roll your own" when a lot of out-of-box token based solutions would just do a better job. The best lesson to learn about security in software is that if you're doing it and you don't have a PhD you're doing it wrong.

The benefits of leaning on a third party for common logic should be carefully reviewed on a case-by-case basis unless that software is related to security, in which case, please do lean on a third party.