+1

 

For the past few years, every time we've had a server compromised, it has
been because something was overlooked or done incorrectly by one of our own
people, such as not changing default administrator passwords,  assigning
improper permissions to key folders or leaving vulnerable ports open.

 

-Malcolm

 

From: Andrew S. Baker [mailto:[email protected]] 
Sent: Friday, April 16, 2010 09:14
To: NT System Admin Issues
Subject: Re: please don't change your password!

 

This fails to consider the situation where a user's password is compromised
and the bad guy accesses the user's information on an ongoing basis. For
instance, monitoring a folder that contains files with information about
patent filings to see when new  files show up, or logging into OWA to keep
an eye on e-mail messages. The unauthorized access will end once the
password is changed (assuming a variety of other factors, such as the bad
guy not getting the new password, etc.), and thus requiring regular password
changes can be of value.

 

 

We live in a world where scripted attacks dominate, and where targeted
attacks are against highly privileged assets.

 

Add to that, most scripted attacks are aimed at an application or OS or
protocol vulnerability, with the primary intent of sending spam or rooting
the machine in some way.

 

Thus, the changing of passwords does little to mitigate any of the
aforementioned.

 

Even a targeted attack is likely to take steps to elevate privileges and
creating a new account for the purpose of removing reliance on the
compromised account.

 

 

Similarly, regular password changes can mitigate the risk from brute-force
attacks. If a password has to be changed every 60 days, for instance, the
bad guy will only have 60 days to try to determine the user's password. This
is generally considered to be better than the bad guy having an infinite
amount of time to try to determine it.

 

 

In most cases, it doesn't take weeks to brute force an account.  Mostly
hours, and occasionally days.  (Doesn't everyone have a quad-core system or
set of systems?)

 

But that's not really the point.  Most breaches today aren't accomplished
via brute force of the password.  There are hundreds of other approaches to
get into systems remote that require far less time and effort, and all lead
to elevated rights.

 

-ASB: http://XeeSM.com/AndrewBaker

 

On Fri, Apr 16, 2010 at 8:51 AM, John Hornbuckle
<[email protected]> wrote:

There's a flaw in the logic.

 

The Globe article states:

 

" . . . [U]sers are admonished to change passwords regularly, but redoing
them is not an effective preventive step against online infiltration unless
the cyber attacker (or evil colleague) who steals your sign-in sequence
waits to employ it until after you've switched to a new one, Herley wrote.
That's about as likely as a crook lifting a house key and then waiting until
the lock is changed before sticking it in the door."

 

This fails to consider the situation where a user's password is compromised
and the bad guy accesses the user's information on an ongoing basis. For
instance, monitoring a folder that contains files with information about
patent filings to see when new  files show up, or logging into OWA to keep
an eye on e-mail messages. The unauthorized access will end once the
password is changed (assuming a variety of other factors, such as the bad
guy not getting the new password, etc.), and thus requiring regular password
changes can be of value.

 

Similarly, regular password changes can mitigate the risk from brute-force
attacks. If a password has to be changed every 60 days, for instance, the
bad guy will only have 60 days to try to determine the user's password. This
is generally considered to be better than the bad guy having an infinite
amount of time to try to determine it.

 

 

 

John Hornbuckle

MIS Department

Taylor County School District

www.taylor.k12.fl.us

 

 

 

 

 

From: Brian Clark [mailto:[email protected]] 
Sent: Thursday, April 15, 2010 4:38 PM


To: NT System Admin Issues

Subject: please don't change your password!

 

After a long week doing a SBS migration I didn't know how to take this
article and needed to share it!! 

 

http://www.boston.com/bostonglobe/ideas/articles/2010/04/11/please_do_not_ch
ange_your_password/?page=1

 

 

Brian 

 

 

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to