Plugin.video.netflix: Sometimes my credentials disappear and i have to re-enter them (RPI)

[dagwieers]

I am seeing this using the latest plugin.video.netflix release.

2020-03-13 17:39:30.534 T:1673438080   ERROR: [plugin.video.netflix (0)] Traceback (most recent call last):
                                              File "/storage/.kodi/addons/plugin.video.netflix/resources/lib/common/credentials.py", line 81, in get_credentials
                                                'email': decrypt_credential(email).decode('utf-8'),
                                              File "/storage/.kodi/addons/plugin.video.netflix/resources/lib/common/credentials.py", line 67, in decrypt_credential
                                                block_size=__BLOCK_SIZE__)
                                              File "/usr/lib/python2.7/site-packages/Crypto/Util/Padding.py", line 93, in unpad
                                            ValueError: PKCS#7 padding is incorrect.

And after this (or maybe before) my Netflix credentials are missing. I have seen this now plenty of times that my credentials are gone and I need to reenter them. Very annoying.

[CastagnaIT]

What device/so?

[dagwieers]

Raspberry Pi 3, LibreELEC 9.2.1.

[CastagnaIT]

This usually happens if the AES key changes
the only way is to verify

in your case the key is composed by reading the value from
cat /var/lib/dbus/machine-id

you should check every time you start the device if this value changes
if this value changes the credentials are requested again

could happen with an update of libreelec

[dagwieers]

That is quite likely, but also pretty annoying. Especially that I have to reenter my email and password.
Why does it get removed, it shouldn't be removed if this happens.

[CastagnaIT]

is not removed, the data remains saved, but cannot be decripted this is to prevent data theft

so i based the encryption on the device's hardware (what the UUID should be doing)(when possible) in this way if the database is sabotaged or copied on other devices it is not possible to decrypt the access data

but something changed in your device, and it changed the UUID
at least that should be what happened

or (I hope not, because that would be a disaster) the new linux kernels have changed the behavior of the UUID, and then you will need to find another safe way

[dagwieers]

I doubt the machine-id has changed, it is stored on the SD-card.

kodi01:~ # ls -la /var/lib/dbus/machine-id 
lrwxrwxrwx    1 root     root            15 Apr 11  2019 /var/lib/dbus/machine-id -> /etc/machine-id
kodi01:~ # ls -la /etc/machine-id 
lrwxrwxrwx    1 root     root            34 Mar  3 21:33 /etc/machine-id -> /storage/.cache/systemd-machine-id
kodi01:~ # ls -la /storage/.cache/systemd-machine-id 
-r--r--r--    1 root     root            33 Apr 11  2019 /storage/.cache/systemd-machine-id

Something else is going on, and it happens more often than a system update.

[CastagnaIT]

i call the kernel path, not the sd path
being generated by the kernel you don't know if it changes
the only way is check every time

I add a new branch uuid_problem: https://github.com/CastagnaIT/plugin.video.netflix/tree/uuid_problem
with this you can check in kodi log if the UUID changes:
in the log look at a line with this output LINUX UUID: xyz
the output is written even without debug enabled

save the log of first output with which you save the nf credentials,
when the problem happens again, compare the new log output, to see if uuid is really changed

[dagwieers]

There was no kernel change from LE v9.2.0 and LE v9.2.1, and the machine-id is stored on the SD card. So I think the problem is elsewhere.

[CastagnaIT]

I have nothing more to tell you, and nothing else to check, if there will be other similar cases i will ask for a comparison

[dagwieers]

i call the kernel path, not the sd path

Not sure what you are trying to say. I just proved to you all three files point to the same content on the SD card.

And that file was modified last on 2019-04-11 (when this system was installed).

[CastagnaIT]

ok, i have rechecked the encryption and decryption code, and is good
this code has been working for several years

so as far as i know the possible cases may be:

• The machine-id could be changed
• The uuid5 generator sometime fail on libreelec linux (sounds weird):
  therefore it is necessary to check the output value on this line so check what value when works, and what value when fails:
  https://github.com/CastagnaIT/plugin.video.netflix/blob/master/resources/lib/common/uuid_device.py#L64
• The value on the database has been corrupted

[arvvoid]

Hello, I use the same machine-id retrieval code on hbo go add-on, slightly different key generation code, and same encryption code for the credentials, and it happens sometimes as well and i agree is annoying, haven't been able to pinpoint the cause I assumed the machine-id sometimes change usually after updates.
But came to the conclusion that maybe the credential encryption can simply be dropped as it is, and thinking about doing that in the hbo go add-on , and replaced by simple obfuscation or simply plaintext since encryption with an easily available and readable key stored on the machine basically provide 0 security.
The same level of protection from random credential scraping script/malware will probably be achieved with simple obfuscation. From targeted attacks both provide 0 protection.

The perfect way of solving this would be if Kodi would provide something like a keychain internally. And ask the user for a pin on startup to unlock the keychain (from the pin that is not stored anywhere a decryption key is calculated) and provide a mechanism for add-ons to store/read sensitive data in that keychain. On systems with a keychain in the OS, Kodi could use the system keychain maybe.
Or we could maybe develop an add-on service that does exactly that, would be more reliable and secure than the current system, but doing it as an add-on since we don't know when it will start exactly can cause all sorts of timeout errors if widgets are used ecc... so not ideal.
Ideally would be a good thing to develop both the service and a module script for client add-ons to use simply that take care of the intricacies waiting for the service to start up and-all.

Those are just ideas I bringing up to hear your opinions.

[dagwieers]

The perfect way of solving this would be if Kodi would provide something like a keychain internally.

@arvvoid I agree with you. And I think @basrieter would benefit from this as well for Retrospect.

[CastagnaIT]

can be simply be dropped as it is, and thinking about doing that in the hbo go add-on , and replaced by simple obfuscation or simply plaintext

I agree that it won't be a very safe method, but certainly safer than simply obfuscating it or very worse in plaintext.

There are two main advantages of my method:

• Provide a minimum of encryption complication this cuts out most inexperienced and intermediate users, prevents users from copying credentials by simply opening the database.

• The encryption key is based (when possible) on the system UUID, having this relationship anyone trying to make a copy of the addon user folder, and uses it on another Kodi installation on other devices, the addon will NOT work.

You can't escape the worst, _but selective attacks are not the order of the day_...

The perfect way of solving this would be if Kodi would provide something like a keychain internally

it would be helpful if Kodi provide a wallet to save/retreive credentials
but how to retrieve them safely? there's no way to determine if the addon is safe and approved to obtain saved credentials (currently anyone can make an addon with the same name but for different purposes).

an other example perhaps can be provide to kodi of an MD5 generated on the fly at the first start of the addon, based on all files of the addon (which must be updated each time the addon is updated),
in this way perhaps you could determine if it is the right addon that ask the credentials

---

in the last year is the first time I've heard about this credentials problem
it's strange that dagwieers only complains
there are hundreds of netflix users...

for netflix for now is limited to an RPI
but I'm not going to eliminate this security system just for one user

I've written down the necessary points to try and study what's wrong

[dagwieers]

but I'm not going to eliminate this security system just for one user

Where did I ask to have this removed?

I just reported an issue I have seen on more than one device from time to time. At first I thought this was related to version updates, but now I am not so sure. It definitely is not the system-id changing.

This is a standard RPi 3B with LibreELEC v9.2.1 (but I have seen this with v9.0 as well before).

[dagwieers]

BTW And I am not complaining, I am reporting an issue.

[CastagnaIT]

arvvoid

But came to the conclusion that maybe the credential encryption can simply be dropped as it is

was not meant for you

[dagwieers]

I use the same machine-id retrieval code on hho go add-on, slightly different key generation code, and same encryption code for the credentials

He was talking about dropping his own implementation AFAICT.

[CastagnaIT]

It definitely is not the system-id changing

ok we theorize that the system-id is not modified between LE updates,
then this means that this value is not always read correctly by the addon
because the error mentioned happens only when the key is not right

so we need to check what happens when it asks you for your password again

I have updated the 'uuid_problem' branch again:
https://github.com/CastagnaIT/plugin.video.netflix/commits/uuid_problem

you can use it to install it on LE
As I told you before you can keep track of Kodi's log even without having the debug enabled
so you can use your device without the annoying on-screen debugging

then get a first log and save it,
the next time that happen it ask the password, extract the new log, and compare the value of the two log

[arvvoid]

Hello, @CastagnaIT my intention wasn't to criticize, I'm sorry if it sounded that way. You did a great job and did the best that can be done with what is available in the current environment. Big thanks for the work on this add-on.
I use your system basically in my add-on (Hbo Go), and added it because I was thinking better some form of security than nothing.
With my post, I simply wanted to express some thoughts to start an exchange and discussion on the matter and to see if we can maybe together think of a better system for the future. And what are the thoughts of other add-on developers on the subject.
But probably it would be better to continue that discussion on another appropriate channel.
I never suggested you remove anything, I was thinking of removing from my add-on or provide an option to disable in my add-on, but I will explain my line of thought on a separate channel.

I can confirm that the described issue definitively happens sometimes and I will try to catch a log as well if it re-ask for credentials and post as well, but you are most likely correct it can be only 2 things, or device id change (strange, and it looks like it’s not the case) or device-id becomes temporarily unreadable or starting the external process to get it fails somehow (strange again). So far it only happened to me on Rpi LibreElec and also on OSMC on Rpi. On other devices I sometimes use macOS, Windows never happened so far.
I also have no other ideas atm.
In my add-on I store the encrypted credentials in settings.xml and don’t use UUID5 (i generate a sha256 hash from the retrieved machine-id with some addition and transformation and use that as the encryption key) but is affected by the same issue at the same time as this add-on, when it happens it ask credentials again in both add-ons (it doesn’t happen often, so not easy to catch), so I would tend to exclude database corruption or uuid5 as the source of the problem.

[CastagnaIT]

Issue marked as "Tester needed"

if someone else have this problem and guarantees availability for continuous Addon testing with debug logs, i will be able to better analyze the problem

[jakermx]

AFAIK it is caused by auto update

[jakermx]

it does happen too when using a slow SD card.... I think that threading is not waiting for end procedure as needed....but, it is most about auto update

[CastagnaIT]

@jakermx are you able to reproduce the problem?
I could give you a modified version to get more debug information

I think that threading is not waiting for end procedure as needed

it is not a thread, and the python check_output command always wait the end of running process before return a results

it is more likely that the correct value is not read, or, an error is raised but which is currently ignored
by code, or, as you say is caused by the update
but they say it can happen also without updating..

it is necessary to analyse in more detail with a modified version

[goforthanddie]

Hi,

I had a similar issue when using a docker container. Turns out, /etc/machine-id is always empty and /var/lib/dbus/machine-id was not existing, so he created the fake id using memory and hostname. However, every time you restart the docker container, it gets a new hostname so that the credentials are not decryptable. What I did was to map the local /etc/machine-id into the docker container to solve this by adding -volume /etc/machine-id:/etc/machine-id to the docker container parameters. Maybe this is interesting for others, too. However, since you changed the title of the issue, this might not fit so nicely anymore.

Best and thanks for the work!

Samy

[CastagnaIT]

i found one of the cause of creadentials problem from a commit of 23 Feb
that caused to version 1.0.0 to ask first time the credentials on rpi (released 6 March)

fixed yesterday, so the machine-id was never read
I added a log writing in case of error
so if reading problems occur in the near future you should catch them in log

[dagwieers]

What commit was this? I find 2 commits on 2020-02-23 that are unrelated.

[CastagnaIT]

https://github.com/CastagnaIT/plugin.video.netflix/commit/da137e44b2f8ec97b6fce010f394784bb64563bc#diff-8c28a19fa3c29556f74d12660088d671

[dagwieers]

Hah, I didn't identify that one as being related :-) Thanks!

[CastagnaIT]

on next release will be ask to re enter again the credetials, due to fixed the code

[CastagnaIT]

i close the issue, if needed can be reopened