-
Notifications
You must be signed in to change notification settings - Fork 650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python3 (Dev): User Authentication not working #2813
Comments
I can confirm this behavior for basic authentication with my latest installation: motionEye version : 0.43.0 Access with camera app shows error message "Invalid username/password" with identical credentials ensured. Access to stream in browser with these credentials does not open the stream, but restarts login process with re-openened login window. Access to stream with no authentication works. |
This should be relabeled as a bug. I found a way around it but it is inconvenient. When you save a Surveillance Username and Password, it is written into /etc/motioneye/camera-*.conf > stream_authentication user:password. |
Thanks @cinnamonsweets for the hint. |
This broke in 14156d2 I guess, because nobody thought of the streaming port authentication, which is done by Motion, and which can't understand hashed password 😞 The security-wise "best" option Motion supports would be MD5 digest auth which doesn't really work for interactive use via browser and is not that great anyway (see docs). |
It seems there's nothing really to be done here except reverting the commit I mentioned (and thus have normal user password unprotected in both |
Many thanks for identifying the issue. This bugged me as well already, but I never found the time to debug. Why can MD5 digest not work interactively? motionEye can do the conversion of inputs for its own authentication and motion should do anyway? And does the same apply for the admin user? There is would be of course more critical do leave it in plain text. What we could generally do is assuring 600 or 640 mode, so that the files are not world-readable. |
MD5 digest auth cannot work for streaming URL, since that is just between browser and Motion, unless I'm mistaken, and there basic auth is the only option for the user. All the rest (which go through ME) work even now just fine (UI, snapshot URL, embed URL although I didn't specifically test this). Admin isn't really relevant for streaming URL so that's not an issue. The point on config file modes is good and probably worth pursuing. |
TL;DR: Let's just revert the commit for now like your PR does, to restore functionality. We can think about enhancing security when we find time. Since this MD5 digest is supported by motion directly, I guess also the login prompt and conversion of input into MD5 digest is handled by motion directly? Of course, in case that is true, and we can store passwords like that (in the motionEye config), also motionEye would need to process this correctly for its own authentication. Is authentication at the streaming URL not possible as admin user? I mean even if it was, i.e. motionEye sets up both users+credentails in motion/camera configs for that, it is not advised to do that, sharing motionEye admin credentials with every motion instance. But if that was currently possible regardless, we might either need to assure that both works, or simply disable the possibility to authenticate at motion with the motionEye admin user. A surveillance user would then be required in any case for motionEye to authenticate at motion (if I am not mistaken) to process and show streams through motionEye interface. ... thinking further about it, also motionEye needs to pass the credentials in plain text to motion to access the streams, as you cannot authenticate with a hash (MD5), is it? Probably it was hence always meant like that: Have the motionEye admin password hashed, as motionEye processes authentication, but have the surveillance password in plain text stored at least in motionEye config, so motionEye can authenticate with (only) this user against motion for access the streams. It could still be stored in MD5 digest in the motion camera configs, but must be accessible in plain text by motionEye. In this case it does not make much sense to hash it for motion, when it is readable just in anther config file. I then wonder whether the surveillance user even works, currently, when you assign a password. I remember I had trouble even logging in with it at the motionEye UI, but did not find the time to investigate. Probably this was caused by the same faulty commit. |
Oh, I misthought what the MD5 digest auth was about (haven't been using that ever). Sure it works just as fine interactively with a browser, and it keeps the password out of plain sight in web traffic, but what it doesn't change is that the password needs to be in clear-text in the config file, which was not working here. The digest auth worked just fine now that I actually tested it, but really it doesn't change the core issue here as it only changes the transport format of the credentials, not the storage.
Currently ME only ever puts
For me login as surveillance user works just fine, but I think there's a possibility of a goof-up when changing the password: What the password field contains after saving is literally just "****", so it you try to edit your password without wiping the field empty first, you do not get the password you thought you would. |
So my assumption then seems to be right: motion correctly handles authentication when credentials are stored as MD5 digest im its configs, but of course authentication needs to be done with plain text password. All fine when users enter it manually, but also motionEye requires it in plain text somewhere, as it needs to authenticate at motion as well. And since hence there is no way around a plain text password in a config file (unless we implement some encryption and obfuscation of the decryption key and method, not really effectively possible in open source software and non-binary Python scripts), there is no point to hash it in motion configs either. Good and reasonable then, that only the surveillance user is used for this, so it is not that critical. But of course the camera streams are still a privacy concern and hence those config files should only be readable by the motion user. Funny that the |
I think this is worth pushing another beta, but I actually would like to test and merge #2903 first. I just didn't find the time yet, and also the next days I am very busy. |
Heya!
Just installed the dev version (python3) on my Raspberry Pi 3 B+ and tried to configure it the same as my old python2 MotionEyeOS install, however I noticed that the user authentication doesn't work.
Whenever I enable "Basic" or "Digest" authentication and try to enter my credentials (either in Browser, VLC or Blue Iris) it always asks me again or throws an "Unauthenticated" error. I tried changing passwords multiple times but nothing seemed to work. One thing I haven't tried yet is renaming the user.
Is this a known issue? How can I debug this to provide more info here? Thanks!
The text was updated successfully, but these errors were encountered: