21

I think there should be a maximum number of password tries allowed to unlock the screen and login. As of now you can keep trying and nothing prevents you from trying a million different passwords. I think after five failed attempts you should be prevented from trying again for five minutes or a user specified amount of time.

I use full disk encryption to start my system and have a very long and secure password to decrypt the drive (30+ Characters). However, I use a shorter password for my user account. If I am already logged in and lock my screen while I walk away, someone could take my computer and use some kind of brute force attack on my user account and have access to all my files. If they were locked out every five minutes it wouldn't be possible to crack the password in a reasonable amount of time. If after 20 failed attempts the computer restarted, then my more secure 30+ character password would be required and my system would be safe.

SEE COMMENTS SECTION FOR MORE DETAILS...

This seems one of those illusion-of-security things.
If someone wants to 'borrow' your computer to get at stuff on your encrypted partition then they could just ctrl+alt+F1 to get to a terminal and brute-force your password there; bypassing completely the maximum password tries in KDM and your locked session.

Then maybe locking your screen should also disable ctrl+alt+F1 and other shortcuts to new sessions.

What's the point of having a password at all if there are so many ways to get passed it?

I don't really know all the security ins and outs, but if I lock my my screen, it should lock my computer, or that should be an option anyway.

Your security is only as strong as the weakest link, and I see this as a weak link.

Encrypting your hard-drive and having a super secure password for that is worthless once your computer is running.

Having an equally secure password for the user account isn't realistic as I am not going to enter 30+ characters every time my password is needed.

It's an illusion-of-security as it is now.

Lock screen should be changed to lock computer and it should do just that. My computer should not switch sessions or do anything other than show a black screen until I enter my password within a reasonable amount of tries.

People won't have access to your files without the root password if your permissions and groups are set correctly. So I don't really see the problem here. If your root password is weak then you are pretty much screwed anyway. It shouldn't be possible to brute-force a good password in a feasible amount of time.

If someone logs into your user account they don't need a root password to view your files.

My root password is very secure, and would take years to brute-force.

User accounts are usually shorter and easier to remember though. Some people, my parents for example, aren't able to remember long complicated passwords unless they write them down, which is nearly as bad as having a short generic password.

If you make it too hard to use a password people stop using a password.

I need to walk away from my computer at work, coffee shops, friends houses, etc. And while the easy answer is to not leave your computer unattended, that just isn't realistic for many people. I'm not taking my computer with me into the bathroom or while I go out to lunch.

If I need to walk away for a few minutes I should be able to quickly secure my system and quickly unsecure it when I return. Having to enter a 20 character password a few times an hour is wildly inefficient.

When I turn my laptop on and start it up from the off position I have to enter a very long and complicated passcode to decrypt the drive and boot the system. This secures my laptops and desktops if the hard drive is stolen. I only want to have to enter this long password once a day.

If I want to install new software, change system settings, or install updates I need to enter a slightly less lengthy and less complicated, but still very secure passcode to get root access. This passcode is only needed about once a week on my work computer.

My user passcode is the shortest and easiest to remember. On a busy day I need to enter this anywhere from 10 to 50 times a day. This is the passcode needed to unlock a locked screen.

If ctrl+alt+L locked the whole computer and didn't allow access to the terminal or any other part of the system, and furthermore only allowed 5 attempts of the user password to unlock the computer before the whole computer restarted, then my user passcode would be invulnerable to attack when the computer is locked. If 5 incorrect passcodes were tried then the system would restart and the system would once again require my most secure password to decrypt the drive just like it does when i start the computer in the morning.

To the correct user of the computer this would seem no different than the current locking of the screen. They could easily lock the computer with either the shortcut (ctrl+alt+ L) or through the 'Leave' menu and easily unlock it on their first passcode try, just as it is now.

This seems much more secure in my opinion.

"If someone logs into your user account they don't need a root password to view your files."

They do if your permissions are set up correctly, as TheBlackCat already stated.

ivan wrote:"If someone logs into your user account they don't need a root password to view your files."

They do if your permissions are set up correctly, as TheBlackCat already stated.

Most people aren't going to want to enter their root password to view their files, so I am not sure what you are suggesting. If I can view files I am working on without my root password, then so can anyone logged into my user account. Recent documents in OOo, CAD programs, Kmail, etc can all be viewed when I am logged in to my user account without the root password. If there is an option to require the root password to view files in all these various programs I wouldn't use it anyway, nor would most people as it is too time consuming to enter your root password each time you need to open something new. I am sorry if I am misunderstanding what you are referring too, if so please enlighten me.

airdrik wrote:This seems one of those illusion-of-security things.
If someone wants to 'borrow' your computer to get at stuff on your encrypted partition then they could just ctrl+alt+F1 to get to a terminal and brute-force your password there; bypassing completely the maximum password tries in KDM and your locked session.

And how do you get login from virtual console what supports and use (depending of distribution) blocking too many tries?

When the partition is encrypted, you can not force it open without massive time spend to crack the encryption.

If you set all partitions encrypted, GRUB to ask password, you can not even get single login. You can not move drive to other computer. What you would need always to do is first crack the encryption and it takes TIME (unless you get lucky and password is quessed in very short time).

The standard behaviour of all login/unloching programs is to wait 3 seconds after each failed attempt which stops brute-force attacks for reasonably secure passwords.

As airdrik said, adding this delay only for unlocking the screen could be very easily bypassed. No matter how /locked/ the KDE is, you could always send keystrokes directly to kernel to switch to a terminal and (try to) login there. Or via SSH, ...

Your approach is at best a solution for a symptom instead, when it doesn't deal with the problem. The problem is that when an encrypted partition is mounted, it becomes /unsecured/.

Wouldn't it be much better to unmount the encrypted drives on screen lock or something similar?

ivan wrote:
As airdrik said, adding this delay only for unlocking the screen could be very easily bypassed. No matter how /locked/ the KDE is, you could always send keystrokes directly to kernel to switch to a terminal and (try to) login there. Or via SSH, ...

You can not send keystrokes to Linux OS (= the kernel) and bruteforce the password. Correctly configured system disallows multiple wrong passwords and place the connection/user account to hold for 15 mins. I have such feature that if I give three times wrong password for any user via SSH, I have 15min waiting time for that account from remote connection. From localhost I can do only five times such thing and then it is 5min until I can try again to login as such user. That makes it perfectly safe against brute forces.

Your approach is at best a solution for a symptom instead, when it doesn't deal with the problem. The problem is that when an encrypted partition is mounted, it becomes /unsecured/.

Only if you can have access to it. And that means you need to break the OS or some way gain access to the user what have permissions to such files.

SELinux + Policykit + sudo + encryption makes pretty good privacy with some other technics.

ivan wrote:"If someone logs into your user account they don't need a root password to view your files."

They do if your permissions are set up correctly, as TheBlackCat already stated.

You are now assuming that cracker has access to other account.

But what was said, was that Cracker has password and username of User1. So Cracker can access to User1 files without problems. Setting permissions does not help at all in any other case then some other user tries to access files what does not belong to them. Like User2 is trying to open files what are owned by User1.

User is the weakest point. And root password is meaningless if others has user1 password and username because you have already access to his/her files. And if user1 has sudo configured wrong way that it has all rights what root has (like in Ubuntu). You have no security at all then in whole system because the user1 can access to user2 - user99+n files. If sudo is configured correctly that user1 has no access to other users files or can not manage users and can manage only very limited system programs and settings (but root account is active and can do whatever, even root account name is changed to other, like I do have), then it is more secure.

ivan wrote:Wouldn't it be much better to unmount the encrypted drives on screen lock or something similar?

Then you would need to enter the password to decrypt and remount the drive, which takes too long for someone who wants to resume their work quickly. If you make it too difficult to return from a locked screen then most people will never lock the screen.

ivan wrote:Your approach is at best a solution for a symptom instead, when it doesn't deal with the problem. The problem is that when an encrypted partition is mounted, it becomes /unsecured/.

The issue of a hard drive being unsecured when it is mounted isn't really the issue, the issue is the security of the user account. If you copy the hard drive or try to access the drive from a live CD the drive will be encrypted and unaccessible. If you're logged in as a different user than user 1, then you need a very secure root password to access private files. The fact that user passwords are usually shorter and less secure is the issue.

ivan wrote:As airdrik said, adding this delay only for unlocking the screen could be very easily bypassed. No matter how /locked/ the KDE is, you could always send keystrokes directly to kernel to switch to a terminal and (try to) login there. Or via SSH, ...

As I said before, change 'lock screen' to 'lock computer.'

Block keystrokes and input from any other device, except from the keyboard to KDE login. Don't allow SSH or any new devices to be plugged in to the computer until it is unlocked, and don't allow access to th terminal. I don't know everything about how an OS works, but this seems like something that KDE should be capable of.

"The fact that user passwords are usually shorter and less secure is the issue."

So, fix *this* issue.

As for locking the whole system. It isn't really possible from KDE. You'd need to:
- disable kernel support for SysRq
- disable all X shortcuts
- disable all system services that are accessible from the outside world (ssh, http...)
- in essence, make a single-user operating system

So, instead of having to just use a secure password, you want to make these changes?

ivan wrote:"The fact that user passwords are usually shorter and less secure is the issue."

So, fix *this* issue.

As for locking the whole system. It isn't really possible from KDE. You'd need to:
- disable kernel support for SysRq
- disable all X shortcuts
- disable all system services that are accessible from the outside world (ssh, http...)
- in essence, make a single-user operating system

So, instead of having to just use a secure password, you want to make these changes?

And how do you propose getting people to use more secure passwords?

The reality is that a lot of people don't or wont use a more secure password. Some are lazy, some just can't remember a 10 digit password of random characters.

You're suggestion is like saying we shouldn't concern ourselves with making cars safer, instead we should just stop getting in accidents. Yeah, that would be nice, but it's not realistic.

I use openSUSE with KDE on all my businesses computers and there are some employees who if I issued them a random ten digit password, would either:

A) Write it down on a post-it and stick it to their screen, which pretty much nullifies any passwords effectiveness .

B) They would get tired of having to enter a long password they barely remember, so would instead just leave their computer on and completely unlocked.

C) They would try to use the password issued to them, but would continually forget it, thus needing to call IT and get help which takes my IT people away from their actual job. This cycle of needing password assistance would likely recur weekly.

I would say either A, B, or C would apply to nearly half of all people. It's unfortunate, yes, but it's the way it is.

I need to make sure the information on my company computers is secure, and right now the inability to secure a computer for short periods of time while away from the computer is a huge weakness.

I do appreciate your technical perspective on the proposed solution, Ivan. However, I am not yet in agreement with you that this is an impossible thing to achieve.

Perhaps it would be possible to make all shortcuts for SysRq and X also shortcuts for system restart while the computer is locked in KDE. This way any shortcut you attempt to send to X or the Linux Kernel also initiates a restart from KDE.

Regarding access from outside services, perhaps that needs to be addressed as a separate issue. Firewalls and SSH sessions should be, and are on my computer, controlled with the root password. So the issue of an insecure user password doesn't apply to these instances.


So you asked if I would rather make the changes necessary to create a 'lock computer option' instead of just using a more secure password. To that, my answer is yes.

The other option would be implementing support for smart card authentication to unlock sessions and log into user accounts, though I fear many people would just walk away from a locked session with the smart card still in the computer. Another problem with this is that not everyone has a smart card reader.

Anyway, this issue may not be as simple a fix as I initially thought, but that doesn't mean steps to make the system more secure shouldn't be explored. The open-source community is full of brilliant minds, so I am confident that this is an issue that can be resolved in one way or another.

"You can not send keystrokes to Linux OS (= the kernel) and bruteforce the password."

Ok, this is what I meant - if KDE (the locker program) succeeds in locking X - for this, there can even be a way without changing anything outside of KDE.

If the user locks X, you /can/ send [ctrl+]alt+f1 directly to the kernel thus switch to VT1.

---

If KDM uses PAM (I don't know whether it is the default configuration), then wrong logins can be set up to block the account using pam_tally module.

So under "Correctly configured system", you can not brute force any way of login already.