-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Robert,
> The various web app schemes aren't trying to establish iron-clad security.
> They are trying to reduce the risk of loss to the client (customer) and
> server (merchant) to an acceptible level without being so intrusive that
> the clients won't attempt the transaction or be turned away.
>
> The reason we can't get better security for current systems is that they
> pass the "good enough" tests for most clients. Merchants and credit card
> companies have enough data to understand the loss rate. So long as they can
> recover that in the prices they charge, there's no reason to change (same
> thing applies to ATMs).
- From the insurance broker's point of view (which I can fortunately follow to
some extent due to some decent knowledge of statistics) you are of course
right - the loss of income you lower with improved "security" should always
outweigh the investment in it...
Alas, such an attitude
- - is unsatisfactory from a theoretical point of view
- - does not help to improve things basically
The "good enough" policy is dangerous, because there are certainly always
some attackers who are willing and able to exploit that on a large scale (just
like all worst case scenarios: they are rather improbable but could be
devastating if they occur) and it is dangerous because it might lower the
overall trust in your system (some "victims" that you had in your calculation
may be disappointed and not contented with the offered compensation).
On the other hand it is not a real option from a "customers" point of view to
pay the price for only "good enough" systems some supplier uses - in a long
term calculation a "best possible" strategy will surely pay off better.
Kind regards
Ingo
- --
ingo_at_ingostruck.de
Use PGP: http://ingostruck.de/ingostruck.gpg with fingerprint
C700 9951 E759 1594 0807 5BBF 8508 AF92 19AA 3D24
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE/JFdZhQivkhmqPSQRAmAyAJ988VgEdVnf8so069kd3XfVQiOemQCg0Iu1
S7E56p/bULbsAIHG9DQskmI=
=QNaS
-----END PGP SIGNATURE-----
Received on Jul 28 2003
Intro
