Encryption & data accessibility question

[Hubert]

Hello,

I use a single file TiddlyWiki with encryption.

I know that any unencrypted single-file TiddlyWiki, when opened in a notepad or browser (view source), will reveal all tiddlers as plaintext.

By contrast, when I open the encrypted TiddlyWiki file in a browser or a notepad and view source (browser) or examine the raw code (notepad), then anything after <!--~~ Ordinary tiddlers ~~--> remains unreadable as far as plaintext is concerned, even after user password was provided. That's reassuring.

However, since the html source appears to remain unchanged once encryption password has been provided and tiddlers were decrypted, I can only assume that all now-decrypted tiddler content has been loaded as plaintext into RAM or some kind of browser storage, is this correct?

My second question then is, how vulnerable would this content be to any form of hijacking/extracting as plaintext once TiddlyWiki decryption password has been provided?

Thanks!
Hubert

[Dragon Cotterill]

However, since the html source appears to remain unchanged once encryption password has been provided and tiddlers were decrypted, I can only assume that all now-decrypted tiddler content has been loaded as plaintext into RAM or some kind of browser storage, is this correct?

The encrypted contents are "unlocked" when the password is supplied. As I understand it, this is done when the contents are displayed in the River, when on the screen. The original tiddler is still encrypted. So if you save the TW then the contents are saved in an encrypted format. (NB. I've not actually checked the various encryption plugins other than a cursory glance.)

 

My second question then is, how vulnerable would this content be to any form of hijacking/extracting as plaintext once TiddlyWiki decryption password has been provided?

Once the password has supplied then the whole thing is wide open anyway. Sneaky javascript added to any plugin can grab said contents and offload it to wherever necessary.

If you are looking for a fully encrypted and locked system, then I'm afraid TW is not it. You'd need proper signing of all the included contents to really make it secure, and even then you still couldn't guarantee it. At best I consider TW encryption as a way of preventing casual viewing of the entries. It is possible to create a "brute force" plugin which can sit and attack any given tiddler once loaded up in the browser. It might take a while, but if you feed it something like "rockyou" then you pretty much hit the majority of passwords.

[TonyM]

The decryption only takes place in your browser unless you save it unencrypted.

But of course Since tiddlywiki is "just a html" file you can use any other means to control access to that file you can use on any other platform. 

Of course security is a many tentacled thing, but with server security + encryption I believe they must compromise your browser to achieve anything. 

The first things to consider are;

• What are you hosting it on?
• Who and how people access it?
• Can you use https?

If its only you, you can make it as secure as almost anything on the net.

As soon as someone or every one has unfettered access they can see what they can see. Thus it may be worth using one wiki to generate another public wiki.

Regards

Tony

[PMario]

On Monday, September 2, 2019 at 4:13:29 PM UTC+2, Hubert wrote:

...

However, since the html source appears to remain unchanged once encryption password has been provided and tiddlers were decrypted, I can only assume that all now-decrypted tiddler content has been loaded as plaintext into RAM or some kind of browser storage, is this correct?

It is RAM. It is a structure that is called $tw.wiki .. we also call it "the store" or "wiki store". ... This store can be accessed with eg: $tw.wiki.getTiddler("HelloThere")

The returned object is "plain text".

There is no persistent browser storage involved. ... So if the TW tab is closed and reopened, there are no plain text artefacts on the hard drive.

 

My second question then is, how vulnerable would this content be to any form of hijacking/extracting as plaintext once TiddlyWiki decryption password has been provided?

As I wrote above. If the user has access to your browser, with decrypted content, it would be as easy as typing F12 which opens the developer terminal. Enter the string $tw.wiki.getTiddler("HelloThere") and you'll get some output.

That's exactly the same problem, you'd have with any other software, that displays unencrypted content, if you have access to the terminal.

It would be possible to create a TW plugin, that detects, if the TW tab is visible. If it is hidden, it could remove "the store" from the TW internal memory. ... Which doesn't mean, that the browser will forget it immediately. But it would make it much harder.

The core encryption/decryption function is a "all or nothing" approach, because it is convenient. There is a plugin, that lets you encrypt / decrypt single tiddlers.

As you can see, we can do a lot with plugins. So it really depends on your requirements. ...

Just to be sure: There are some researchers out there, that state that: "encryption in the browser will never be secure".

have fun!

mario

[Hubert]

Thank you all for the replies. So, essentially any TW content is up for grabs as long as the TW is loaded in the browser, whether encrypted or not. I reckon that the stationary TW file residing on HDD somewhere is relatively safe, if encrypted (password protected).

Again, thank you for the valuable information & technical insights.

Regards,

Hubert

[TonyM]

Hubert,

But to be clear this is the truth of any content you give to someone on the internet. Its just tiddlywiki loads its whole self into the browser (thus giving us all its interactive features). Individual encrypted tiddlers are possible but they could take the tiddler and brute force it. You can guarantee they can't save changes back to the server, you can stop access to the wiki in the first place, with server based security and you can protect yourself when passing users id, password and save keys with https.

Noteself adds a layer where you also need the database credentials.

Regards

Tony 

[PMario]

On Tuesday, September 3, 2019 at 7:53:32 PM UTC+2, Hubert wrote:

So, essentially any TW content is up for grabs as long as the TW is loaded in the browser, whether encrypted or not.

"whether encrypted or not." <- That's wrong. ...

The content is _only_ up for grabs in the browser, if you did provide the password.

If you provide the password the whole content is decrypted and "stored in the internal store" which only exists in browser ram. ... There it's easy to grab, because that's what we wanted. ... As I wrote, it would be possible to add additional conditions to "forget" the store. ...

So if you want to access the content again you have to provide the PW first.

 

I reckon that the stationary TW file residing on HDD somewhere is relatively safe, if encrypted (password protected).

That's right. A file based TW is "secure on rest" and "secure on transport", even if you use an unsafe protocol like HTTP. That's an advantage over systems that need HTTPS to be secure on transport.

HTTPS was hard but since Let's Encrypt it's easy. .. So if you deal with encrypted content you should add HTTPS too! Which with an encrypted TW means, that you add an additional layer of encryption.

BUT nothing of this helps if the PW is guessable, like 123456 or similar nonsense.

So today it's much cheaper to attack the password or the owner of the PW, than the encryption mechanism or the device that contains the info. ... That's why "multi factor authentication" is a huge topic.

As I wrote, it depends on your usecase, and may be "external standards" the apply to your usecase.

have fun!

mario

[Hubert]

The content is _only_ up for grabs in the browser, if you did provide the password. 

Yes, that was one important bit :) That's what I was trying to say.

As I'm working in a single file TiddlyWiki this is basically all I wanted to know.

Thanks again to everyone, this community is amazing.

Best regards,

Hubert