Credit Card Numbers become a NULL value after entering

[JBuell]

Upgraded to v6.16 from 5.0.2.6 recently and we are having an issue with credit card numbers randomly becoming NULL values in the database just after entry. The credit card browser via the customer profile shows a blank filed (name, cvv, exp date remain) Anyone else having this issue. Techs tell me developers do not know why this is happening which is concerning. Techs log in to the app server to run an SQL query to convert the NULL values to the intended credit card numbers. 

Anyone else having this issue? Anyone hear any news or info on a fix?

[Atlantic Tactical]

We have the same problem... Here is what tech support told me... when you run the encryption key program every 30 days... when it is finsihed... leave it run for a while before exiting... what happens is that it generates the new key and then starts re-encrypting the values... if you exit out, it will stop where it was and you'll have blanks... we leave it run for about an hour before we close the utility... we have 75K cc cards in the file. Once I did that, most have returned.

I was telling Everest, that it would be nice if their cc purge routine would be a bit smarter... like the ability to filter cards that have expired or cards from customers that haven't purchased in X number of months, and only if there are no open sales orders etc, etc.... fell on deaf years I believe.

[Mike Marshall]

We also had this issue, and have found a few workarounds.

Are you using Payware Connect or another processor?

[Torbett]

Isnt this part of attempt of  PCI compliance rules? You cant keep credit cards numbers on your server anymore. Daily fines can be as high as $25,000 a day per instance plus of course loosing your ability to accept cards.

 

Not keeping thes numbers even encrypted is a mess for us... customers are changing their minds after order palced all the time.

 

Any looked into tokens?

--
--
Email sent to Google Groups: "Everest (Icode/Versata) ERP Users Group" group.
 
- Post: evere...@googlegroups.com
- Unsubscribe: everest-erp...@googlegroups.com
- More options: http://groups.google.com/group/everest-erp?hl=en
---
You received this message because you are subscribed to the Google Groups "Everest (Icode/Versata) ERP Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to everest-erp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

C Torbett Crocker

This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. SupplyDIRECT, Inc. 2550 Collins Springs Dr Suite B, Smyrna, GA 30080, USA, www.supplydirectinc.com

 

 

[Paul]

Everest has advertised payware connect hosted cc where the processing takes place on verifones servers, but I'm pretty sure it's only for the client. Easy enough to add to legacy asp on your own, but I doubt it's possible with dot net unless versata decides to add it. Based on the typos , poor alignment, and cross browser compatibility of dot net versata doesn't give two shits about it.

[Paul]

http://www.verifone.com/products/software/hosted-payment/

[Planet Scott]

No PCI rules still allow you to store the CC number.  Not the CVV.  Ideally using tokenization would be best.  But Everest does not allow use to use any tokenization service.  So you are handcuffed.

 

https://www.pcisecuritystandards.org/documents/pci_ssc_quick_guide.pdf

Page 14

 

from PCI handbook:

Protect Cardholder Data
Cardholder data refers to any information printed, processed, transmitted or stored in any form on a
payment card. Organizations accepting payment cards are expected to protect cardholder data and
to prevent their unauthorized use – whether the data is printed or stored locally, or transmitted over a
public network to a remote server or service provider.
Requirement 3: Protect stored cardholder data
In general, no cardholder data should ever be stored unless it’s necessary to meet the needs of the
business. Sensitive data on the magnetic stripe or chip must never be stored. If your organization
stores PAN, it is crucial to render it unreadable (see 3.4, and table below for guidelines).
3.1 Limit cardholder data storage and retention time to that required for business, legal, and/or
regulatory purposes, as documented in your data retention policy.
3.2 Do not store sensitive authentication data after authorization (even if it is encrypted). See
guidelines in table below.
3.3 Mask PAN when displayed; the first six and last four digits are the maximum number of digits
you may display. Not applicable for authorized people with a legitimate business need to see
the full PAN. Does not supersede stricter requirements in place for displays of cardholder data
such as on a point-of-sale receipt.
3.4 Render PAN, at minimum, unreadable anywhere it is stored – including on portable digital
media, backup media, in logs, and data received from or stored by wireless networks.
Technology solutions for this requirement may include strong one-way hash functions,
truncation, index tokens, securely stored pads, or strong cryptography. (See PCI DSS Glossary for
definition of strong cryptography.)
eNCRyPTIoN PRIMeR
Cryptography uses a mathematical
formula to render plaintext data
unreadable to people without
special knowledge (called a “key”).
Cryptography is applied to stored
data as well as data transmitted
over a network.
Encryption changes plaintext into
ciphertext.
Decryption changes ciphertext
back into plaintext.
Illustration: Wikimedia CommonsThis Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents. 15
3.5 Protect cryptographic keys used for encryption of cardholder data from disclosure and misuse.
3.6 Fully document and implement all appropriate key management processes and procedures for
cryptographic keys used for encryption of cardholder data.
Guidelines for Cardholder Data elements
Data Element Storage
Permitted
Protection
Required
PCI DSS
Req. 3.4
Cardholder Data
Primary Account Number (PAN) Yes Yes Yes
Cardholder Name1 Yes Yes1 No
Service Code1 Yes Yes1 No
Expiration Date1 Yes Yes1 No
Sensitive
Authentication
Data2
Full Magnetic Stripe Data3 No N/A N/A
CAV2 / CVC2 / CVV2 / CID No N/A N/A
PIN / PIN Block No N/A N/A
1 These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS
requirements for general protection of the cardholder data environment. Additionally, other legislation (for exam 

[Torbett]

They sure have changed the rules on PCI then. A year ago they were riping us up. Even made us have a sign in sheet for all visitors etc... real crazy stuff... going into our server on regular basis saying what was not in compliance and time frame to fix... any tweak in our system got them in our stuff... the new non privacy USA.  A 25 year customer and treated us like criminals.

--

--
Email sent to Google Groups: "Everest (Icode/Versata) ERP Users Group" group.
 
- Post: evere...@googlegroups.com
- Unsubscribe: everest-erp...@googlegroups.com
- More options: http://groups.google.com/group/everest-erp?hl=en
---
You received this message because you are subscribed to the Google Groups "Everest (Icode/Versata) ERP Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to everest-erp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Atlantic Tactical]

We were told to run the encryption program again, but, don't close it down even after it says it is finished... because it isn't and when you close it down, it stops were it was and the rest that were not re-encrypted are left as nulls... When I run the utility, I let it run all night long and don't seem to have too many issues after that...

On Thursday, September 5, 2013 12:23:39 PM UTC-4, JBuell wrote: