106
As per PCI, the first 6 (BIN) and the last 4 can be shown, others should be masked:
From an official 2008 PDF: PCI Data Storage Do’s and Don’ts:
Never store the personal identification number (PIN) or PIN Block. Be
sure to mask PAN whenever it is displayed. The first six and last four
digits are the maximum number of digits that may be displayed.
...
105
At our office with connect to the internet through our cable modem
provided to us by Spectrum Business.
Our Treasurer uses a verifone vx520 card reader to process credit card
payments. It connects via ethernet. We don't store credit card data.
It sounds like you fall under SAQ B-IP (and you will be amused that the mnemonic is that "SAQ B-for-Brick-...
61
Cardholder name, 4 last digits of CC number and its expiration date are all NOT sensitive data. The cardholder name and expiration date only require protection if you are storing them with the full primary account number, not the truncated 4 digit number.
If you are storing, processing, or transmitting cardholder data then you must meet all of the other PCI ...
52
"Best" is rather subjective - it depends on your requirements. That said, I'll give you a general overview of each mode.
ECB - Electronic Code Book. This mode is the simplest, and transforms each block separately. It just needs a key and some data, with no added extras. Unfortunately it sucks - for a start, identical plaintext blocks get encrypted into ...
50
TLS 1.0 when properly configured has no known security vulnerabilities. Newer protocols are better designed and better address the potential for new vulnerabilities. So that's why
I wouldn't personally recommend disabling TLS 1.0, primarily because IE 7-10 don't support TLS 1.1 out of the box. In January 2020, IE10 has gone EOL, so I expect it's likely ...
38
Looks like you are hashing card details along with the CVV. That's bad, very bad. Don't do that. Ever. And there's no way to do the wrong thing on the right way.
"A man may do a right thing in a wrong way; but he cannot do a wrong thing in a right way. For there is no right way of doing wrong."src
There are very cheap hash cracking rigs around the world ...
34
Ivan, this is an absolutely huge topic. And you have a bunch of questions here. I'll try to help but this will likely be closed as too broad.
I'm planning on making a case to the higher-ups that the liabilities of storing CC information outweigh the conveniences of not having to re-ask the customer for numbers, but I know I'm going to get asked how ...
33
Storing card numbers means you must comply with the requirements of PCI-DSS, or you risk fines and breach of your merchant account contract. PCI-DSS has an enormous set of requirements - some sensible, some onerous, some of questionable usefulness - and the cost of complying with it, and certifying that you've complied with it, can be very high.
Download ...
33
Yes, this is wrong, and here is why. As you mentioned, PCI-DSS requires that communication containing sensitive data be handled over a secure channel. As a part of this process, certificate validation ensures that the certificate in question is in good order and belongs to the party that you intend to talk to. If you do not validate the certificate, the ...
33
Some of the non DBA workers (DEV, Fraud, analysts ... ) in my organization need direct access to databases to write their own queries.
...
PCI DSS requirement 8.7 stats "Only database administrators have the ability to directly access or query databases"
The usual way of handling this is to create a scrubbed version of the database, with PAN data and ...
32
Since you are physically handling cards, and sending that card data across a network to your card processor, you do need to secure your network. Besides just being compliant in order to get auditors off your case, if someone sneaks a program into your network, it might be able to eavesdrop on the rest of the network and steal that card data.
Based on your ...
29
Note : not a QSA, but I do have some PCI experience.
There is nothing in PCI about storage of source code - there are requirements about change management, which github would help with, but nothing about where source code should be or any requirements to keep source code private (it allows use of open source, after all). Given a private repo and assuming ...
28
"None of us are security experts" and "I wouldn't feel comfortable with a company storing my credit card information in this manner" are completely valid arguments. From a technical perspective (on the merits), they ought to end the discussion. But if you're arguing with folks who are not security experts, they may not be in a position to recognize good ...
25
There are several reasons why wildcard certificates are bad:
The same private key has to go on the systems that have different security levels, so your key is only as good as your least-protected system. Giving it out to third-party vendors is a really bad idea, as then it completely escapes your control.
You have to keep meticulous records that show ...
24
Typically, it's just the last 4 that are shown to the customer, sometimes the first 6.
From the PCI DSS 3.4 Standards
Never store the personal identification number (PIN) or PIN Block. Be
sure to mask PAN whenever it is displayed. The first six and last four
digits are the maximum number of digits that may be displayed. This
requirement does not ...
24
TLDR: DON'T secure your network. Get a modern card terminal with P2PE (Point to Point Encryption) and acquirer who supports it - e.g. new-market products like Square or PayPal Here, which cost less than you think.
This transfers PCI-DSS responsibility away from you and to these billion dollar financial companies who are well equipped to handle it ...
21
First, IANAL. Secondly, this is entirely dependant on your local laws and regulations.
PCI-DSS is a guideline, but adherence to the guideline may be a requirement as part of certain laws. I'm not aware of any countries that do this, but in such a case you could be prosecuted if you violate a law that makes PCI-DSS adherence mandatory.
The more common case ...
21
Short version:
TLS 1.0 is on notice as of PCI DSS 3.1
TrustWave is carping, but you may be able to continue using TLS 1.0 if it's not a "new application"
Long version:
PCI DSS 3.1 was released two weeks ago, on 14 April 2015. It lays out that
SSL and early TLS are not considered strong cryptography and cannot be
used as a security control after ...
19
Just remember that sensitive does not mean secret. The card number is "sensitive" because it can be used to initiate financial transactions, but it is not secret. Only the PIN code is.
Earlier, the full number was written down on the receipt, like the full account number is written on a check. As online businesses use only VISA card numbers without ...
18
Generally, the most conservative answer comes in the form of something easily understood, and approachable by the general populous.
Ignoring the hyperbole of that kind of response, there are two things you must really take into account.
What logs should I retain
How long should I retain said logs
Log Retention
The answer to 2 is simple and well defined ...
17
HTTPS and SFTP when used properly are equally safe. The underlying encryption algorithms in practice are both functionally equivalent -- neither can be broken in practice by directly attacking the cryptographic protocols.
However, in practice with non-tech savvy user, HTTPS is slightly weaker in my opinion.
There are attacks on both that can be launched ...
15
Since PCI stands for Payment Card Industry the short answer is no.
However that information is sensitive so you should treat it like any other sensitive data and store and transmit it in a secure, encrypted form.
PCI is a great baseline for dealing with any secure data so it certainly wouldn't hurt to treat it the same.
15
Technically, according to PCI SSC you can hold onto CVV and other sensitive authentication data until authorization has occurred. In other words the restriction on storing sensitive authentication data applies to post authentication/processing storage. Here is a document from the PCI SSC about data storage requirments. See the "Technical Guidelines for PCI ...
15
Storing CVV is not allowed:
There are a few things to consider:
You assume booking.com is storing CVV
You're assuming a CVV is needed to process a transaction.
On 1) - there can be no way to confirm whether booking.com, Expedia are storing unless you work there. They would have to answer to a QSA. Now, as far as the CVV that is stored, that is CVV2 ...
14
Why even store it in a MySQL database when you can be using Authorize.Net's Customer Information Manager API and taking PCI compliance and security issues right out of your hands completely and letting them do all of the heaving lifting for you? CIM let's you create customer payment profiles by storing the customer's credit card information on their end and ...
14
It is, of course, always wisest to accept the judgements of your QSA when making judgement calls, however during your own in-house compliance work I recommend checking out the Navigating PCI-DSS: Understanding the Intent of the Requirements document whenever confused by a requirement.
Looking at page 32 of that document we see the following write up ...
14
Can you pass PCI DSS without installing antivirus on all linux
workstations and servers?
Yes, absolutely.
Can you pass PCI DSS without installing additional firewalls or
configuring iptables on all linux workstations?
Yes, absolutely.
In both cases the PCI-DSS contains statements that allow you to make reasonable arguments as to the applicability (...
13
So basically what the requirement is saying is that you need to assign one primary function per server.
The server you've described sounds like it runs a few applications for production users to utilize. This would be classified as an "application" server. However, you've also mentioned that there are multiple applications on that server, some touch the CDE ...
13
I also recommend disabling TLS 1.0 if possible and supporting the most modern cryptography and cipher suites your web servers can handle.
TLS 1.0 is vulnerable in many implementations to a couple well-known attacks such as BEAST and POODLE. There's also some crypto issues in TLS 1.0, such as cryptograhpic initialization vectors (IV's) being predictable in ...
Only top voted, non community-wiki answers of a minimum length are eligible
