PCI Compliance & Authorize.net Payment module
David Marcin
Bruce Kroeze
> Hi Bruce,
> Thanks for your very informative post. Splitting this thread so as not to
> hijack the discussion about certification. Is there anywhere that explains
> PCI futher in terms normal people can understand?
No, I really don't know of a good explanation. It takes some reading
and thought. Argh.
> I ask having just finished building a Satchmo site for a client, and I'm
> worried about the Authorize.net integration. They have their own SSL
> certificate, but are very small, and having any more than one shared hosting
> server doesn't really make much financial sense. My questions are:
> - Is it possible to use the Authorize.net module in a compliant way?
Yes, for the moment. Just do not choose the option to store CC# in
the database.
> - CC#s are not supposed to be stored, but they appear in the database as
> "encrypted". Is that problematic? Couldn't they be unencrypted if someone
> managed to steal the key? What is the key?
They aren't saved unless you choose to do so, which is defaulted to
false. The value saved is a key to the cache which has the actual CC#
and which is deleted in a few minutes. The key is "ABCD" where A=last
4 digits of CC#, B=expire month, C=Expire Year, D=ID of payment
object.
AFAIK, this should be completely PCI compliant.
> If it's just not possible to do the right thing, any recommendations for
> alternative solutions? The client really likes how users aren't redirected
> to another site to make their purchases with Satchmo & Authorize.net, so if
> possible any solution would maintain that feature.
Bursar will maintain this approach. However, until we formally apply
for PSA-DSS status, you will be responsible for any PCI compliance
audits.
> Finally, while they do a third party redirect, using the Paypal and Google
> Checkout modules seem like they would sidestep all the issues of PCI
> compliance, do I understand that correctly?
That is correct, those solutions skip PCI requirements.
--
Bruce Kroeze
http://www.ecomsmith.com
It's time to hammer your site into shape.
David Marcin
Bruce Kroeze
> Thanks Bruce,
> One more question. My client can't run long running processes, so no
> memcached and django via fcgi. If I don't want the CC# written to disk, it
> seems that I need to use locmem, but there is a warning that says it "will
> not work properly at all in production." What exactly does that mean? The
> site is low traffic enough that it doesn't really matter if things are
> cached (when/if it matters, I'll get them to upgrade to a VPS), I just need
> for the CC# to be held long enough for the authorize.net module to work.
Locmem won't work because it isn't thread-aware. Each thread would
have its own cache, and so you'd get cache-misses, AKA Mysteriously
Missing Information, if you saved the CC# to memory on one thread and
tried to read it with another.
I'm not sure what to suggest to use as a cache if you can't use
memcached. Every other option would involve writing to disk in some
way. It is encrypted, so you could just use filecache, and then have
some cron job which clears out files older than CACHE_TIMEOUT seconds
(Or maybe filecache does that on its own, I don't know). I'm not sure
how acceptable that is to PCI standards.
Sounds like a bad server to run a store on, to be honest.