8 ms·

They're doing nothing too wrong, the person criticising them doesn't understand basic computer security. When the user hits "save password" on the client-side,

They're doing nothing too wrong, the person criticising them doesn't understand basic computer security. 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. 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 rules that apply to servers/services aren't the same as those for clients/saved logins. Using reversible encryption is unavoidable, because they ultimately need plain text to send to the TeamViewer remote service. 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). 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. One potential upgrade might be to use Windows' Data Protection API. 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). But 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. injected DLL, UI hooks, other misc memory hooks, etc). 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. 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. And don't leave backups of your saved passwords in insecure locations. I'm going to research if I can get a CVE assigned to that.

mooneater 7y ago
> 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.
- wlesieutre 7y ago
  I think parent is saying you can't have a login system where you store the hashed password locally and then log in by sending the hashed password to the server. The hashing to validate a password has to happen on the server, otherwise anyone could get a copy of your hashed password and submit it as a login. But as other replies have pointed out, you can generate a login token to offer a "save password" feature without actually saving the password to disk.
Justsignedup 7y ago
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.
- Someone1234 7y ago
  I don't know if that applies to TV's circumstances because you can use the client to connect to endpoints without either end being internet accessible. TeamViewer does operate account infrastructure like you're describing, but that isn't exclusively what they offer. They do point-to-point too.
  - NieDzejkob 7y ago
    I don't see how network position relates to the authentication scheme. As far as I can see, these are entirely separate issues, handled at different layers of the OSI stack.
  - Nullabillity 7y ago
    The TV host could issue its own persistent tokens, no internet access required.
  - signal11 7y ago
    Yes, looking at this page it’s possible to disconnect the client from Team Viewer’s online infrastructure entirely: https://community.teamviewer.com/t5/Knowledge-Base/Can-TeamViewer-be-used-within-a-local-network-LAN-only/ta-p/4618 https://community.teamviewer.com/t5/Knowledge-Base/Can-TeamV... > Hint: If you choose Accept exclusively, TeamViewer will disconnect from the internet – that means it will no longer be possible to make or receive connections using the TeamViewer ID, and the Computer & Contacts list will no longer be available.
- gowld 7y ago
  > Nobody stores passwords in local browser store. Yes, quite many body do: chrome://settings/passwords
continuational 7y ago
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.
- xxs 7y ago
  Also the token should be regenerated as well on use, not stored as plaintext token, either. But yeah - the idea to store plaintext password encrypted or hashed is just stupid.
simcop2387 7y ago
> 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
- pushrax 7y ago
  These are the ways the strategies differ: - a token can be invalidated individually, while resetting a password invalidates all sessions - a token can be given a predetermined expiry without the issues that arise from predetermined password expiry - a token can be given a limited permission set - a token can be used to track the origin and extent of an attack In practise for something like TeamViewer I find it likely that none of these except the first would be implemented. If the attacker has access to the registry chances are you're f*cked anyway.
  - Daniel_sk 7y ago
    Also - a token can’t be used to change your password or steal the account completely. The app can ask you to enter your password again if you are doing these changes to your account. A token would not allow the attacker to pass this.
- sowbug 7y ago
  It is the only way if the action is labeled "save password," rather than "stay signed in" or "authorize this device" or similar. It's a subtle distinction for the average user who doesn't care, but for a sophisticated user it does indicate a specific kind of behavior, and the relevance is what you do in case of compromise. Do you change your password and make the eavesdropped one useless? Do you deauthorize the stolen computer via a centralized interface?
0xff00ffee 7y ago
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?
- deleted 7y ago
  [deleted]
- gowld 7y ago
  > Tokens were introduced before 1990 https://en.wikipedia.org/wiki/Kerberos_(protocol) https://en.wikipedia.org/wiki/Kerberos_(protocol)
  - 0xff00ffee 7y ago
    Precisely.
- mcny 7y ago
  > Don't save plaintext passwords. Ever. Sorry if I am saying something obvious but just so I understand... we need Team viewer to expose some way for a program to send a username and a password and team viewer then sends back a token saying store this instead. Now, every time the client makes a request, it should use this token? and if the client tries to use a user password, refuse? Thank you
  - munk-a 7y ago
    When the user initially attempts to authenticate into Team Viewer send the user a randomly generated (not-derived off of user information at least) token in the response and register it with a data-store on the server. From that point on the user can re-authenticate with Team Viewer by sending the token until, for some reason, you decide to invalidate the token on the server - then the user is forced to re-authenticate with their password. At any point before their token is forcefully invalidated the user can optionally re-authenticate with their password to get a new token. That's the general gist, but if you're thinking of writing some software for it I'd suggest searching out some third party tool to manage these tokens for you or, if you're unable to find anything, then doing a bit of research into the pitfalls you can run into with this approach. The less you write in-house the better.
ggerganov 7y ago
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-secure-is-chrome-storing-a-password https://security.stackexchange.com/questions/170481/how-secu...
- professorTuring 7y ago
  No, you can only access browser's stored passwords if you can log in as the user in the machine (see second response). In this case, anyone can access that registry and get the pwd.
magicalhippo 7y ago
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.
m-p-3 7y ago
> 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.
signal11 7y ago
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 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-firefoxs-master-password-is-still-insecure/ https://nakedsecurity.sophos.com/2018/03/20/nine-years-on-fi...
- nightcracker 7y ago
  This is trivially solvable by salted hashing twice, once client side (which then can get saved post hash) and once server side.
  - marcinzm 7y ago
    That doesn't help you since you authenticate using the client hash so knowing that lets you authenticate remotely anyway. It only protects you against a password that was reused for something else as well.
    - nightcracker 7y ago
      > It only protects you against a password that was reused for something else as well. That was the thing I was protecting against... Of course, no matter what form the access token takes when you press "Keep me logged in" allows you to authenticate remotely.
- dx034 7y ago
  Firefox encrypts passwords with your master password. The clear downside is that you lose all data if you forget your password. That's clearly good for security but I don't think it's an option for most services.
anon176 7y ago
They also used CBC over EBC for the encryption mode. Which is good. Looks like they were at least trying to keep it safe.
- mothershipper 7y ago
  Assuming one byte per character, you'd have to have a 17 character password before you're using multiple blocks. For any password shorter than that, this cipher is pretty much operating in ECB mode due to the re-used IV.
xxs 7y ago
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)
pcmonk 7y ago
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.
nullc 7y ago
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.
tptacek 7y ago
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.
- Polylactic_acid 7y ago
  If you are able to grab the users password off of their computer then you are able to capture it as they type it. Passwords are stored unencrypted on computers all the time, your browser stores passwords.
  - closeparen 7y ago
    Reading keystrokes sent to other applications requires higher privileges than reading registry and filesystem, no?
    - _nedR 7y ago
      Not on linux/x.org (wayland is more secure)for certain... i am guessing not on windows either but i am not sure...
  - tptacek 7y ago
    The point of tokenizing is to minimize the number of times you ever need to handle the actual password, in part to avoid exactly those attacks.
kjaftaedi 7y ago
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.
amluto 7y ago
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.
tinus_hn 7y ago
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.
e12e 7y ago
See also: https://www.nirsoft.net/password_recovery_tools.html https://www.nirsoft.net/password_recovery_tools.html
RachelF 7y ago
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.
deleted 7y ago
[deleted]

mooneater 7y ago

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

wlesieutre 7y ago
I think parent is saying you can't have a login system where you store the hashed password locally and then log in by sending the hashed password to the server. The hashing to validate a password has to happen on the server, otherwise anyone could get a copy of your hashed password and submit it as a login. But as other replies have pointed out, you can generate a login token to offer a "save password" feature without actually saving the password to disk.

Justsignedup 7y ago

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.

Someone1234 7y ago
I don't know if that applies to TV's circumstances because you can use the client to connect to endpoints without either end being internet accessible. TeamViewer does operate account infrastructure like you're describing, but that isn't exclusively what they offer. They do point-to-point too.
- NieDzejkob 7y ago
  I don't see how network position relates to the authentication scheme. As far as I can see, these are entirely separate issues, handled at different layers of the OSI stack.
- Nullabillity 7y ago
  The TV host could issue its own persistent tokens, no internet access required.
- signal11 7y ago
  Yes, looking at this page it’s possible to disconnect the client from Team Viewer’s online infrastructure entirely: https://community.teamviewer.com/t5/Knowledge-Base/Can-TeamViewer-be-used-within-a-local-network-LAN-only/ta-p/4618 https://community.teamviewer.com/t5/Knowledge-Base/Can-TeamV... > Hint: If you choose Accept exclusively, TeamViewer will disconnect from the internet – that means it will no longer be possible to make or receive connections using the TeamViewer ID, and the Computer & Contacts list will no longer be available.
gowld 7y ago
> Nobody stores passwords in local browser store. Yes, quite many body do: chrome://settings/passwords

continuational 7y ago

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.

xxs 7y ago
Also the token should be regenerated as well on use, not stored as plaintext token, either. But yeah - the idea to store plaintext password encrypted or hashed is just stupid.

simcop2387 7y ago

> 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

pushrax 7y ago
These are the ways the strategies differ: - a token can be invalidated individually, while resetting a password invalidates all sessions - a token can be given a predetermined expiry without the issues that arise from predetermined password expiry - a token can be given a limited permission set - a token can be used to track the origin and extent of an attack In practise for something like TeamViewer I find it likely that none of these except the first would be implemented. If the attacker has access to the registry chances are you're f*cked anyway.
- Daniel_sk 7y ago
  Also - a token can’t be used to change your password or steal the account completely. The app can ask you to enter your password again if you are doing these changes to your account. A token would not allow the attacker to pass this.
sowbug 7y ago
It is the only way if the action is labeled "save password," rather than "stay signed in" or "authorize this device" or similar. It's a subtle distinction for the average user who doesn't care, but for a sophisticated user it does indicate a specific kind of behavior, and the relevance is what you do in case of compromise. Do you change your password and make the eavesdropped one useless? Do you deauthorize the stolen computer via a centralized interface?

0xff00ffee 7y ago

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?

deleted 7y ago
[deleted]
gowld 7y ago
> Tokens were introduced before 1990 https://en.wikipedia.org/wiki/Kerberos_(protocol) https://en.wikipedia.org/wiki/Kerberos_(protocol)
- 0xff00ffee 7y ago
  Precisely.
mcny 7y ago
> Don't save plaintext passwords. Ever. Sorry if I am saying something obvious but just so I understand... we need Team viewer to expose some way for a program to send a username and a password and team viewer then sends back a token saying store this instead. Now, every time the client makes a request, it should use this token? and if the client tries to use a user password, refuse? Thank you
- munk-a 7y ago
  When the user initially attempts to authenticate into Team Viewer send the user a randomly generated (not-derived off of user information at least) token in the response and register it with a data-store on the server. From that point on the user can re-authenticate with Team Viewer by sending the token until, for some reason, you decide to invalidate the token on the server - then the user is forced to re-authenticate with their password. At any point before their token is forcefully invalidated the user can optionally re-authenticate with their password to get a new token. That's the general gist, but if you're thinking of writing some software for it I'd suggest searching out some third party tool to manage these tokens for you or, if you're unable to find anything, then doing a bit of research into the pitfalls you can run into with this approach. The less you write in-house the better.

ggerganov 7y ago

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-secure-is-chrome-storing-a-password https://security.stackexchange.com/questions/170481/how-secu...

professorTuring 7y ago
No, you can only access browser's stored passwords if you can log in as the user in the machine (see second response). In this case, anyone can access that registry and get the pwd.

magicalhippo 7y ago

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.

m-p-3 7y ago

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

signal11 7y ago

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 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-firefoxs-master-password-is-still-insecure/ https://nakedsecurity.sophos.com/2018/03/20/nine-years-on-fi...

nightcracker 7y ago
This is trivially solvable by salted hashing twice, once client side (which then can get saved post hash) and once server side.
- marcinzm 7y ago
  That doesn't help you since you authenticate using the client hash so knowing that lets you authenticate remotely anyway. It only protects you against a password that was reused for something else as well.
  - nightcracker 7y ago
    > It only protects you against a password that was reused for something else as well. That was the thing I was protecting against... Of course, no matter what form the access token takes when you press "Keep me logged in" allows you to authenticate remotely.
dx034 7y ago
Firefox encrypts passwords with your master password. The clear downside is that you lose all data if you forget your password. That's clearly good for security but I don't think it's an option for most services.

anon176 7y ago

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

mothershipper 7y ago
Assuming one byte per character, you'd have to have a 17 character password before you're using multiple blocks. For any password shorter than that, this cipher is pretty much operating in ECB mode due to the re-used IV.

xxs 7y ago

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)

pcmonk 7y ago

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.

nullc 7y ago

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.

tptacek 7y ago

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.

Polylactic_acid 7y ago
If you are able to grab the users password off of their computer then you are able to capture it as they type it. Passwords are stored unencrypted on computers all the time, your browser stores passwords.
- closeparen 7y ago
  Reading keystrokes sent to other applications requires higher privileges than reading registry and filesystem, no?
  - _nedR 7y ago
    Not on linux/x.org (wayland is more secure)for certain... i am guessing not on windows either but i am not sure...
- tptacek 7y ago
  The point of tokenizing is to minimize the number of times you ever need to handle the actual password, in part to avoid exactly those attacks.

kjaftaedi 7y ago

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.

amluto 7y ago

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.

tinus_hn 7y ago

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.

e12e 7y ago

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

RachelF 7y ago

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.

deleted 7y ago

[deleted]