E-commerce security????
jaywhy
there SSL to transfer credit cards? People think SSL most be secure, or why
would they use it?
Certificate based public key encyption does provide secure transmission,
but security with who? Do I have a secure transmission with Amazon.com or
some hacker in a country with no extradition treaties posing as Amazon.com?
I know security isn't a one layer thing, and SSL isn't the answer. But what
is? SSL doesn't keep you secure from people hacking into Amazon.com, and
just stealing the information after transmission.
How does a business keep credit information? You can't just encrypt the
customers credit information and think you're secure. The encryption
algorithm relies of the security of the private key, and the protocols in
which you deploy it. The layering of security on top of heavy encryption is
the best option. Deploying a firewall, NIDS, and making the server that
hold the credit information secure as possible.
Even with all that security, the private key still has to be kept
private. How do you do that? Putting the private key on some type of
external device is an option. You most create security protocols for the
disk now. How do you keep it safe from some disgruntled employee looking to
trash your companies reputation. Furthermore the disk most be inserted
every single time you need it, automatic billing systems are no longer
automatic. Billing most be overlooked now.
The private key is your doorway to bill your customers. What if the key
is lost, destroyed, or corrupted. If you lose the keys to your house, call
a locksmith. If you lose the key to your 128-bit algorithm, good luck.
Barring any organizations with three letter names, you're basically screwed.
No wonder business's place credit information in clear text. It's a whole
lot easier.
I guess my question is, How do you keep customer information secure?
And I'm also guessing my question has no right answer.
--
Jason Yates
jay...@home.com
Jim Watt
Its a big question with an expensive answer beyond the scope
of Usenet. Send a large blank cheque by DHL
--------
Jim Watt - see the website http://www.gibnet.com
--------
Martin
> Its a big question with an expensive answer beyond the scope
> of Usenet. Send a large blank cheque by DHL
lol
my sentiments exactly....like we're going to tell all of you our secrets :)
jaywhy
the...@ntlworld.com wrote on 9/1/01 4:40 PM:
But there are no secrets, you just don't know how. Does anyone? I don't
think so.
--
Jason Yates
jay...@home.com
Ilas
> And I'm also guessing my question has no right answer.
>
single question consists of a varying number of underlying issues. And all
those issues will have different solutions based on the type of company, the
business they conduct, the amount of security they want, legislation, etc.
And I don't think that there is no right answer. You just need a lot of
information, time, knowledge, skilled people, dedication, communication,
etc. to create a very good (perfect is not possible and also not wanted
IMHO) security architecture for a company. That is why all the security /
consultancy firms are making such a lot of money out of this ;-)
Norm
jaywhy wrote:
>
> What is security in e-commmerce? Is there such a thing? Well isn't
> there SSL to transfer credit cards? People think SSL most be secure, or why
> would they use it?
128 bit SSL is secure since if you do not know the key you would have to
try 2^128 possible combinations to gaurantee finding the key. Of course
you could get lucky on the first try, but that is 1 in 2^128 ~ 3.4E38.
Highly unlikely. Of course if you pick really bad keys, it makes it
easier for the enemy. German coders used to use HIT LER as their two
3 letter keys. Needless to say it made it much easier for English
code breakers at Bletchley Park. (They used the first to encrypt the
second and the second was the key for the message. This way they had an
encrypted key exchange. Well, almost.).
> Certificate based public key encyption does provide secure transmission,
> but security with who? Do I have a secure transmission with Amazon.com or
> some hacker in a country with no extradition treaties posing as Amazon.com?
> I know security isn't a one layer thing, and SSL isn't the answer. But what
> is? SSL doesn't keep you secure from people hacking into Amazon.com, and
> just stealing the information after transmission.
Yes, that is how it is typically done. Find a weakness in security on
one
of the servers. DNS cache spoiling and man in the middle attacks are
successful
in this scenario.
> How does a business keep credit information? You can't just encrypt the
> customers credit information and think you're secure. The encryption
> algorithm relies of the security of the private key, and the protocols in
> which you deploy it. The layering of security on top of heavy encryption is
> the best option. Deploying a firewall, NIDS, and making the server that
> hold the credit information secure as possible.
Don't keep it beyond what is needed to get your money. As soon as you
have
the money why do you care about the numbers? It is because you want to
take advantage of impulse buying of your customers. Gosh if I had to
enter my credit card everytime I made a purchase I would have to
actually want the product rather than making a snap decision. It is a
marketing ploy not a security feature. Now that you only have
outstanding
accounts in your database, your customers are not at risk for quite
as long (a couple days versus forever).
Have a well defined period of time to keep the information if no sales
have occured. If someone has not bought something for a month, purge the
numbers.
> Even with all that security, the private key still has to be kept
> private. How do you do that? Putting the private key on some type of
> external device is an option. You most create security protocols for the
> disk now. How do you keep it safe from some disgruntled employee looking to
> trash your companies reputation. Furthermore the disk most be inserted
> every single time you need it, automatic billing systems are no longer
> automatic. Billing most be overlooked now.
Don't hire losers. Treat your employees half way decent. Gosh if my
previous
employers hadn't screwed me so bad, I might have actually cared about
their success. Now everytime NASDAQ goes down I laugh. Hee hee hee.
> The private key is your doorway to bill your customers. What if the key
> is lost, destroyed, or corrupted. If you lose the keys to your house, call
> a locksmith. If you lose the key to your 128-bit algorithm, good luck.
> Barring any organizations with three letter names, you're basically screwed.
> No wonder business's place credit information in clear text. It's a whole
> lot easier.
>
Ignorance is bliss and laziness is everywhere. Key Escrow.
> I guess my question is, How do you keep customer information secure?
> And I'm also guessing my question has no right answer.
>
There are many ways to have security. Unfortunately most of them are
contrary
to "business requirements". Since getting business people to understand
security is like herding cats, it is rarely accomplished.
Security is possible, the truth is out there.
> --
> Jason Yates
> jay...@home.com
--
Problems cannot be solved at the same level of awareness that created
them.
A. Einstein
Anne & Lynn Wheeler
>
> There are many ways to have security. Unfortunately most of them are
> contrary
> to "business requirements". Since getting business people to understand
> security is like herding cats, it is rarely accomplished.
>
> Security is possible, the truth is out there.
note that prior to the internet with electronic commerce ... by far
the largest amount of fraud was insider fraud ... and there was lots
of attention attempting to address insider fraud. since electronic
commerce internet activity ... there is a lot of focus on handling
outsider exploits. potentially that will get addressed and get back to
the state of security issues of 15-20 years ago.
digital commerce trivia question
http://www.garlic.com/~lynn/aadsmore.htm#dctriv digital commerce trivia question
misc connections
http://www.garlic.com/~lynn/2001i.html#52 misc. connections
random refs:
http://www.garlic.com/~lynn/subtopic.html#fraud
--
Anne & Lynn Wheeler | ly...@garlic.com, http://www.garlic.com/~lynn/
Norm
>
> Norm <no...@justhacked.org> writes:
> >
> > There are many ways to have security. Unfortunately most of them are
> > contrary
> > to "business requirements". Since getting business people to understand
> > security is like herding cats, it is rarely accomplished.
> >
> > Security is possible, the truth is out there.
>
> note that prior to the internet with electronic commerce ... by far
> the largest amount of fraud was insider fraud ... and there was lots
> of attention attempting to address insider fraud. since electronic
> commerce internet activity ... there is a lot of focus on handling
> outsider exploits. potentially that will get addressed and get back to
> the state of security issues of 15-20 years ago.
>
Yes, and people used to run credit cards on carbon paper and throw
the carbon in the trash. The carbon had a picture perfect reverse
image of everything you needed to complete a transaction. If you
did a little dumpster diving you would get the days receipts (or
weeks, depending on when the trash man came.) However, today, with
databases, you could conceivably get every credit card of every
person who's ever done business with the company. If the store
owner is a crook, then there is little you can do to protect
yourself, other than not do business with him. The company
employees can of course steal your credit card info during the
process of taking it for a purchase. The Internet has made it
faster and up'd the scale of the amount of credit card numbers
you can get a hold of. It is scale and pervasiveness of the
information that is the problem and what makes it lucrative to
break into e-commerce sights. The risk is low and the rewards
are high, especially if the perpetrator is in a foreign country.
If the perpetrator is an insider it is much easier to catch
them. Just follow the money.
Security is possible and the truth is out there. It just means
an intrusive security policy.
Don't take risk without the possiblity of commenserate reward.
> digital commerce trivia question
> http://www.garlic.com/~lynn/aadsmore.htm#dctriv digital commerce trivia question
>
> misc connections
> http://www.garlic.com/~lynn/2001i.html#52 misc. connections
>
> random refs:
> http://www.garlic.com/~lynn/subtopic.html#fraud
>
> --
> Anne & Lynn Wheeler | ly...@garlic.com, http://www.garlic.com/~lynn/
--
Anne & Lynn Wheeler
> Yes, and people used to run credit cards on carbon paper and throw
> the carbon in the trash. The carbon had a picture perfect reverse
> image of everything you needed to complete a transaction. If you
> did a little dumpster diving you would get the days receipts (or
> weeks, depending on when the trash man came.) However, today, with
> databases, you could conceivably get every credit card of every
> person who's ever done business with the company. If the store
> owner is a crook, then there is little you can do to protect
> yourself, other than not do business with him. The company
> employees can of course steal your credit card info during the
> process of taking it for a purchase. The Internet has made it
> faster and up'd the scale of the amount of credit card numbers
> you can get a hold of. It is scale and pervasiveness of the
> information that is the problem and what makes it lucrative to
> break into e-commerce sights. The risk is low and the rewards
> are high, especially if the perpetrator is in a foreign country.
the problem is that current infrastructure effectively makes the
account number a "shared-secret" ... since harvesting the account
number is sufficient to generate a valid transactions (and therefor
account numbers have to be treated as shared secrets). Financial
standard for all account-based electronic payments changes that ... so
that transactions are authenticated and account numbers no longer are
an exploit. For lots of references about X9.59 standard for all
account-based electronic payments:
for some ancillary discussion about harvesting of credit card account
number files:
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk
misc. discussions about account number harvesting:
http://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
http://www.garlic.com/~lynn/aepay6.htm#harvest harvesting of credit card numbers
http://www.garlic.com/~lynn/aepay6.htm#harvest2 shared secrets, CC#, & harvesting CC#
http://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes giving Stanford EE380 talk this
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared Secret exploit
http://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#19 [Newbie] Authentication vs. Authorisation?
http://www.garlic.com/~lynn/2001f.html#24 Question about credit card number
http://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001f.html#52 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#54 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#55 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001g.html#0 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#63 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#68 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#70 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/subtopic.html#privacy X9.59, Identity, Authentication, and Privacy
http://www.garlic.com/~lynn/subtopic.html#fraud Risk, Fraud, Exploits
Norm
>
Why should the vendor keep the credit card information Forever?
If you do not keep it online forever, then the risk is reduced
significantly. You still have employee risk, but that will
always be a problem. Any time you "trust" someone you accept the
risk of getting burned.
Trust - giving someone enough information to damage/harm you.
If the vendor merely deletes the data after the transaction is
completed the outside and inside cannot get to it but for a
limited time frame.
Lyalc
Some have very different solutions which vary depending on the mix of risk,
technology and business process the e-commerce company wants to invest in.
Lyal
"jaywhy" <jay...@home.com> wrote in message
news:B7B6B035.1AC4%jay...@home.com...
Anne & Lynn Wheeler
> Why should the vendor keep the credit card information Forever?
> If you do not keep it online forever, then the risk is reduced
> significantly. You still have employee risk, but that will
> always be a problem. Any time you "trust" someone you accept the
> risk of getting burned.
>
> Trust - giving someone enough information to damage/harm you.
>
> If the vendor merely deletes the data after the transaction is
> completed the outside and inside cannot get to it but for a
> limited time frame.
first off the business rules (aka the credit card associations have
rules that merchants must follow) have things about stuff like
charge-backs and the merchant having the records associated with same
(i.e. a customer may be able to dispute for 90-180 days ... and the
material provided to the merchant may be as little as account# and
date ... so merchant must keep records at least as long as there is
possibility of chargeback &/or other dispute).
the initial translation of credit card (aka electronic commerce) to
internet was relatively straight-forward since there was already
provisions for non-face-to-face MOTO (mail-order/telephone-order)
transactions ... ref to this effort:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
however, because account number is effectively shared-secret, there
are all kinds of exploits ... not just limited to the internet. As a
result, the financial standards body developed the X9.59 standard for
ALL account-based payments (not just limited to internet but can be
done at point-of-sale also and other types of environments). refs to
debit implementation
http://www.garlic.com/~lynn/nacharfi.htm
http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm
refs: to X9.59 mapping to iso8583 (aka international message standard
used by both credit and debit networks):
http://www.garlic.com/~lynn/8583flow.htm
--
Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/
Norm
>
>
> > Why should the vendor keep the credit card information Forever?
> > If you do not keep it online forever, then the risk is reduced
> > significantly. You still have employee risk, but that will
> > always be a problem. Any time you "trust" someone you accept the
> > risk of getting burned.
> >
> > Trust - giving someone enough information to damage/harm you.
> >
> > If the vendor merely deletes the data after the transaction is
> > completed the outside and inside cannot get to it but for a
> > limited time frame.
>
> first off the business rules (aka the credit card associations have
> rules that merchants must follow) have things about stuff like
> charge-backs and the merchant having the records associated with same
> (i.e. a customer may be able to dispute for 90-180 days ... and the
> material provided to the merchant may be as little as account# and
> date ... so merchant must keep records at least as long as there is
> possibility of chargeback &/or other dispute).
>
Generally you have 60 days to dispute a charge from the time you
get a statement. So that would imply at least 90 days for the
business to keep transaction data. Does that data need to be on
a server connected to the Internet. No. It could be archived
to an offline server that is a peice of junk but has lots of
storage capacity. Only a few employees, those that handle disputes
need access. In the CD Universe case a Russian attacker stole
300,000 credit cards. Some of the people had not had a transaction
in 2-4 years. There really is no need to keep it forever is
my point. This seems to be the mindset: never archive anything
and hold on to all data on users as long as possible. This makes
risk for the user increase. You could burn it to optical disks
and have it stored offsite at a secure facility. Anyway, if it
doesn't exist it is impossible to steal.
> the initial translation of credit card (aka electronic commerce) to
> internet was relatively straight-forward since there was already
> provisions for non-face-to-face MOTO (mail-order/telephone-order)
> transactions ... ref to this effort:
> http://www.garlic.com/~lynn/aadsm5.htm#asrn2
> http://www.garlic.com/~lynn/aadsm5.htm#asrn3
>
> however, because account number is effectively shared-secret, there
> are all kinds of exploits ... not just limited to the internet. As a
> result, the financial standards body developed the X9.59 standard for
> ALL account-based payments (not just limited to internet but can be
> done at point-of-sale also and other types of environments). refs to
> debit implementation
> http://www.garlic.com/~lynn/nacharfi.htm
> http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm
>
> refs: to X9.59 mapping to iso8583 (aka international message standard
> used by both credit and debit networks):
> http://www.garlic.com/~lynn/8583flow.htm
>
> --
> Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/
--
Anne & Lynn Wheeler
>
> Generally you have 60 days to dispute a charge from the time you
> get a statement. So that would imply at least 90 days for the
> business to keep transaction data. Does that data need to be on
> a server connected to the Internet. No. It could be archived
> to an offline server that is a peice of junk but has lots of
> storage capacity. Only a few employees, those that handle disputes
> need access. In the CD Universe case a Russian attacker stole
> 300,000 credit cards. Some of the people had not had a transaction
> in 2-4 years. There really is no need to keep it forever is
> my point. This seems to be the mindset: never archive anything
> and hold on to all data on users as long as possible. This makes
> risk for the user increase. You could burn it to optical disks
> and have it stored offsite at a secure facility. Anyway, if it
> doesn't exist it is impossible to steal.
there are all sorts of things that can be done ... but have
shared-secret account numbers is the fundamental problem ... x9.59
eliminates the account numbers as exploit/fraud objectives
... i.e. the account number no longer can be used in non-authenticated
transactions.
as in the discussion about security proportional to the risk ... the
basic problem is that the degree of risk of account numbers in
unauthenticated transactions bears little or no relationship to the
risk/benefit scenerio at the merchant business i.e. the account number
risk is significantly larger than any amount of merchant business at
risk, and therefor there is no correlation between the amount of
business & revenue that a merchant is doing and the amount of risk &
security associated with the existing account numbers.
There are lots of security things that can be done proportional to the
amount of risk represented by the account number file .... however, in
principle, the amount of business a merchant is doing should be
proportional to the risk the merchant is dealing with ... and therefor
is able to fund/underwrite risk proportional to their
business. However, the account number file tends to far exceed the
risk in the merchant business and bears little or no correlation with
that business
i.e.
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk
Ferrosti
> have
> the money why do you care about the numbers? It is because you want to
> take advantage of impulse buying of your customers. Gosh if I had to
> enter my credit card everytime I made a purchase I would have to
> actually want the product rather than making a snap decision. It is a
> marketing ploy not a security feature. Now that you only have
> outstanding
> accounts in your database, your customers are not at risk for quite
> as long (a couple days versus forever).
>
> Have a well defined period of time to keep the information if no sales
> have occured. If someone has not bought something for a month, purge the
> numbers.
I think this is quite a good idea, but there is one option left. For
sure it is a nice marketing thing and more comfortable for the user to
keep the customers credit card number. As long as the server which
stores the information can´t be compromitted everything is allright.
As soon as some information gets lost or copied you´d be glad not to
work for the company in the security office :-))
But there is one thing u forgot. You only thought about the company
keeping the data, but there is the customer on the other side of the
net sending information. As long as keyboard sniffers are as popular
as they are now I think it is more save to keep all the information on
the server.
BTW I never order using my credit cards number.
Bye, Ferrosti
Norm
>
>
> >
> > Generally you have 60 days to dispute a charge from the time you
> > get a statement. So that would imply at least 90 days for the
> > business to keep transaction data. Does that data need to be on
> > a server connected to the Internet. No. It could be archived
> > to an offline server that is a peice of junk but has lots of
> > storage capacity. Only a few employees, those that handle disputes
> > need access. In the CD Universe case a Russian attacker stole
> > 300,000 credit cards. Some of the people had not had a transaction
> > in 2-4 years. There really is no need to keep it forever is
> > my point. This seems to be the mindset: never archive anything
> > and hold on to all data on users as long as possible. This makes
> > risk for the user increase. You could burn it to optical disks
> > and have it stored offsite at a secure facility. Anyway, if it
> > doesn't exist it is impossible to steal.
>
> there are all sorts of things that can be done ... but have
> shared-secret account numbers is the fundamental problem ... x9.59
> eliminates the account numbers as exploit/fraud objectives
> ... i.e. the account number no longer can be used in non-authenticated
> transactions.
>
Ok, somebody breaks into CD Universe, steals my address, card number,
expiration date, etc. So now with this data are you trying to say
that they cannot now make purchases? The business might be authenticated
so that the credit card company knows that amazon is making the charge
or
thrifty car rental is making the charge. But how does this insure that
I am making the charge?
I think you are missing my point. The credit card number should not be
kept forever. This is why I periodically cancel all credit cards.
Because I don't want to have to worry about the security of all the
people I do business with. If they delete the data and/or archive it
off-line, crackers cannot get to because it doesn't exist. The only
reason they keep these large lists is marketing and impulse buying
reasons. It really serves me little purpose to have buy.com store my
address 10 years from now. If I am constantly doing business with
them then great. But a lot of the time I buy once, because some
site has a much lower price, and never again. Why keep that data
forever? No data should be kept forever.
No amount of buzz words can convince me that e-commerce is any safer
now than it was a few years ago. Look at the whole Code Red incident.
Internet security is pathetic and based on systems that are
fundementally flawed. ~50% of web servers run M$ patch and hope
crap (please send comments on this remark to
mailto:webm...@fuckmicrosoft.com,
I find their responses helarious and need a good laugh). Hey I
think I have a new slogan for M$: patch and pray (instead of plug
and play). They cannot keep Messenger or Hotmail up (yes they
blame Unix as being insecure, ya right, since they use Solaris
a lot at Hotmail.)
> as in the discussion about security proportional to the risk ... the
> basic problem is that the degree of risk of account numbers in
> unauthenticated transactions bears little or no relationship to the
> risk/benefit scenerio at the merchant business i.e. the account number
> risk is significantly larger than any amount of merchant business at
> risk, and therefor there is no correlation between the amount of
> business & revenue that a merchant is doing and the amount of risk &
> security associated with the existing account numbers.
>
I tend to like the "no risk" solutions. Plus think of how much faster
their database box will perform searches if it has less data. Purging
accounts after 90 days (or at least part of the data, you could keep
the user name password combination forever in a special table).
Your arguments are valid. However, we need to go further.
> There are lots of security things that can be done proportional to the
> amount of risk represented by the account number file .... however, in
> principle, the amount of business a merchant is doing should be
> proportional to the risk the merchant is dealing with ... and therefor
> is able to fund/underwrite risk proportional to their
> business. However, the account number file tends to far exceed the
> risk in the merchant business and bears little or no correlation with
> that business
>
Yes my risk in purchasing something online far exceeds the benefit
derived from having another widget. I think the best practice is
to save your money and prevent the early filling of the land fill.
> i.e.
> http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk
>
> --
> Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/
--
Norm
Since I beleive (and I could be wrong) that my security is better than
most web sites, I would rather take my chances typing it in every now
and then. Besides I don't like having my address, phone numbers, etc
sitting on the web waiting for someone to break in. For most people
this is not true. But I also don't store my numbers in a file on my
hard drive. For a consumer that does a lot of business on the web
keep the number, but if they only buy something once every 90+ days
it should get purged.
I agree the next step is client security.
> BTW I never order using my credit cards number.
>
> Bye, Ferrosti
--
Anne & Lynn Wheeler
> I think you are missing my point. The credit card number should not be
> kept forever. This is why I periodically cancel all credit cards.
> Because I don't want to have to worry about the security of all the
> people I do business with. If they delete the data and/or archive it
> off-line, crackers cannot get to because it doesn't exist. The only
> reason they keep these large lists is marketing and impulse buying
> reasons. It really serves me little purpose to have buy.com store my
> address 10 years from now. If I am constantly doing business with
> them then great. But a lot of the time I buy once, because some
> site has a much lower price, and never again. Why keep that data
> forever? No data should be kept forever.
when we were working on the credit card transaction stuff (now frequently referred
to as electronic commerce):
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
we tried to get various security measures specified:
* physical security for the data processing room, motion detecters, guards, etc
* multiple layers of firewalls & packet filtering routers
* actual financial transactions performed on backroom dataprocessing
equipment away from the actual web server
* fbi background checks for all employees
* security audits
* minimum business & security certification levels.
... didn't happen, oh well.
so faced with the prospect that there might someday be 20,000,000 or
so e-commerce servers world-wide and all of them had to be implemented
absolutely perfectly, none of them ever having the slightest security
lapses with either technology or people ... the next choice seemed to
be to eliminate the major source of risk ... i.e. account numbers as a
risk.
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk
i.e. with security supposedly proportional to risk ... if it wasn't
going to be easy to get ubiquitous security actually proportional to
the risk (with real live security audit and certification for all such
sites) ... then the next choice would be to change the associated risk
... aka the x9.59 solution ... which was done in such a way that it
is applicable to ALL account-based transactions (not just credit, and
not just internet).
http://www.garlic.com/~lynn/
the issue isn't just that even simple things could be done to improve
the situation ... the consumer also has no way of telling what sites
have implemented what levels of security (even if some sites were to
implement even partial measures to improve the situation ... the
customer has no way of determining who has implemented what).
some discussion regarding tieing information security implementation
into business risk management and associated business rating
(i.e. analogous to credit risk rating)
http://www.garlic.com/~lynn/aepay3.htm#riskm
http://www.garlic.com/~lynn/aepay3.htm#riskaads
http://www.garlic.com/~lynn/aepay3.htm#x959risk1
http://www.garlic.com/~lynn/aepay3.htm#x959risk2
http://www.garlic.com/~lynn/aepay3.htm#x959risk3
http://www.garlic.com/~lynn/aepay3.htm#x959risk4
longer list of risk & security related discussions
http://www.garlic.com/~lynn/subtopic.html#fraud
general x9.59 financial standard discussions
http://www.garlic.com/~lynn/subtopic.html#privacy
Anne & Lynn Wheeler
>
> the initial translation of credit card (aka electronic commerce) to
> internet was relatively straight-forward since there was already
> provisions for non-face-to-face MOTO (mail-order/telephone-order)
> transactions ... ref to this effort:
the other part of MOTO that we translated to e-commerce was AVS
... address verification transaction; a simple form of authentication,
basically matching name & address with mailing name & address on file;
aka MOTO-transactions want name&address of record for AVS
authentication.
this further (unnecessarily) propogates (more) privacy information.
X9.59 substitutes AVS with digital signature authentication which
eliminates that bit of additional privacy information (in addtion to
eliminating account number as a shared-secret exploit).
Hardgood shipments may still require some name&address (although
softgoods & various other online services wouldn't) and there are a
half-dozen or so hardgood shipment strategies that also eliminates
merchant needing to know name&address for shipping.
now, there is an issue of point-of-sale ... and upgrading the
magstripe cards with the addition of chips and deploying the
readers. some of that is already going on ... but note that the same
x9.59 transaction is defined for debit, credit, internet,
point-of-sale, etc. Part of the driving force for magstripe card
upgrade is that technology advances have been it extremely inexpensive
to counterfeit large numbers of magstripe cards. The addition of a
chip, significantly raises the bar.
misc. refs:
http://www.garlic.com/~lynn/subtopic.html#privacy
http://www.garlic.com/~lynn/subtopic.html#fraud
random specifics
http://www.garlic.com/~lynn/ansiepay.htm#cardsteal Stealing cards easy as Web browsing
http://www.garlic.com/~lynn/ansiepay.htm#breach Security breach raises questions about Internet shopping
http://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping
http://www.garlic.com/~lynn/aepay6.htm#fraud Online Card Fraud Thirty Times That Offline
http://www.garlic.com/~lynn/aepay6.htm#ccfraud latest credit scam puts plastic in peril ... is your credit card being cloned?
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001f.html#35 Security Concerns in the Financial Services Industry
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
http://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card fraud"
Phillip Tompkins
place hard drive in magnitic bin.
Customer data will be secure..
Dude.. nothing is ever secure, you can only do the best you can to keep it
secure.
--
Have you tried ???
rpm -Uvh os2rh71
"jaywhy" <jay...@home.com> wrote in message
news:B7B6B035.1AC4%jay...@home.com...
Ron Alexander
them you did not create that transaction. I have never heard of a reputable
card issuer not reversing the charge.
Most people believe that crap about you being responsible for the first $50.
"Norm" <no...@justhacked.org> wrote in message
news:3B933E43...@justhacked.org...
Ron Alexander
about scanners. You are MANY orders of magnitude more secure on a secure web
server than on your phone.
"Ferrosti" <Ferr...@gmx.de> wrote in message
news:580269a5.01090...@posting.google.com...
Anne & Lynn Wheeler
> Do you ever order over the phone? If you do, you might want to understand
> about scanners. You are MANY orders of magnitude more secure on a secure web
> server than on your phone.
>
issue hasn't been the transactions in flight ... it is the exposure
with web merchants to gain access to the merchant transaction master
file (something that is a little bit harder to obtain with
non-web-based merchants).
misc. refs:
http://www.garlic.com/~lynn/subtopic.html#fraud Risk, Fraud, Exploits
random refs:
http://www.garlic.com/~lynn/aadsm2.htm#keyl2 On leaving the 56-bit key length limitation
http://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
http://www.garlic.com/~lynn/aadsmore.htm#setjava javasoft SET - NO!
http://www.garlic.com/~lynn/ansiepay.htm#breach Security breach raises questions about Internet shopping
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000g.html#25 SSL as model of security
http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
--
Anne & Lynn Wheeler | ly...@garlic.com, http://www.garlic.com/~lynn/
Bernd Eckenfels
> Do you ever order over the phone? If you do, you might want to understand
> about scanners. You are MANY orders of magnitude more secure on a secure web
> server than on your phone.
Umm.. sniffing an internet connection is way more easy than tapping a phone
wire. You just have to start a program, you do not need to get out in the
rain and find the wires.
Greetings
Bernd
Graham H.
they only work with cordless and cellular phones, but it's still much
easier than finding wires. And just as a reference, it's not that hard
to find a wire pair.
Graham
--
|\ ( )
_________|_\_________________________
----- -_-_
-- - -
Gilbert W. Pilz Jr.
> Umm.. sniffing an internet connection is way more easy than tapping a phone
> wire. You just have to start a program, you do not need to get out in the
> rain and find the wires.
Only if you can get into your victims LAN and/or their ISP. Once the
data hits the backbone it gets much harder to sniff . .