Store login credentials in encrypted form

[taktoa]

I noticed that after running mal login, ~/.config/mal/myanimelist.ini contains my MyAnimeList login credentials in plaintext. I think there should at least be an option to store it as a GPG encrypted blob (so whenever I run mal it will ask the GPG agent to decrypt the blob, prompting me for a password to my GPG private key every so often). I may take a look at implementing this myself.

[ryukinix]

Yes, this is indeed a problem, I probably warn that in the README (or in https://lerax.me/mal). The problem overall is: there is no Oauth or other more secure way to communicate our credentials with the currently MAL API. It's pretty horrible.

Probably you can implement that, but sincerely I'm not very happy to depend to gpg, the GNU PGP client, to mal works. I use gpg a quite often, but I know that some people don't use it and some of them don't even understand how to deal with PGP keys. I don't want obey people get into all the mess because the MAL API fault.

However, yes, I care about my own credentials and as well the other users of mal. If would possible implement that as optional behavior... I don't know, probably mal/config.py stuff? This is stored at ~/.config/mal/myanimelist.ini. That way people that have a nice setup of GPG can use it and people that don't want to worry about gpg can just ignore it (btw, it's a quite surprise for me, but even don't be supported, there is some people trying to use this client on Windows... so think a little adding gpg dependency for windows users :v ).

I have some hope to MyAnimeList release a better API with oauth in some day... but probably I'm just dreaming a lot about it.

But, anyway, it's free software. If this really bother you, you can fork freely, implement it as default behavior and use your own version.

Thanks for your thoughts @taktoa, this is a important thing. Since you implement a nice optional feature don't being the default behavior, I probably can merge it on master (or at least in some other branch of the repository).

[kutsan]

Instead of living with GPG-only world, why not make an eval option for ini file that can be used while reading our passwords?

[login]
username = kutsan
passwordeval = gpg --no-tty --for-your-eyes-only --quiet --decrypt ~/.config/mal/secret.gpg

That way, we -even so-called Windows users- can define whatever command we want.

Besides, as default, other than storing as a plain text file, I'm even okay with ROT13. It just shouldn't be that easy to get. Also, mal definitely needs to chmod 600 to that file.

I have some hope to MyAnimeList release a better API with oauth in some day... but probably I'm just dreaming a lot about it.

They need to rebuild the whole website from scratch. There are a lot of things that wrong about it. API is just one of them. But, well, at least there is an API.

[evanjs]

This might also be an option: https://github.com/Netflix-Skunkworks/go-jira/blob/master/README.md#keyring-password-source

Not sure what we'd do about Windows, though.
Looks like credential locker is supported here: https://pypi.python.org/pypi/keyring

[ryukinix]

We can implement that as well:
tea-tiny-encryption-algorithm.pdf

Which will be done with no costs about relying on encrypt software, external dependency or hacky configurations for evaluating encrypt commands.

[kutsan]

@ryukinix I really want to have passwordeval functionality. Do you have any plans on that? Can I create another issue?

[ryukinix]

I don't have any plans to implement something as passwordeval or using gpg explicitly (though passwordeval is indeed better than that). I think that can be a minimal solution, but too dependent to config stuff... I don't like very much that. I would prefer something like TEA, which can work fine by default without the user knows about it because we'll implement all the mechanism of encrypt/decrypt (it's really simple).

Moreover, reducing always the number of dependencies and config we'll have more control of our software... we have until a bug with argparse (#79), this is quite awful.

But, if you really want this, and you want implement this, you are free to implement that by yourself. Since you show your point and we like it, we can merge it. Otherwise, I don't have plans on that, as I said.

I think this issue is already sufficient to discuss about that.

[kutsan]

My point was provide a simple algorithm as a default security model and apart from that let them have passwordeval config if they want more advanced security. Obviously, no one wants passwordeval as a default option.

[ryukinix]

My point was provide a simple algorithm as a default security model and apart from that let them have passwordeval config if they want more advanced security. Obviously, no one wants passwordeval as a default option.

Okay, since this your point and I get it right now, I'm ok with that. Probably, if I implement the tea, I'd add it as a especial tag like passwordeval=@tea to avoid conflicts on namespace if for some weird reason have a tea binary.

Are you ok with that, @kutsan? Probably everyone will be happy with that... 🤔 I guess.

[ryukinix]

I recommend read about tea that I attached here, it's nice and simple. A think as default can be great since we can embed directly without relying on conf/dep of environment of the users, with that we don't have problems with windows users as well, since this can implemented as portable really easily.

[ryukinix]

Do you have any plan to help implement that @kutsan ? Or anyone on this thread.

[ryukinix]

I can try look implement the TEA by myself, the passwordeval way a help can be useful. We need make that a little flexible to change, although seems a simple thing to do.