I am not exactly sure where I should post the following issue, and I am not sure it is even a bug. The behavior; however, is different from every other Linux variant I have tried, and what I would expect for a secure response, so I am bringing it to the community’s attention.
I basically enable full-disk encryption for OpenSUSE when I installed the system (LEAP 42.2 x64). Having said this, when I start up the system, I am given the screen where I must enter my encryption password to continue. What I observed is that if one enters the incorrect password 3 times, the system brings me to the login menu where I am to select my username and enter my user password (if I have one). Trying to do that at this point, the system will not allow me to logon, despite entering the correct information. Once I restart the system, I am brought back to the screen where I have to enter the encryption password again. If I do so correctly, I am taken to the same login menu, only this time it works. If I entered the encryption password incorrectly 3 times again, the cycle repeats itself.
My concern stems from simply the fact that entering the encryption password incorrectly any number of times, one would think that the system should never allow the screen to advance to the login menu. I don’t know if this is done on purpose to prevent a program from trying to brute force its way into the machine by essentially not allowing the encryption password to be continuously entered repeatedly. This could be an issue as well, which is why I am bringing it to your attention.
This is repeatable. I have tried it on a modern Dell system only a couple of months old, an 8 year old Lenovo, a friend’s old HP laptop does the same thing. Is this an issue? Thanks for your time.
There is no such thing as full disk encryption during installation. Please tell in more details exact steps you have taken.
I am given the screen where I must enter my encryption password to continue. What I observed is that if one enters the incorrect password 3 times, the system brings me to the login menu where I am to select my username and enter my user password (if I have one).
I am aware there is no “full disk encryption”, which is why I mentioned “essentially”. I apologize and will be more specific in the future. The home folder is encrypted. My specific disk setup has four partitions, one for the boot, one for the swap, one for the root directory, and one for home. The home folder, and only the home folder, is encrypted. I have used this and other setups on different computers, all running into the same issue. I’ll get you the screenshots later tonight.
I use an encrypted LVM, which comes closer to full disk encryption.
I am not seeing anything like the problem you describe. If something fails, when providing the encryption key, my only alternative seems to be to power off and then try again. As for encryption key, as far as I know it repeatedly asks. But I don’t think I have recently gone beyond three tries before getting it right, so I can’t be sure of that.
I can be sure that I would never get a login prompt, if I fail on the encryption key. The software that gives the login prompt is not accesible until the disk is unencrypted.
What you have described, is actually normal procedure for login failures. After three failures, to back to the login prompt. So I don’t think you have found a security problem. When you encrypt your home directory, this is really just like login, but with the extra step of decrypting during the login. I’m guessing that you are setup for auto-login, so what you see looks like an encryption prompt rather than a login prompt.
I tried to reproduce it, but I do not see the same effect. When I enable auto-login for a user with encrypted home directory, I just get what looks like “normal” login screen (I’m using lightdm). If I enter incorrect password I remain at this screen. I never get any other possibility. Also, encrypted home directory does not (at least, by default) use separate passphrase - IIRC it generates random passphrase and encrypts it using user password.
So screenshots of both screen would still be good idea I suppose other display manager may behave differently here.
While I do not have anything encrypted, I think I can understand what happens.
boot.
the login screen (display manager) is skipped because you seem to have automatic login (you never told so, but we are used to people telling not much about what they have and do :().
the login to that automatic user tries to use the home directory of the user which is in the encrypted /home and thus asks for the encryption password.
after three trials the usage of /home is blocked and the login killed.
the vanishing of the login process is detected (by systemd) and a new login process (display manager) is started.
username and password are entered (correct), but /home is still blocked and the login is killed.
In theory, you could login with a user name that hasn’t his home directory in /home (like root, but please do not login in the GUI as root).
I do not see any security issue specially created by the above. The file system you use for /home is encrypted. the usage of it is blocked after three wrong attempts and stays so for the lifetime of the system running. Isn’t that according to the specifications/documentation?
It is only after a reboot that you get a new chance.
By the encryption software I assume. In any case that is what the OP reports: three times the wrong password and no more attempts offered. I guess until shutdown.
In his first post the OP describes what he sees (and I take that description as rather correct). But he does not seem to understand completely why that is what he sees ((and he is afraid there is a security issue there).
What I try is to explain why he sees what he sees in that sequence. Taking into account that he seems to have an automatic login in the GUI after boot (which is a security issue in itself IMHO) and assuming that the encryption software gives you three chances to get access to the encrypted file system (as I do not use it, that is a guess, but it seems not illogical and explains what he sees).
Probably the least considered but possibly should be considered is TPM (Trusted Platform Module).
MSWindows was first to implement support, but is now also possible in Linux.
TPM utilizes certs and codes stored in silicon hardware (so of course you need hardware support), so your BIOS/UEFI becomes the gatekeeper to machine access. Although there were possibly (more in theory than practice) defects in early TPM, AFAIK the level of security is high and not broken. Note that besides encrypting drives, an unauthorized User is prevented from <any> kind of system access.
There is also a version of TPM security for hard drives as well when the TPM chip is stored in the hard drive instead of on the motherboard.
Sorry for the lack of detail. I do not enable automatic login. Normally, I would have to enter the encryption password correctly. Upon doing so, I would be taken to the login screen to enter my username and login password to begin the session.
One of these times, I was obviously not paying attention too much and entering the encryption password for another system. After the third try (remember I am entering the wrong password for the target system), the system seemed to act the way it normally does when I enter the encryption password correctly - it brought me to the normal login screen. From here, no matter how many times I entered the password correctly here, it did not let me login.
The explanation given by Henk van Velden actually clears this issue up. It is extremely obvious now, and one can indeed login to another account other than \home. I always expected a failed password never to let you beyond the main encryption screen. I am now confident there is no security issue.
In other flavours (Fedora, Mageia, etc.), usually LVM encryption is an option one simply checks during installation. nrickert, I will have to pay closer attention to the options at boot-up, I did not pay attention to the fact that LVM partitioning was an option. Where is it exactly in the installation options?
To everyone, thanks for your help and feedback. I appreciate it immensely. I apologize that it turned out to be a non-issue. A few friends and I took a look at this and thought it odd, and **Henk’s **explanation did not come to mind, so I figured that the safest course of action would be to bring it to the attention of the community so that if it was indeed an issue that was unrecognized, the proper steps could be taken to fix it. In the end, I ended up learning something. Thanks again.
In a completely unrelated note, since you seem to have a little knowledge of the BIOS, have you ever heard about a Dell BIOS locking the user out of the BIOS itself? It only seems to be with Dell computers. I do use BIOS protections when I can, but this particular issue has crippled one of my machines. I can still boot the machine and access the OS, but I cannot enter the BIOS (F2 key at startup) and cannot modify the startup (F12 key at startup) to install a new OS! It currently runs OpenSUSE Leap 42.2, but there are software issues with that installation that a clean reinstall would quickly fix. I have never seen this before, and the IT guys in our department all say they have seen it with Dell systems only! I already tried resetting the BIOS via taking the battery and the backup battery out of the system to kill power to the machine completely, yet the problem still exists! Any ideas? System is only 1 year old!
New BIOS AKA UEFI uses flash to store settings this of course does not respond to the old remove the battery fix. Need to contact Dell for any possible fix. Note also most times you really don’t have to use the Windows fix of reinstalling. Maybe a properly done zypper dup will resolve matters. If interested explain the problem and show zypper lr -d We can probably help fix without a full reinstall
On Thu, 25 May 2017 17:06:02 +0000, morrison27 wrote:
> have seen it with Dell systems only! I already tried resetting the BIOS
> via taking the battery and the backup battery out of the system to kill
> power to the machine completely, yet the problem still exists! Any
> ideas? System is only 1 year old!
An OS configured to install using UEFI instead of legacy BIOS disables any way of booting directly to a BIOS configuration screen.
More than likely, you have to boot into the OS, and from there enable a restart to the BIOS configuration.
But, when you’re talking about Servers from Dell, HP, IBM etc.
You should also verify whether the OS was installed using a proprietary installation disk from the manufacturer which may specially configure the installation.
I suppose other display manager may behave differently here.