21

ivan wrote:
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.

Could you please elaborate further. As far as I know, there is nothing currently blocking the user account from multiple bad logins, either through KDM or a terminal. If there is something already existing that could block multiple failed log in attempts through a terminal, then that would pretty much solve the problem. There is already enough of a delay for the password attempt in KDM that a brute force attack isn't likely possible there, but being able to start a new session in the terminal is where you could possibly launch a brute force attack.

So is pam _tally a reliable way to secure against failed log ins? Can it be circumvented?

From what I just read it appears PAM will protect ssh, su, login, and kdm.

I'd never heard of PAM until now, but as far as I can tell, if it is set-up properly, it has the potential to stop any brute force attempt.

Now I need to go read more about PAM and how to implement it. Thank you very much for sharing your wisdom Ivan, it is much appreciated.

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

Well, from my point of view, if a user wants to be safe, (s)he will choose a proper password - if the user doesn't care about his security, why should we?

If the password is written on a post-it note, there is absolutely nothing we can do to circumvent that.

The chain is as strong as the weakest link - it doesn't matter if we make the system unbreakable if the user puts 123456 as a password. Our (devs in general, not only KDE) job is to make the system as unbreakable as the user (as the weakest link) is.

So, if you want security, you can get it.

----

As for pam_tally, I haven't used it, but from what I've read, it does just that - counts the failed log-in attempts and locks the account for a specified period of time. And if all login-related services are using PAM, it should be a sufficient brute-force stopper.


"Thank you very much for sharing your wisdom Ivan, it is much appreciated."

No problem, I always enjoy constructive debates

Some configuration for delays etc. would be nice. It would be even better if KDE would manage these settings for the normal login-shell, too.
What would be about shutting down the pc after maybe 5 wrong passwords or after typing a special shutdown-password? So nobody could try to access the RAM directly.

@The User: RAM? What do you mean to /access RAM directly/ - that is prevented by kernel. It wouldn't be easy to do even with the root access.

When there is no way to access the data on the hd because you can't login and they are encrypted, side-effect-attacks or trying to look into the RAM are the onliest possibilities and they are impossible after shutdown.

"they are impossible after shutdown"

Unfortunately not, RAM doesn't really erase everything immediately.

As for the encrypted data - if the partition is mounted, it becomes virtually unencrypted. So if you have enough cracking skills, you'd be able to access it as easy as accessing RAM.

If it isn't mounted, then it is a completely different story.

But, we are derailing from the initial topic here.

We can discuss about some details, but shutting down the pc is certainly good for security...

Would a pam-config-dialog in systemsettings solve the initial problem? I think it is more or less an implementation detail for this idea.

"certainly good for security..."

yes it is, but from my POV it is a bit paranoid

If somebody wanted your data that badly, the easiest way would be to attack the weakest link (the user) physically and /ask/ you for the password

"Would a pam-config-dialog in systemsettings"

Probably yes, the problem is that PAM has a lot of modules, so that configuration dialogue wouldn't ever be complete. But, yes, it could contain this option.

ivan wrote:If somebody wanted your data that badly, the easiest way would be to attack the weakest link (the user) physically and /ask/ you for the password

It's worth remembering, too, that many studies have shown that the most frequent path to breaking security is social engineering - finding a way to convince users that you need their passwords and have the right to ask for them. The number of people that respond to phishing attacks bears this out.

@ivan
This thread is for feeding our paranoias.
(ah, you fed it, I need a program to overwrite the RAM )
Imagine the police or something like that, hopefully they won't /ask/ too aggressively.


@annew
We are too paranoid for that kind of attacks. *g*
I do not think that KDE could do anything against such social engineering stuff, I think there are enough dialogs in the web etc. explaining "do not tell...".

Don't get me wrong - I wasn't for one moment suggesting that we should attempt to tackle this issue other than by education. And that, I think, is our personal responsibility in training our family and friends, even interested outsiders, but no part of KDE's responsibility.