No, the problem is NOT that when auto-login is enabled you don't have to type your password with screen lock. Even with auto-login enabled, you DO still have to enter your password when the screen is locked. The problem is that on the screen unlock dialog, instead of entering your password, you can click the "Switch user" button, which takes you to the login screen, where you can select the very user who had locked the screen. This workflow leads to a false sense of security -- a naive user who enables auto-login and also enables screen locking will be fooled into thinking the screen is really locked when it is not. That is a security vulnerability.
To make matters worse, disabling auto-login does not remove the user from the nopasswdlogin group, so even if the user turns off auto-login, the screen lock vulnerability remains. This is a clear security vulnerability even for non-advanced users who don't encrypt their system. If such a user enables auto-login upon system installation and then disables auto-login at some later time, their user account will still be in the nopasswdlogin group and their screen lock can be circumvented, but they would never know it. As for more advanced users who encrypt their system, it is incorrect to assume that this problem will necessarily be discovered or easily fixed by them. I was using the system for a couple of weeks before noticing the problem, and I only noticed it by chance because I decided to play around with the "Switch user" functionality (which I don't really have any need for, as there is only one account on the machine). I could easily have gone months or longer without ever discovering the vulnerability. And once I discovered the problem, it took me hours of research to figure out the workaround. It is not part of any official documentation -- I just happened upon a solution posted somewhere by a user. So, this represents a security vulnerability for advanced users as well, as they would have no reason to expect enabling auto-login would create a screen lock vulnerability (given that the locked screen does still request a password). Former Windows users, in particular, will likely be unaware of the problem, as Windows behaves correctly in this situation (when you lock the screen, you cannot circumevent the lock, even with auto-login enabled). I think the solution is to separate the auto-login functionality and the nopasswdlogin functionality. Actually, it appears these functions are already separate, but there's no way to turn them on and off independently using the UI, nor is there any (obvious and easy to find) official documentation regarding how to do it manually. When I installed the system, I enabled auto-login, which apparently also added my user to the nopasswdlogin group. However, when I suspected auto-login as the culprit in the screen locking vulnerability, I disabled auto-login, but that had no effect on the screen lock problem. Once you enable auto- login, you're stuck with the problem, unless you happen upon the workaround, which is not at all obvious or easy to find. The following two changes would resolve the problem for both encrypted and non-encrypted systems: 1. Have separate UI settings for auto-login and nopasswdlogin. These are already two separate settings, just make them independently configurable in the UI. This will allow users with encrypted systems to enable auto-login but still lock the screen (without being fooled into thinking the screen is locked when it isn't). 2. When nopasswdlogin is enabled, disable the lock screen functionality, as it tricks users into thinking their screen is locked when it is not. Thank you. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/987330 Title: Insecure login -- not requesting password To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/987330/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
