From: Jason Gregson (Jason.Gregsoneasyi.com)
Date: Mon Oct 30 2006 - 06:34:26 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

As Peter said,

You will need to do a risk analysis of the system/s that you are proposing
to secure.
The only secure computer is one that is switched off and not plugged in to
any network and has not physical access to it. This does not help users that
need to have access to the computer so, you identify the risks and plan the
security. Security is a compromise between access vs. usability. No point
locking down a computer/system if none of the intended audience can access
it ;o)

There is some great documentation here -
http://www.sans.org/resources/policies/ - with sample policies as well.

You only have to look at some "Hacked Mirror" sites like www.zone-h.org to
see what happens when people ignore basic security advice.

On the Amazon front - this sounds like a classic schoolboy approach. "If
Johnny puts his hand in a fire, will you do the same." You need to assess
your own requirements first and then decide to put you hand in the fire with
Johnny. Amazon are not wrong but you would be taking a big risk in just
following Amazon's example. Amazon have sat down and calculated the risk,
put in the systems that would mitigate some/all of the risk to a
"acceptable" level. This way everyone is aware of what's systems are at risk
and to what extent. Then you manage the exceptions ;o)

To be fair to Peter, I don't think I added much more information than Pete,
just added gravitas to the situation ;o)

Kind regards

Jason Gregson

-----Original Message-----
From: listbouncesecurityfocus.com [mailto:listbouncesecurityfocus.com] On
Behalf Of Peter Conrad
Sent: 27 October 2006 09:53
To: webappsecsecurityfocus.com
Subject: Re: Why doesn't Amazon enforce a password policy?

Hi,

Am Dienstag, 24. Oktober 2006 19:34 schrieb James Strassburg:
>
> How should I go about convincing them that Amazon.com is wrong and the
> fact that they haven't had a severe account breach is no reason not to
> implement a policy ourselves? Or, to play devil's advocate with
> myself, if I'm wrong, why doesn't Amazon enforce a password policy?

as usual, you have to compare the cost of the change to the benefits.
The cost is that more complicated password procedures *will* drive some
users (potential customers) away. The benefit is that fewer user accounts
will be hacked. So how big is the damage that can be done through a hacked
user account, and how likely is it that a hacker will actually create that
much damage?

IMO, for Amazon the potential damage is medium (the attacker can order lots
of stuff for someone else), and the likelihood is low (because the attacker
can't draw a profit from the attack). OTOH, 1% fewer customers due to
"complicated" password requirements would be a big loss to Amazon.

So while Amazon's reasoning may be perfectly valid, it's not necessarily
valid for you. It depends on your situation.

(Apart from that, I wouldn't vote for password expiry, especially not in a
web application. How do you deal with expired accounts?
Delete them? Notify users before expiry? Whatever you do, it adds to the
"cost" side of the argument.)

Bye,
        Peter
--
Peter Conrad Tel: +49 6102 / 80 99 072
[ t]ivano Software GmbH Fax: +49 6102 / 80 99 071
Bahnhofstr. 18 http://www.tivano.de/
63263 Neu-Isenburg

Germany

-------------------------------------------------------------------------
Sponsored by: Watchfire

Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download our The Twelve Most Common Application-level Hack Attacks
whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008YTi
--------------------------------------------------------------------------

• application/x-pkcs7-signature attachment: smime.p7s

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]