Secrets Vault - store secrets within TiddlyWiki5

Plugins
,
#1

Hi dear TiddlyWikians!

I’ve created a plugin that I’m going to use for my own purposes and I want to share it with you:

It’s a vault for secrets that gets unlocked with a master password
No secret is ever stored in plain text in any tiddler
Secrets are encrypted using Web Crypto API and stored in the $:/secrets/vault tiddler
There’s a special syntax for displaying secrets: §[secret:<secret-name>]
There’s a dedicated “secrets” editor toolbar button that lists all secrets for convenient insertion in the text editor
Clicking a rendered secret-name reveals the secret, ctrl-click copies the secret without revealing it

What do you think about this plugin?
Would you use it? Do you have security concerns?

Thanks for your interest and feedback and best wishes from Southtyrol,
Simon aka BTC

10 Likes
#2

I don’t have any immediate need for it, but I can see how it could be very useful!

I’d have to think it through some more, but if you’re using the Crypto API, I have no immediate concerns.

#3

I will be looking at this very closely, as it sounds like it might fit a specific need I have (and with a soft deadline only a week away) very well.

I had been looking at the Encrypt Tiddler Plugin - which encrypts whole tids, and has the downside of being fully decrypted (and via node, saved to disk) as soon as it’s decrypted in browser, and then requiring encryption all over again (to then save the crypt version to disk)

A secret that isn’t the whole tid, and which is ALWAYS kept encrypted (and only unencrypted in-browser) is kind of perfect.

At first glance my thoughts are not from a security perspective (I simply dont have the skills beyond very basics), but from a UI perspective - I think the Vault Manager should have ‘view’ and ‘copy’ columns. Maybe ‘duplicate’ and ‘edit’ functions too? - I see the vault has metadata about each secret, which looks to be prepared for the possibility of editing secrets. That created and modified metadata should be visible in the vault too. I’d also suggest within the metadata, a non-encrypted comment to go with each secret

Within rendered content. I think it’d help to have the ‘copy’ button in the non-revealed form - maybe use the typical ‘copy’ icon ($:/core/images/copy-clipboard)? The revealed secret being between the title and the copy icon would then

When adding a secret, it’d be good to be able to view what’s being added. At the moment if I add a secret, it’s typed hidden, and to check I have it right, I have to save the secret, then add it to a tid!

Oh, and testing that I just found the order of secrets within the editor menu item, is confusingly different to the order within the vault (toolbar seems to be in alphabetical order, vault seems to be in added order).

Anyway, I didn’t mean to write so much straight up! I’m coming from a place of enthusiasm here! :smiley:

2 Likes
#4

This is amazing, while the current design is very helpful for me to store my pass words I also would like to use it like below:

  1. Through a view template, or toolbar button I could see a lock pad button on the tiddler
  2. Secret vault works as describe by the original post, but also on tiddler
  3. The key is the tiddler tittle, the value is JSON including all tiddler fields. (this may need a complex nested JSON structure as @etardiff wished here Wishlist: Better support for nested JSON tiddlers - Discussion - Talk TW)
  4. The encrypted tiddler is vanished on clicking the pad lock
  5. To open an encrypted tiddler, do as explained in original post
  6. An unencrypted tiddler is recreated the tiddler from JSON stored in secret vault.
#5

Hi @nemo

I’m glad you find this useful

Yes, I’ll add them

I’m inclined not to add this functionality because I’m not sure what the security impact is

The metadata internally adds a layer of security, it’s just used for that

I’ve now added such a copy-to-clipboard button

I’ve added an “eye” icon which allows displaying what has been written in the password / secret input

I’ve fixed the vault manager to also display secrets in alphabetical order

Thanks for your feedback @nemo , very helpful!

2 Likes
#6

Hi @Mohammad and thanks for your feedback!

By design this works only with fields in the $:/secrets/vault tiddler and I’m not about to change that
The secrets inputs and password inputs are encapsulated in Shadow DOM with mode: “closed” for another layer of “security” for what it’s worth. So it’s not feasible for me to change the behavior so that this encrypts a tiddler. There may be other and better solutions for that.

#7

For a multi-user “password vault” solution, check out TiddlyTools/Panels/Security and TiddlyTools/Panels/Security/Help.

As with your Secrets Vault, it uses encrypted tiddler content to store sensitive information directly in the TiddlyWiki file. However, unlike your Secrets Vault, the TiddlyTools/Panels/Security interface lets you define multiple “usernames”, each with their own password.

To enter and encrypt data, the TiddlyTools Security panel uses forms that are defined as separate tiddlers (see TiddlyTools/Panels/Security/Google and TiddlyTools/Panels/Security/Contact for examples). These tiddlers each contain an items field that defines the layout for individual form inputs and the tiddler’s text field can be used to provide optional instructions or related information. You can add your own custom forms to the Security panel interface by creating additional TiddlyTools/Panels/Security/* tiddlers.

When you enter and save form data for a specific username, the data is encrypted using a custom encrypt[...] filter operator (see TiddlyTools/Filters/encrypt.js). When you subsequently select a saved username, you are prompted to enter the associated password which is used with a custom decrypt[...] filter operator (also defined in TiddlyTools/Filters/encrypt.js) to “unpack” the saved form data into an unencrypted JSON tiddler named $:/temp/TiddlyTools/Security.

You can then reference the indexes in this tiddler using TWCore standard getindex[...] filter operators or direct {{$:/temp/TiddlyTools/Security##indexname}} transclusion syntax. Note that $:/temp/... tiddlers are, by default, NOT saved with the TiddlyWiki file, so the unencrypted form data is automatically discarded when you save your Tiddlywiki. This effectively ensures that when you save and reload your TiddlyWiki, you are automatically “logged out”.

You can also use the Security panel input forms to enter temporary unencrypted information directly into the $:/temp/TiddlyTools/Security tiddler without saving it to a username. If TiddlyTools/Filters/encrypt.js has not been installed, or you choose to omit the password when saving a username, user-specific data is also stored without encryption.

enjoy,
-e

1 Like
#8

Revisions look great!

Thoughts on the quoted notes:

Fair enough that’s the internal use. But I think there is a legit user benefit to seeing them though - it’s good password policy to rotate passwords from time to time, and having visibility on when a secret was last changed would make this an easier option.

From a user perspective, they’re just shortcuts to ‘new (with prefilled content)’ and ‘delete+new’, but saves a level of copy+paste or re-typing. ‘Duplicate’ probably has less value than ‘edit’ which I think has real value, especially when combined with the ‘show creation/modification’ metadata for a secret.

Further thoughts:

I think the vault unlock prompt within the Vault Manager should allow paste, so the password to this vault can be stored and managed in another password manager. Curiously, the green prompt when a secret is clicked (and the vault is locked), DOES allow paste.

Beyond that I think my thoughts are getting more into aesthetics of the UI:

  • Vault manager - could be worth having the Actions to the left of the secret - ensuring the View/Hide button doesn’t change position when a secret is revealed
  • Still think the copy clipboard icon would be better than a big green ‘Copy’ when it’s inline in another tid - helps avoid it being read as part of a sentence when the secret name is written inline to other text
  • When it’s inline, consider changing the lock icon to an unlocked one, if the vault is unlocked? (I realise the presence/absence of the ‘copy’ also indicates this state). On my theme (Spartan Day with some tweaks) the lock emoji is also almost the same colour as the background orange of the key
    • perhaps both these could be done in CSS to allow easier user adjustment and theming? The .secret-container could be .secret-container-locked (and unlocked) with the relevant icon being a ::before content, and .copy-button class could be empty with ::before set to ‘copy’ or ‘⎘’ or other content to taste.
  • Autohide timeout setting should be exposed in the vault manager alongside the autolock timeout
  • consider avoiding browser popups entirely? When the password is wrong in the vault, it notifies within the vault. But when prompted from a locked key, the green secrets popup is within the TW page - and a wrong password on that generates a browser popup. Likewise if the secret is deleted by remains in the wikitext, clicking on it generates a browser popup.
  • the readme should have a link to the repo on github
  • The rate limiting - I feel that should indicate when it’s applied - I’m pretty sure I hit that in an early test when I semi-forgot what variant of a temporary password I’d used, and found it non-obvious what the issue was. (because it was testing, I ended up deleting the vault and paying more attention to what I was doing on the next round of testing!)

Final note - can confirm it works with a node TW setup as well (I would have been surprised if it hadn’t, but might be worth adding to the compatibility notes to reassure other potential users :slight_smile:

#9

I like it’s simplicity and ease of use. It could be a mini-password manager replacement with a couple of additions.

As the number of secrets grows, you need a filter to limit the secrets or to find a particular one. And it needs a copy button for the “secret” name because you often have to type that into a field as well. I guess having two fields per secret would actually be more normal, because for most services you need a username (which is kind of a secret) and the password.

I often have situations where I want to share just a few passwords between systems, or where I’ve created a new password on one system that I will later enter into my standard password vault. Sometimes these passwords end up in insecure text files. But the real problem is that when I find them I don’t remember what they were for. :flushed: .

Some of the “features” of standard password managers make simple tasks so frustrating. Like a fast timeout that forces you to re-enter a pin, and then when you get back to the site you were setting up it’s timed out. And don’t get me started on the security “asterisks” that hide your password while you’re working from an android device where you have trouble typing even when you can see what you’re typing.

#10

I second this. I do use a password vault. I think using a html password element helps detect the password, I wonder if this could optionally include User name, again which password vaults handle.

And how often is someone looking over your sholder to try and see your password? 99% of the time - never. ATM I am the only one in the house, I dont thing the cats or dogs will read my password, so why are they all “asterixed out”?

@BurningTreeC I am yet to fully experiment with your solution but wonder if it is valid to allow cookies or local storarge to keep the passwords so once entered, are retained in the local browser indefinatly?

#11

The $password widget does this. It renders as an HTML input control with type=password, which displays your input as asterisks. The text you enter is kept as an unencrypted plain-text value in LocalStorage. This value can only be accessed via TWCore javascript $tw.utils.getPassword(...), so it can’t “leak” out and be exposed by wikitext scripting.

However, because this value is NOT available for use in wikitext scripting, it can’t be used to submit URLs using a wikitext-based <$action-sendmessage> widget to dispatch a tm-http-request; for example, to access various remote services like the Google Places API for retrieving JSON address data, or showing embedded maps and streetview images.

Also, since the password text is kept in LocalStorage, it is inextrictably bound to a specific installed browser, and is not portable like other TiddlyWiki data.

This is where the Secrets Vault or my TiddlyTools Security Panel solutions come into play. They each permit “password-like” data values to be safely stored in an encrypted form within tiddlers, so those values can be later decrypted and used where ever that TiddlyWiki is accessed, even if it is a “traveling TiddlyWiki” that exists only on a USB stick and is regularly viewed with a variety of browsers installed on different systems.

-e

#12

I suppose one reason I value a saved password option is as long as you use a browser more than once you need not revert to your password vault on subsequent access. Like I suspect many people, I usualy dont use more than three devices Computer, tablet and Mobile. With these I dont use other devices such as Internet Cafes etc… I need the password so if others stumbled apon my content they cant Access it, for me I just want to store it and get it out of the way.

#13

Thanks to all for your feedback!

Now we can copy-paste into the inputs
Optionally a username can be specified which is connected to the secret

#14

It has potential to replace KeePassX on any system that can run a modern web browser, thus can run TiddlyWiki. And unfortunately, it is tethered by the same constraint that becomes a TiddlyWiki usage show stopper on any older computer that can’t run a modern web browser / Node.js. Think an old laptop running Linux in text mode only (yes I have one of those, I’m using it and I’m proud of that even if it’s not a ThinkPad! :rofl: ). In the future when this plugin matures, perhaps it could add a few custom importers/exporters for a GPG-compatible vault encrypted dump, a KeePass (which has a CLI-only mode) database or a pass directory tree (likely harder, because the TiddlyWiki importer can’t recursively import a whole directory tree, and the exporter can only save a single file as well, right?)

#15

@nemo yes you’re right and I’ve thought about it

  • passwords should show when they were created
  • passwords should be changeable

Yes, I’m also not happy with the current layout

Styling will be improved

Yes, I’ll add that!

Can you explain a little bit what you mean by that?

Yes that’s a good Idea, there should be an indicator for that!

Thanks again!

#16

Hi @Mark_S

That’s a good idea with the filter. Can you explain a bit more detailed how and where it should be implemented?

#17

Hi @TW_Tones

Can you explain for what that could be useful?