Changing subject line since not MySQL specific.
Marv:
Regarding storing card numbers online,
Visa and MCs new PCI Standard regulations require
that you can answer YES to all these questions
to be compliant. Just an FYI while you're=20
considering your module:
Requirement 3: Protect stored data
=09
3.1 Is sensitive cardholder data securely disposed of when no longer
needed?
3.2 Is it prohibited to store the full contents of any track from
the magnetic stripe (on the back of the card, in a chip, etc.) in the
database, log files, or point-of-sale products?
3.3 Is it prohibited to store the card-validation code (three-digit
value printed on the signature panel of a card) in the database, log
files, or point-of-sale products?
3.4 Are all but the last four digits of the account number masked
when displaying cardholder data?
3.5 Are account numbers (in databases, logs, files, backup media,
etc.) stored securely- for example, by means of encryption or
truncation?
3.6 Are account numbers sanitized before being logged in the audit
log?
<A HREF ="http://www.usa.visa.com/business/accepting_visa/ops_risk_management/cisp">http://www.usa.visa.com/business/accepting_visa/ops_risk_management/cisp</A>
_merchants.html
Jen
Hostasaurus.Com
Miva Premier Hosting Partner
813.971.8772
[email protected]
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Marvin
Sanders
Sent: Thursday, May 05, 2005 2:01 PM
To: 'Wil Hatfield'; [email protected]
Subject: RE: [m5u] MySQL question
<<All of the big hosts plan to use remote storage.>>
Related question: At one time, we looked into having a module written
that
would store credit card info for customers, but found that it would
violate
our merchant agreements *not* because storage simply isn't allowed (as
many
people have suggested), but rather because if you're going to store that
data it has to be done in a particular way that MM4 couldn't really
accommodate -- something about needing to keep CC data separate from the
rest of the data.
I know I'm being clear as mud, but if you get the gist of what I'm
saying
can you think of any reason an MM5/MySQL setup couldn't be configured to
store CC data securely (in keeping with CC agreements)?
Cheers,
Marv
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Wil
Hatfield
Sent: Thursday, May 05, 2005 9:50 AM
To: William Weiland; [email protected]
Subject: RE: [m5u] MySQL question
Heads up Bill. All of the big hosts plan to use remote storage. Heck
alot of
them do that already. So if you are saying your not writing your modules
to
take full advantage of MySQL I suggest you reconsider.=20
If I am misreading what you are saying then disregard.
Wil Hatfield
HyperConX Customer Care
HyperConX International - <A HREF ="http://www.hyperconx.com">http://www.hyperconx.com</A>
1.800.894.3613 - Toll Free in the US and Canada
Check out the all new Miva Pages:
<A HREF ="http://www.hyperconx.com/miva/">http://www.hyperconx.com/miva/</A>
Premium e-commerce hosting, 24/7 technical support, toll free support
lines
for your convenience, great low cost packages to choose from,
Authorize.Net
Direct retailer, need high-speed connectivity well we have that too.
Everything a business needs to succeed. Host with the Pros and sell like
one
too!
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of William
Weiland
Sent: Thursday, May 05, 2005 6:02 AM
To: [email protected]
Subject: RE: [m5u] MySQL question
In most scenarios, the MM5 would not need the load balancing across
multiple
servers, so the issue would not come up. But when a store decides it
wants
that load balancing, there will be database issues along with the issue
of
needing mirror scripts copies of the modules. Updating module versions
(3rd
party and miva core) will be a headache. It is one thing for the host
to
unzip multiple copies of core mvc files, but what about the new update
wizard. It is going to flow the new module versions to one location.
So
you will have one server updated with new scripts and others not. It
definitely is going to require some sort of technique to put all scripts
on
the single server. If that is done, then it might not be an issue with
the
data either. This is going to be a trial and error experimentation. I
would hope that hosts share their knowledge rather than "trade secret"
these
issues. Film at 11.
--
Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc">http://www.emporiumplus.com/store.mvc</A>
Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
PayPal,
Gift/Wish List, Froogle data feed, Shipping & dozens more Online
Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm">http://www.emporiumplus.com/tk3/v3/doc.htm</A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=3DSPTS =20">http://www.emporiumplus.com/mivamodu...?Screen=3DSPTS =20</A>
|
=20
---- David Hubbard <[email protected]> wrote:=20
> From: William Weiland
> >=20
> > The modules within merchant were written that way because they have=20
> > had a year or two to write them. You know how long we have had=20
> > since Miva settled on how and where the data would be located and=20
> > files named. So the suggested first step was to use the old access=20
> > method for your
> > module's own configuration and concentrate on the mivasql methods=20
> > for accessing store data (products/cats/orders/etc). The next step,
> > which will take considerable time if the module has a lot of=20
> > configuration databases, will be to convert the module's internal=20
> > data to mivasql calls.
>=20
> Ah, I didn't realize that was even an option. That definitely would=20
> raise some issues with load balancing; those considering it would need
> to ensure that the modules they are using have been written using the=20
> SQL method so no surprises result.
>=20
> David
>=20
>=20
Comment