Plaintext password storage

[Kirizan]

You are storing the bindpassword as a plain text field in settings.json. VS Code has a secret store capability, that should be used for storing secrets.

[fengtan]

Thanks for the feedback!

If the concern is that passwords may end up in version control then you may resort to environment variables (syntax: ${my-env-var}). That won't protect your password in case the system is compromised though, so storing passwords using SecretStorage certainly sounds worthy!

[Kirizan]

The problem isn't a password ending up in version control (that's a problem, but not that one I have with this setup).

The problem is the majority of people who need to use an LDAP browser are working for companies that likely have security requirements. Not storing your domain password in plain text is usually one of the first password requirements.

It shouldn't be an option to store passwords in plain text in 2025. VScode provides access to a secret store from their API, I would recommend implementing that in this extension to prevent plain text password storage.

At a minimum, the description should warn people that the bindpassword is stored in plain text. This way people who have to follow specific requirements for their corporate machines will be able to make decisions based on their corporate requirements.

[fengtan]

I checked what a few other tools do:

• SQLTools lets users decide, for each connection, whether the password should be
  • Stored in secret storage (default option)
  • Stored as plaintext in settings
  • Asked on connect
  • (Empty)

• Apache Directory Studio stores passwords as plain text in a local file
• JXplorer stores passwords "internally"

I have to say I like the approach of SQLTools. By default new passwords are saved in secret storage however regular settings are still supported at least for backwards compatibility. For reference this was implemented in mtxr/vscode-sqltools#1066.

[Kirizan]

That would be great! I would love to be able to use this again, having an easy LDAP search directly in VS Code would be great!

[fengtan]

#65 adds a new field Bind Password mode on the connection edit screen that lets you choose where the password should be stored (similar to SQLTools):

While I was there I also implemented an option Ask on connect for users who do not want to store the password at all on the machine.

If the user chooses to store it as a secret then they will have no way to check the current value of a password. This may be annoying, so I also added a button to reveal or hide the value of that field:

@Kirizan would you like to test this? The .vsix archive can be downloaded here (this URL can be found by going to #65 > tab Checks > tab build (ubuntu-latest) > section Upload package as artifact > last line).

The .vsix archive can be installed locally like this:

[Kirizan]

@fengtan This is exactly what I was hoping for!

Quick note for clarity: When a password is stored in secret storage, you can't just reveal it in the settings. You can only reveal it when you type it in, which is exactly how it should be from a security standpoint. Once I save the connection, if I leave and browse back to the connection settings, the bind password field appears blank, which is how it should work ideally. It means if someone leaves their computer unlocked, someone can't just open the LDAP settings and view their password real quick, which is something I've seen done with other tools that stored passwords in plain text.

Those of us who work IT security thank you for helping us keep environments secure!

[fengtan]

Thanks for testing @Kirizan !

The behavior you describe was actually not implemented on purpose. It is true that this makes it harder for someone to steal a password, but at the same time it means you have to re-enter the password every time you need to edit and save the connection settings (say, if you want to change the timeout) otherwise you'll end up with an empty password and won't be able to connect. Which is not super convenient.

I was able to confirm that giving the user the option to unmask a password is generally a good idea:

• OWASP - Application Security Verification Standard (ASVS):

2.1.12 Verify that password input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password.

• NIST - Authentication and Lifecycle Management:

5.1.1.2 In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD
offer an option to display the secret — rather than a series of dots or asterisks — until it is
entered. This allows the claimant to verify their entry if they are in a location where their screen
is unlikely to be observed. The verifier MAY also permit the user’s device to display individual
entered characters for a short time after each character is typed to verify correct entry. This is
particularly applicable on mobile devices.

However I could not find any references on how to deal with the UX issue I mentioned above (empty default password when editing the connection forces user to re-enter password value).

I guess one option is to not save the password field when it is empty so the existing password is not overwritten. That might explain why SQLTools has a password mode Use empty password.

[fengtan]

I have updated #65 to address the UX issue I mentioned above. Now if you edit a connection which password mode is Store encrypted in secret storage, leave the password empty, and re-save the connection, then the password will be left untouched in secret storage (i.e. it won't be changed to an empty string).

Summary of how the field behaves:

I am going to leave the pull request hanging for a few days in case there is additional feedback, and if not I'll merge and make a new release.

[fengtan]

Merged #65 and released as part of 1.5.0. Thanks again @Kirizan !