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 <https://letsencrypt.org/> 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 <https://en.wikipedia.org/wiki/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 -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/8b304758-634a-450d-bd7d-0e4492ef9714%40googlegroups.com.
