FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Red Hat Install

 
 
LinkBack Thread Tools
 
Old 08-22-2008, 04:55 PM
Karl Pearson
 
Default Cycling Passwords

I'm curious on your take on systems that require changing passwords on a
set schedule, whether it's 90 days or whatever.


When I've setup new systems, I instruct the users to select passwords that
are cryptic and follow guidelines that make them essentially impossible to
crack, such as: Ol10yzZx119xa


Once a good password is found, why change it? I know there are a lot of
consultants who say you must, but everywhere I've been that requires
people to change passwords, I see they have written them on sticky notes
and then put them on their monitor, or bookshelf or whereever. I also see
the frustration level raise everytime they are trying to get into a system
with a customer on the phone, and they have to tell them to wait for their
session as they change their password...


Since roughly 90% of corporate break-ins are from the inside, having to
change the passwords, and then sticking the passwords up, defeats the
security purposes for changing passwords.


What do you think?

Okay, I do have a reason for asking this: 1. convince me I'm wrong, and 2.
I have a client that wants it to stop, and I need to know where in Fedora
Core 6 that is setup so case I can make the change for them.


Their FC6 system is setup so the accounts go to /sbin/nologin so they
don't have to change their password for email. But no one has shell
access, and a few need it, thus creating the need for passwords to change.


TIA

--
Karl L. Pearson
karlp@ourldsfamily.com
http://consulting.ourldsfamily.com
---
My Thoughts on Terrorism In America right after 9/11/2001:
http://www.ourldsfamily.com/wtc.shtml
---
The world is a dangerous place to live... not because of
the people who are evil, but because of the people who
don't do anything about it.
- Albert Einstein
---
"To mess up your Linux PC, you have to really work at it;
to mess up a microsoft PC you just have to work on it."
---

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 08-22-2008, 06:11 PM
Rick Stevens
 
Default Cycling Passwords

Karl Pearson wrote:
I'm curious on your take on systems that require changing passwords on a
set schedule, whether it's 90 days or whatever.


When I've setup new systems, I instruct the users to select passwords
that are cryptic and follow guidelines that make them essentially
impossible to crack, such as: Ol10yzZx119xa


Once a good password is found, why change it? I know there are a lot of
consultants who say you must, but everywhere I've been that requires
people to change passwords, I see they have written them on sticky notes
and then put them on their monitor, or bookshelf or whereever. I also
see the frustration level raise everytime they are trying to get into a
system with a customer on the phone, and they have to tell them to wait
for their session as they change their password...


Since roughly 90% of corporate break-ins are from the inside, having to
change the passwords, and then sticking the passwords up, defeats the
security purposes for changing passwords.


What do you think?

Okay, I do have a reason for asking this: 1. convince me I'm wrong, and
2. I have a client that wants it to stop, and I need to know where in
Fedora Core 6 that is setup so case I can make the change for them.


Their FC6 system is setup so the accounts go to /sbin/nologin so they
don't have to change their password for email. But no one has shell
access, and a few need it, thus creating the need for passwords to change.


Any access control system should be tailored to the specific needs of
your business. It is entirely possible to make a server or network so
secure it's unmanageable. The art of it is balancing security against
ease of use and flexibility.

We set up PCI-compliant systems (you know, credit card processing), so
our attitude towards passwords is "make them complex and change them
often". We're driven by the statement: "Just because we're paranoid
doesn't mean they AREN'T out to get us!"

Since in your case user accounts don't have a shell associated with
them, an enforced password rotation schedule would have minimal positive
effects. Your root, administrative and any other account with shell
access should be put on an enforced rotation. This is only sensible.

Our (somewhat paranoid) systems use this:

We require our root passwords to be rotated at least every 90 days, but
no one's allowed to have them. Root and admin passwords use the
following criteria:


1. We use cracklib
2. Minimum of 12 characters
3. Minimum of two upper case characters
4. Minimum of one special character (punctuation mark)
5. Minimum of two decimal digits
6. A given password cannot be reused until at least three others have
been used.
7. No minimum lifetime
8. Maximum lifetime of 90 days

Our security admin creates passwords on the systems themselves in the
standard /etc/passwd and /etc/shadow files, then creates a KeePass file
containing them which is put on two FLASH pendrives kept in two
different firesafes in two different offsite locations. They're
available if we need them, but all administrative work is done by
designated personnel using sudo.

All of our authentication data (with the exception of root and other
admin stuff above) is maintained in LDAP on two, fully redundant LDAP
servers. We do lessen the restrictions for normal user accounts:

1. Minimum lifetime is 1 week
2. Maximum lifetime is 365 days
3. Minimum of 8 characters
4. Must have one uppercase character
5. Must have one decimal digit
6. A given password cannot be reused until three others have been used.

The LDAP server enforces these requirements via the "ppolicy" overlay
and a custom password checking library specifically written for this
purpose (they're easy to write). We also make use of the "host"
attribute capability of LDAP (if a user tries to authenticate from a
machine and that machine is not in a "host" attribute in the user's LDAP
entry, they're denied access).

The LDAP database also includes the equivalent of the /etc/sudoers file
and all machines use the LDAP sudoers data. You can set an attribute in
LDAP that will prevent the machines from even looking at a local
/etc/sudoers file, which makes circumventing the sudo system more
difficult.

We have a few admins that do real heavy lifting where having to enter
"sudo this" and "sudo that" can be onerous. we allow them to create a
root shell via "sudo bash -l". Needless to say, these are highly
trusted people.

As I said, these are probably more extreme than most systems need, but
we have financial data coursing through our systems. With some mods,
they may work for you.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer rps2@nerd.com -
- Hosting Consulting, Inc. -
- -
- We have enough youth, how about a fountain of SMART? -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 08-23-2008, 01:32 AM
"Daniel A. Rachels, Sr."
 
Default Cycling Passwords

On 22 Aug 2008 at 10:55, Karl Pearson wrote:

> I'm curious on your take on systems that require changing passwords on a
> set schedule, whether it's 90 days or whatever.
>
> When I've setup new systems, I instruct the users to select passwords that
> are cryptic and follow guidelines that make them essentially impossible to
> crack, such as: Ol10yzZx119xa
>
> Once a good password is found, why change it? I know there are a lot of
> consultants who say you must, but everywhere I've been that requires
> people to change passwords, I see they have written them on sticky notes
> and then put them on their monitor, or bookshelf or whereever. I also see
> the frustration level raise everytime they are trying to get into a system
> with a customer on the phone, and they have to tell them to wait for their
> session as they change their password...
>
> Since roughly 90% of corporate break-ins are from the inside, having to
> change the passwords, and then sticking the passwords up, defeats the
> security purposes for changing passwords.
>
> What do you think?
>
> Okay, I do have a reason for asking this: 1. convince me I'm wrong, and 2.
> I have a client that wants it to stop, and I need to know where in Fedora
> Core 6 that is setup so case I can make the change for them.
>
> Their FC6 system is setup so the accounts go to /sbin/nologin so they
> don't have to change their password for email. But no one has shell
> access, and a few need it, thus creating the need for passwords to change.
>
> TIA

After retiring from the Army, I could not believe the password situation at the school where I
started working as a computer applications teacher. I found that many of the teachers were using
their spouses and kids names as passwords. Or just as bad,coaches who rotated their
passwords between baseball, football, and basketball. Needless to say on more than one
occasion we caught a student logged in on a teacher's computer.

When I convinced the technology coordinator to have them start to use strong passwords, we
discovered that most started writing them on sticky notes and attaching them to the bottom of
their keyboard, and more than one, right on the side of the monitor. Their excuse was always that
they were afraid they would forget that complicated password, especially over a long holiday
break or summer vacation. And, we of course caught students stealing the teachers passwords
and using them, again.

We finally started giving classes on how to make very complicated passwords that are actually
very easy to remember. For instance, take a significant name that only you know and will never
forget and a significant year associated with that name. Spell the name backwards, mix in the
year as every other letter, and add some punctuation to finish it out. For example my son's first
pet dog was named Boomer and we got him in 1989. Absolutely no one where I work knows
about the dog. That info could easily be turned into this password: r1e9m8o9o!B This makes for a
nice complicated password that can easily be remembered without writing it down. After just a
few slow logins most teachers quickly remember the sequence and can bang it out in just a
couple of seconds.

Of course we do have to remind them periodically and check to make sure they are following the
new guidelines as well as teach any new teachers that are hired.



Daniel A. Rachels, Sr.
drachels@adelphia.net

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 08-23-2008, 04:15 PM
wonderer
 
Default Cycling Passwords

Hy,


Once a good password is found, why change it?
Because every password can be "suggested" (Bruteforce). If you cange a
password continously it is much harder to bruteforce it in a manner of time.
I know there are a lot of consultants who say you must, but everywhere
I've been that requires people to change passwords, I see they have
written them on sticky notes and then put them on their monitor, or
bookshelf or whereever. I also see the frustration level raise
everytime they are trying to get into a system with a customer on the
phone, and they have to tell them to wait for their session as they
change their password...
On the one hand there is the technical problem of changing the password.
On the other hand you have the social problem that people are dumb
(sorry, it is so techincaly spoken).
If you want better technical barriers to get in a system like SmartCards
or USB Tokens then there was the problem that people losse them or other
"social problems arround technical".



Okay, I do have a reason for asking this: 1. convince me I'm wrong,
and 2. I have a client that wants it to stop, and I need to know where
in Fedora Core 6 that is setup so case I can make the change for them.
If you Client wants that then I would hardly suggest that he will sign a
paper where ALL responsibilitys in case of an emergancy was fully on HIS
side and that HE decides that to be changed.


I think it would be better to make a short (1-2h) briefing over password
security and make ALL employees cut of this sticky notes stuff.



best regards
Henrik


P.S.: I thought since Virus-Scanners and SPAM-Attacks these days this
very old discussions was over. I have to change my mind.


_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 

Thread Tools




All times are GMT. The time now is 09:30 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org