HTTP Auth Values and Secret Storage in Markdown Vaults

[asjones987]

Describe the bug

I understand the logic of keeping things simple and truly appreciate that. However it seems like passwords or other tokens should be encrypted when stored to disk or memory.

Ideally maybe a separate user/password/token storage place that is encrypted. Then variables name entered in the actual session. LIke:
Username: {{ERP_ID}}
Password: {{ERP_Password}}
or
Username: {{CRM_ID}}
Password: {{CRM_ID}}

That would be all that is seen in the file on disk and/or seen on the screen on the Auth page.

When run the variables would be dynamically and securely passed the actual user name and password.

This would be better in general and better in a shared GIT environment where the code snippets, notes, HTTP, etc.

The encrypted passwords would be in separate encrypted folder/file might or might not be synced to a GIT repository. ... Optional separate path for the folder/file for the passwords that may not necessary be in the same place as the rest of the user data.

To reproduce

1. Go to ...
2. Click on ...
3. Scroll down to ..
4. See error

App Version and Architecture

5.3.0

System info

Windows 11

Validations

• Follow our Code of Conduct
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.

[antonreshetov]

Thanks for raising this. This is a valid concern for shared or Git-backed vaults, but I wouldn’t classify it as a bug in the current storage model.

massCode v5 uses a simple local Markdown vault, so HTTP auth values are stored as user content. Real secrets should not be committed or shared through the vault.

I’d treat this as a feature request/discussion for secret variables or environments stored outside the vault.

I'll also update the documentation to make this clearer.

[asjones987]

You are correct. It is not really a bug as it is working as designed. However I might suggest even in a single user environment it is not a best practice to store passwords in the clear.

I my ideal world I would love to see it separated out as described.

Hopefully this is something you will consider and will benefit others.

thanks

Alan