View Single Post
  #9   (View Single Post)  
Old 7th November 2008
anemos's Avatar
anemos anemos is offline
Fdisk Soldier
 
Join Date: May 2008
Location: Ελλάδα
Posts: 53
Default

Guys, congratulations for this guide. Although I haven’t followed it yet, it seems you have done a very mindful research. However, I do have some objections.

1.
Quote:
It's quite simple really:

Code:
# pkill -KILL -u <username>
You think that it is so simple to kill a user's session? How do you know what he/she does at that time? Even a gamer would kill you (literally) - imagine a real-life user.

2.
Quote:
The quick and easy way is to set the "change" date on the user's password. There are a few different ways to do this, and I'll touch on each way.

The first way is by using the chsh command. The syntax is:

Code:
# chsh <username>
This does the job for 5-10 users. What happens when there are more and you want to change their passwords, say, every 60 days, which incidentally is absolutely common?

3.
Quote:
You can quickly set a new random password, that will expire at first login, with:
Code:
pw usermod <user> -p 0-0-0 -w random
Making it (relatively) safe to email it to him. If anyone retrieves the email later on, chances are, the password has already changed.
It is not safe[r]. The risk when sending a password via email is while sending it.

4.
Quote:
It means that users who change their password can only use 12-byte (or more) passwords with characters from three classes or 10-byte (or more) passwords with characters from four classes. It also means that a password too similar to the previous one will be rejected.
I understood that (at least I think so). But how can you explain it to the grandma working three doors next to you?



To conclude, I don't mean to start any flame on this subject (honestly),
though you all know that we can talk/write for hours for such a topic.

Technically speaking, this thread is very helpful.
But password policy enforcement, as this guide's title claims to be, is not as simple as that
and I, personally, would be more cautious when using such terms/words.

I would also appreciate if inside this guide was included an instruction such as:
How to make users understand why they should use a strong password instead of impose strict policies.

No intention to offend anyone

Last edited by anemos; 7th November 2008 at 09:13 PM.
Reply With Quote