search

TiddlyWiki / TiddlyWiki5

A self-contained JavaScript wiki for the browser, Node.js, AWS Lambda etc.
https://tiddlywiki.com/
Other
7.98k stars 1.18k forks source link

GitLab and GitHub saver store token as plain-text. It should be encrypted #4525

Open pmario opened 4 years ago

pmario commented 4 years ago

At the moment the oauth tokens are stored in plain text. So everyone, with access to the browser, can see it.

IMO, the tokens should be stored encrypted.

If the PW gets lost, that's not a big deal, since users can create new oath tokens, if the "old" one can't be decrypted.

Jermolene commented 4 years ago

If the oath token is to be encrypted then presumably we'd have to prompt the user for a passphrase so we could decrypt it. But once decrypted wouldn't we be in the same situation? Anyone with access to the browser could extract the decrypted passphrase.

pmario commented 4 years ago

At the moment it's too easy for everyone, to get the info: F12, Storage tab, Local Storage and you can see the key. Get mobile - klick - done - 10 seconds and you are good to go.

If the key is encrypted, the above workflow would be useless. And it's definitely harder to trick the password-widget.

I personally would like to use the browser internal store, which can be synced https://developer.mozilla.org/en-US/docs/Web/API/PasswordCredential with several devices.

But I'm not sure, how to use this stuff. There is an AddON for FF - FireFox Lockwise, ... So the API functions are there, otherwise they wouldn't be able to use it.

So if we would prepare the "form" in the right way, we could use the browser "auto-fill" functions, which imo would make it safer and convenient.

pmario commented 4 years ago

I'm sure similar things are available for Chrome-based browsers and Safari.

Jermolene commented 4 years ago

That Password Management API doesn't seem to be mature enough to put in the core.

If I'm understanding correctly that the plan would be to use a passphrase as the key for the encryption/decryption, then entering the passphrase each time doesn't seem that much less onerous than entering the oauth key each time, especially if the user chooses a robust passphrase.

Perhaps a simpler way to avoid the vulnerability would be to add an option to avoid storing the oauth key in local storage?

pmario commented 4 years ago

... If the 7-day auto-remove function will be activated, I think, we need to think about a different option.

pmario commented 4 years ago

Perhaps a simpler way to avoid the vulnerability would be to add an option to avoid storing the oauth key in local storage?

Yea, ... See my last post.

pmario commented 4 years ago

I personally wouldn't have a problem if the git-save workflow is like this:

Jermolene commented 4 years ago

Hi @pmario

I personally wouldn't have a problem if the git-save workflow is like this:

Brilliant, yes.

silvyn commented 4 years ago

Hi, A french user forum has just create a api today and he receive this mail from GitHub :

"Basic authentication using a password to the API is deprecated and will soon no longer work. Visit https://developer.github.com/changes/2020-02-14-deprecating-password-auth/ for more information around suggested workarounds and removal dates."

I think it's related to this issue, or it's steel OK with access tokens.

Jermolene commented 4 years ago

Hi @silvyn that article refers to dropping support passwords in favour of access tokens. I think it will be a documentation issue for us: the saver implementation works with passwords or access tokens.