Secrets Vault - store secrets within TiddlyWiki5

[BurningTreeC]

This gives a list of all secrets rendered:

\define render-secret() §[secret:$(secretName)$]

<$list filter="[[$:/secrets/vault]fields[]removeprefix[secret-]]" variable="secretName">
<<render-secret>><br>
</$list>

This gives a list of all secrets with a given username:

\define render-secret() §[secret:$(secretName)$]

<$let username="myUserName">
<$list filter="[[$:/secrets/vault]fields[]prefix[username-]]" variable="secret">
<%if [[$:/secrets/vault]get<secret>match<username>] %>
<$let secretName={{{ [<secret>removeprefix[username-]] }}}>
<<render-secret>><br>
</$let>
<% endif %>
</$list>
</$let>

[TW_Tones]

@BurningTreeC

@TW_Tones

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?

Hi @TW_Tones

Can you explain for what that could be useful?

If I maintain a database of secrets in a TiddlyWiki localy, I want it protected by a password, but on my home computer, safe in my study, I want to provide the password once and happy it is retained in local browser memory, so I need not type it again, however should the wiki itself be stolen they will not have the password.

• This password should be periodicaly changed see next note
• This could also be said for the username when used.
• Although sometimes I will have a password vault hold these credentials and insert when needed.

A Note on secrets

It is importiant for every one to note, that there is an internet wide collection of content containing encrypted content, it is thought by many criminals that if they cant decrypt it now, they may be able to in the near future.

So where possible’

• dont make encrypted content publicaly available lest it one day be decrypted
• continue to cycle and reencrypt content periodicaly such that stolen content “ages out”

[nemo]

@BurningTreeC

@nemo

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.

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

Attempting to unlock a vault from the vault manager reveals this in-page error:

However, if you click a secret when the vault is locked, you get the green vault prompt:

and failing the password there, returns an alert popup

That alert popup is what bothers me - I think all UI elements should be within TW

Also, a failure by this mode doesn’t inform of the lockout attempts remaining.

The other place that generates this alert popup is when you click a secret that doesn’t exist (I edited this one to mock it up, but originally encountered it by deleting a secret after adding the wikitext code for it)

---

Another thing I just noticed in testing:

Having a colon in the title messes things up.

From a fresh vault (which is a .tid in my node setup), I add this secret:

However the name has lost the colon, and the username isn’t shown at all:

Looking behind the scenes, the vault is now converted to a json, with the colon dropped from the secret- and meta- field names, but not the username- field name. IMHO any characters should be valid for the name, though I recognise this will complicate things, or give info and about valid/invalid characters within the name before saving. (Looks like []{}() are all similarly removed, I’ve not tested weird characters in the title beyond these seven)

This also has me noticing that the username is not encrypted, which I feel like it should be.

---

I should note - for my own intended use, this is already great - I currently don’t see my needs for the secrets stored in TW to require more than this already does. But thinking on the systems I’ve used (personal and professional, ranging from commercial products to home-grown wrapper scripts around gpg), I think my minimum requirements of what I’d want for a general purpose secret stash are:

• Four fields: name, username, secret, comment.
  • Name and Username both single line, secret and comment multiline (storing SSL certs and keys is common in work secret stores for instance).
  • Name and Comment public, username and secret encrypted
  • Name and Secret as required fields, username and comment as optional
• …I’m sure I had a second thing to note, but between investigating the :[]{}() thing, and then lunch it’s entirely escaped my mind and eluded any attempts to think of it again!

[BurningTreeC]

Hi @nemo and thanks for your valuable feedback!

Oh yes, I shouldn’t use the TiddlyWiki builtin password prompt I guess when clicking on secrets.
I’ll add a custom solution that works like the password prompt in the vault manager.

@nemo

The other place that generates this alert popup is when you click a secret that doesn’t exist (I edited this one to mock it up, but originally encountered it by deleting a secret after adding the wikitext code for it)

Ouch! How about a notification instead of a prompt?

---

About colons and special characters in secret names and usernames
I’m going to fix that asap. Bothers me too.
And yes, the username should be encrypted, you’re right!

Tonight I’ll make these updates, stay tuned!

Thanks again,
Simon

[TiddlyTitch]

@BurningTreeC let’s pretend someone steals you wiki.

Opening the vault needs a password.
Could it be set so that after X (say 5) tries it will refuse to open?

Just a slightly paranoid thought.

TT

[TiddlyTitch]

@Mark_S

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.

Right.

Credentials management is become a vastly over-complex issue.
Sheer volume is a big factor.
Last count I had about 125 login credentials to keep somewhere.

My ultimate solution should be to develop a Better Brain.
I don’t want a Robot Memory Partner that goes “beep”.

Meanwhile @BurningTreeC and @EricShulman have both had a stab at understanding and adressing the issues.

[Scott_Sauyet]

@TiddlyTitch

let’s pretend someone steals you wiki.

Opening the vault needs a password.
Could it be set so that after X (say 5) tries it will refuse to open?

What’s to stop them from making a million copy of your wiki, and getting five tries on each one? And if that doesn’t work, then making a billion more?

[Mark_S]

@TW_Tones

It is importiant for every one to note, that there is an internet wide collection of content containing encrypted content, it is thought by many criminals that if they cant decrypt it now, they may be able to in the near future.

I think the concern is more that public key encryption, based on mathematical algorithms, may someday be broken. But single-key encryption, assuming a good password, will continue to be safe for the foreseeable future.

The problem with frequent password changes is that my greatest danger isn’t hackers – its me – forgetting what the new password is.

[Mark_S]

There’s two scenarios here.

In the first, someone has a copy of your wiki. Then in theory they could make an infinite number of tries.

In the second, someone has access to your device. They do 5 tries and it’s locked. You come back and now can’t get into your own wiki.

So to be of any benefit, it would need to automatically unlock after some period of time. Or have a second password for unlocking the timeout.

[TW_Tones]

@Mark_S

I think the concern is more that public key encryption, based on mathematical algorithms

Theoreticaly without encryption keys of similar lengths to those used in “public key encryption” I would have thought they were more vulnerable to decryption. the private/public key encryption methods have the probelm that they are for systems available on the internet and thus an easier target.

• I suppose it depends on the encryption algorithum in use.

[BurningTreeC]

Hi @nemo

The issue with the password prompt should now be handled better.
Secret names are now base64 encoded so that special chars should not make problems anymore.
Usernames are now encrypted, too.

Hi @TiddlyTitch

If someone steals my wiki I need to rotate my passwords. But how do I know if it was stolen…
Currently after 5 attempts it locks the vault for 5 minutes but one can simply reload the wiki and try again…

@Mark_S

In the second, someone has access to your device. They do 5 tries and it’s locked. You come back and now can’t get into your own wiki.

Hi @Mark_S

The wiki itself doesn’t get locked, just the secrets vault for 5 minutes