1996-01-17 - Re: new web security product

Header Data

From: Steve Gibbons <steve@aztech.net>
To: bshantz@nwlink.com
Message Hash: 7c92db1e686d2a3a0c9afe42a9fb6906a82288e15b3ed634b448ef698ab9c5f9
Message ID: <0099C802.AA1011C0.13@aztech.net>
Reply To: N/A
UTC Datetime: 1996-01-17 20:16:29 UTC
Raw Date: Thu, 18 Jan 1996 04:16:29 +0800

Raw message

From: Steve Gibbons <steve@aztech.net>
Date: Thu, 18 Jan 1996 04:16:29 +0800
To: bshantz@nwlink.com
Subject: Re: new web security product
Message-ID: <0099C802.AA1011C0.13@aztech.net>
MIME-Version: 1.0
Content-Type: text/plain


# Perry Metzger wrote: 
# > I don't think its going to fly. No one wants to pay for an unneeded
# > $100 piece of hardware to encrypt the same credit card over and over
# > again, when a nearly zero marginal cost piece of software can do the
# > same thing.

Merchants might.  Current credit-card processing terminals are increadibly
overpriced for what you get.  $100.00 plus the price of an inexpensive PC, plus
proprietary software isn't too far of the mark, in comparison.

# I agree with Perry. Hardware encryption does add a layer of security 
# not normally found in software, but it is hardware.

I've been a fan of unrelated encryption at each layer of the 7 (5, 4, whatever)
layers,  lateley.  In military/financial terms, the question of "who has access
to what" and "needs to know what" at different levels of the protocol stack
make a big difference.  Network guys should be able to perform traffic
analysis, application guys should be able to debug application-specific
traffic, but not visce versca.

# Shoot, I don't even have a 28.8 modem yet, why would I want a black 
# box that supposedly does something with my Credit Cards?

If you think "Not _my_ credit cards, but my _customers'_...", then it starts to
make sense.

--
Steve@AZTech.Net





Thread