Being a responsible corporate citizen and member of the local community is at the core of Control Gap’s daily operations. We believe in making work a rewarding experience by incorporating fun team events within our corporate culture, and supporting cause-related and local organizations.

Blog

WP_Query Object ( [query] => Array ( [post_type] => post [post_status] => publish [cat] => 14, 134, 1 [orderby] => date [order] => desc [posts_per_page] => 3 [paged] => 1 [ignore_sticky_posts] => 1 ) [query_vars] => Array ( [post_type] => post [post_status] => publish [cat] => 14 [orderby] => date [order] => DESC [posts_per_page] => 3 [paged] => 1 [ignore_sticky_posts] => 1 [error] => [m] => [p] => 0 [post_parent] => [subpost] => [subpost_id] => [attachment] => [attachment_id] => 0 [name] => [static] => [pagename] => [page_id] => 0 [second] => [minute] => [hour] => [day] => 0 [monthnum] => 0 [year] => 0 [w] => 0 [category_name] => charity [tag] => [tag_id] => [author] => [author_name] => [feed] => [tb] => [meta_key] => [meta_value] => [preview] => [s] => [sentence] => [title] => [fields] => [menu_order] => [embed] => [category__in] => Array ( ) [category__not_in] => Array ( ) [category__and] => Array ( ) [post__in] => Array ( ) [post__not_in] => Array ( ) [post_name__in] => Array ( ) [tag__in] => Array ( ) [tag__not_in] => Array ( ) [tag__and] => Array ( ) [tag_slug__in] => Array ( ) [tag_slug__and] => Array ( ) [post_parent__in] => Array ( ) [post_parent__not_in] => Array ( ) [author__in] => Array ( ) [author__not_in] => Array ( ) [update_post_term_cache] => 1 [suppress_filters] => [cache_results] => 1 [lazy_load_term_meta] => 1 [update_post_meta_cache] => 1 [nopaging] => [comments_per_page] => 50 [no_found_rows] => ) [tax_query] => WP_Tax_Query Object ( [queries] => Array ( [0] => Array ( [taxonomy] => category [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id [operator] => IN [include_children] => 1 ) ) [relation] => AND [table_aliases:protected] => Array ( [0] => wpcm_term_relationships ) [queried_terms] => Array ( [category] => Array ( [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id ) ) [primary_table] => wpcm_posts [primary_id_column] => ID ) [meta_query] => WP_Meta_Query Object ( [queries] => Array ( ) [relation] => [meta_table] => [meta_id_column] => [primary_table] => [primary_id_column] => [table_aliases:protected] => Array ( ) [clauses:protected] => Array ( ) [has_or_relation:protected] => ) [date_query] => [request] => SELECT SQL_CALC_FOUND_ROWS wpcm_posts.ID FROM wpcm_posts LEFT JOIN wpcm_term_relationships ON (wpcm_posts.ID = wpcm_term_relationships.object_id) WHERE 1=1 AND ( wpcm_term_relationships.term_taxonomy_id IN (1,14,134) ) AND wpcm_posts.post_type = 'post' AND ((wpcm_posts.post_status = 'publish')) GROUP BY wpcm_posts.ID ORDER BY wpcm_posts.menu_order, wpcm_posts.post_date DESC LIMIT 0, 3 [posts] => Array ( [0] => WP_Post Object ( [ID] => 1678 [post_author] => 2 [post_date] => 2019-01-28 14:49:25 [post_date_gmt] => 2019-01-28 14:49:25 [post_content] => Big changes are coming to payment security in 2019. PCI is launching a grand experiment in payment security - Software PIN on COTS (SPoC) - a subset of "PIN-on-glass". SPoC is intended to make payments using devices like phones and tablets both easy and secure. The approach is both interesting and a departure from previous payment security standards. SPoC has generated a lot market interest but will face challenges with complexity and potentially with acceptance.  This article looks at what SPoC is, its new security model, and some of the challenges. We also present a timeline on the standard including known mandates. The PCI Council which oversees 10 different standards and a dozen programs is in the process of updating and rolling out standards that will have a big impact on payment security.  In addition to SPoC, 2019 will see a new software security standard & framework to replace PA-DSS, improvements to the 3DS standard to benefit card-not-present & mobile payments, a new Qualified PIN Assessor (QPA) program, and a Contact-less payments on COTS standard.

What is PIN- on-Glass and Software-PIN-on-COTS?

Simply put, PIN-on-Glass is a general payments use case where a customer PIN is entered on the merchant's touch screen.  This includes both certified payment terminals and also non-certified solutions.  Software PIN on COTS (Commercial-Off-The-Shelf) is a use case where the customer PIN is entered into a commercial device like a phone, or tablet while the card is processed via small secure device.

What concerns surround PIN- on-Glass and SPoC?

There are two main concerns that arise from the new form factor and the new architecture these are:
  1. Security - Regardless of the input mechanism, how does the device secure your PIN?
  2. Accessibility - With only a touch screen, what issues arise with visually impaired customers, and accessibility laws?
From a security perspective, PTS approved touch screen payment terminals already exist and are there are no additional security complications.  Securing a PIN entered into any general purpose computing device is challenging to say the least. At this time, there are exactly zero certified SPoC solutions!  There are however, many uncertified solutions - many of which are insecure. From an accessibility perspective, with any PIN on Glass or SPoC solution merchants need to do their due diligence as they may find themselves on the wrong end of a legal action if they cannot accommodate customers with disabilities. We will discuss all of these later in the article.

How is SPoC Secure?

SPoC is, at least in part, a response to initiatives by companies like Square. The existing PCI software standard, PA-DSS, simply didn't and couldn't support this use case. In fact, payment applications for COTS devices are specifically not permitted under PA-DSS. The only approved mobile security model for PCI prior to SPoC was to use a mobile POS with a P2PE approved terminal solution rendering the COTS mPOS out of scope. SPoC is a radical departure and required completely rethinking the approach to software security. The basic idea behind SPoC is to reduce risk by splitting up sensitive data, actively monitor the operation of the solution, and react in real-time. By supporting EMV, SPoC also rejects the use of static authentication data (i.e. magnetic stripe). The approach buys security at the cost of additional  monitoring and attestation complexity. SPoC solutions consist of several parts:
  • A PTS approved Secure Card Reader PIN (SCRP) device
  • An approved SPoC Solution
    • A PIN Cardholder Verification Method (CVM) application
    • Back-end decryption, and attestation monitoring service
  •  A COTS device such as a phone or tablet
  • A PCI DSS compliant back-end processing environment hosting the SPoC back-end
The SCRP connects to the COTS device and provides:
  • EMV contact card reader with no magnet stripe or manual entry capability
  • A method of establishing PIN exchange keys with the PIN CVM application
  • Decryption of SCRP PIN data received from application
  • Encryption of the payment card data (from SCRP) and PIN (from CVM) using a PTS SRED approved mechanism for transmission to the back-end
The PIN CVM application running inside the COTS device provides:
  • Active monitoring of the COTS device's security state for signs of software tampering, debuggers, rooting & jail-breaking
  • Reporting and attestation of the COTS device security state to the back-end
  • PIN entry, encryption, and transport to the SCRP
  • Relay of SRED encrypted data to the back-end from the SCRP
The back-end provides:
  • Monitoring of COTS device status and attestations, and real-time response/reactions
  • Decryption of the SPoC request
  • Transaction processing
SPoC is a buying tool for merchants and consumers. In addition to using approved PTS SCRP devices, solution providers will need to validate the PIM CVM and backend software with an approved SPoC lab. The solution provider's back-end environment will also be validated  against the enhanced PCI DSS requirements known as DESV. The following diagram from the PCI Council illustrates the architecture:

Accessibility and the Law

Many jurisdictions, including the US, Canada, and the EU, have laws aimed at providing accessibility for disabled individuals. The scope and breadth of these laws varies. While a merchant using SPoC "line-busters" backed up by traditional PIN pads should have no problems, a merchant offering payment only via SPoC could be at risk under many of these laws as there have been a number of lawsuits filed in the US over the use of touch screens and apps. Learn more:

Consumer Trust and Adoption

Regardless of demand, a percentage of the population may simply refuse to trust these solutions.  This is particularly true in places that have had active "Protect your PIN" awareness programs. Buy-in from other payment networks could be an important factor.  Just because the major card brands are on-board doesn't mean that other payment networks will be. The Canadian market is a good example of where PINs are more strongly associated with the major banks, trust companies, credit unions,  and Interac, the national ATM and debit network, which took an early lead in promoting EMV and contactless payments than brands like Visa and MasterCard.  The Canadian experience with PIN based magnetic stripe credit card payments has been almost non-existent.  Canadians are very comfortable with using PINs for payment which may help adoption. However, the success of SPoC in Canada will be heavily influenced by  whether or not Interac buys into SPoC and how protective Canadian consumers feel about their PINs. It is also unclear if recent trends in data breaches will dim enthusiasm for this type of solution.

Hacked COTS devices?

SPoC is designed with defense in depth in mind.
  • The attestation and monitoring components are designed to detect and prevent the use of compromised COTS devices and PIN CVM applications.
  • Segregating the PIN and card data is designed to ensure that a successful compromise of the COTS/CVM could expose only the PIN
  • The SCRP design ensures that neither plain-text card data nor decryption keys are available to the COTS device.
  • By using only EMV cards, a criminal couldn't clone your card and would need to steal it.
One of the more radical parts of SPoC is the PIN CVM monitoring.  The ability and effectiveness of active tamper detection mechanisms designed to ensure that phones and tablets will not be run jail-broken or with debuggers remains an open question.

Phantom Terminals and Non-approved Solutions

In order for a criminal to get both your card data and PIN, they would need to compromise or replace both the SCRP device and the PIN CVM application. The use of fake or non-compliant card readers and PIN CVM applications presents the largest risk to consumers using SPoC. A number of existing non-certified COTS card readers are known to be insecure. Recent tests of Bluetooth enabled payment devices used by Square, PayPal, Zettle, and SumUp finds lots of vulnerabilities https://www.forbes.com/sites/thomasbrewster/2018/08/09/these-bluetooth-hacks-can-steal-your-credit-card-pin/ By limiting SPoC to EMV only and eliminating the use of static authentication data (i.e. magnetic stripe) the risk should be reduced. Consumers will be hard pressed to identify a legitimate SPoC device.  The exclusion of magnetic stripe readers (MSR) provides a a teachable point as the presence of an MSR should raise a huge red-flag that the device is not certified. However, a proposal under consideration to allow pin-less MSR on SPoC may jeopardize this important clue.

SPoC Mandates and Un-certified Solutions

The PCI Council does not set compliance deadlines as these are left to the individual card brands. For instance, there are no requirements within PCI DSS to use certified SPoC solutions. However, without them the heavy burden of compliance proof will fall to the merchant. Visa has announced a mandate to sunset all non-approved SPoC solutions:
PCI Software-based PIN Entry on COTS Device Standard and Program Published REGIONS: US, AP, Canada, CEMEA, LAC, Europe 26 JUL 2018 The Payment Card Industry Security Standards Council (PCI SSC) has published a standard for protecting PIN-based transactions on commercial off-the-shelf (COTS) devices. Merchants accepting PIN-based transactions via COTS devices must use or transition to a PCI-validated software-based PIN entry on COTS solution by 31 July 2019.
Source: https://usa.visa.com/support/merchant/library/visa-merchant-business-news-digest.html Realistically, implementing new payment systems at acquirers and merchants can take months. With no available certified solutions and only seven months to the sunset date, the deadline seems unrealistic.

SPoC and PIN-less Magnetic Stripe?

In the original release of the standard, MSRs were completely excluded. Last week the PCI Council announced that it is considering some form of transitional support for non-PIN magnetic stripe transactions. A 90-day feedback cycle will begin on this shortly. For more information see the announcements for SPoC and Contactless in 2019 https://blog.pcisecuritystandards.org/pci-spoc-and-contactless-standards-what-to-expect-in-2019/

Conclusion

Innovation and security frequently seem at odds. Tension between the promise of bright shiny new tools, and the rigor needed to ensure they're secure seems constant. Easier, faster, and more powerful things can be exploited by those with both good intentions and bad. Over the last decade payment software has been changing far more rapidly than the approved security framework increasing the tension. PCI SPoC is a radical departure from PA-DSS. SPoC represents a new approach and an attempt to strike a new balance between payment innovation and security.

Learn More

PCI Documents and Articles

The following is a list of official PCI SPoC resources: Related articles

SPoC Program Timeline

This is a list of key events in the development of SPoC:

Square and Mobile PIN

[post_title] => PCI SPoC (PIN on COTS) - Grand Experiment in Mobile Payments [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-spoc-pin-on-cots-grand-experiment-in-mobile-payments [to_ping] => [pinged] => [post_modified] => 2019-01-28 14:49:27 [post_modified_gmt] => 2019-01-28 14:49:27 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1678 [menu_order] => 15 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1877 [post_author] => 2 [post_date] => 2018-12-05 12:40:40 [post_date_gmt] => 2018-12-05 12:40:40 [post_content] => Payment card breaches concern customers and businesses alike. A recent epidemic of e-commerce breaches is focusing attention on what makes a website more or less secure than others. The old advice of looking for the “security lock” and the “green location bar” are simply not-adequate anymore. While fully evaluating the security of an e-commerce site is a bit technical and involved, we wanted to provide a simpler resource to help people understand the risks. It isn’t uncommon for a merchant’s compliance department, project manager, or system owner to not know the details of their website. Rather than asking the web developer/maintainer, our idea was to present a simpler procedure that could be quickly used by anyone, even a curious consumer. This method doesn’t require sophisticated security tools or skills, just your browser and a little patience.

Why are "Locks" and "Bars" not enough?

Much of the standard advice on secure shopping focuses on knowing your merchant (good advice) and external technical indicators like "locks" and "bars" which aren't enough.

Under-the-covers, many e-commerce websites are insecure

To understand why "locks" and "bars" aren't enough, it necessary to look beneath the covers at how most e-commerce websites are built. Merchants want to provide their customers with a rich, full-featured, easy-to-use website and a great shopping experience. They also want to be able to optimize their website using sophisticated analytics and tracking tools. Payment processing is typically a tiny portion of the website commonly implemented a form that accepts card data and directly posts it back to the merchant's payment processor. A typical e-commerce website embeds third-party scripts from potentially dozens of websites. Every script on the page has visibility into that form. Every third-party website and every change made to them can potentially impact the security of the website and your card data.  This is a key selling point for a number of legitimate tracking and web replay software. However, many of these have been shown to have security problems. It's also exploited by criminals. Yet many website developers are either unaware or unconcerned with this risk and aren't addressing it. As a direct consequence of this development style and lack of focus on supply-chain security a number of organized criminal gangs have been using this method to actively exploit e-commerce sites. To date over 100,000 sites have been compromised including Newegg, British Airways, and Ticket Master. These attacks are collectively known as "Magecart". For more information on Magecart and the problems with Web Replay software see "Learn More About E-Commerce Insecurity" at the end of this article. One of the best ways to defend against these attacks and errors is to use IFRAMEs rather that direct-post forms.  The IFRAME will effectively sand-box the card entry to the processors site. And while it won't eliminate all risks, it will provide a significant security boost. Alternatively, a full redirection to the payment processors website will provide a similar defense.

Which types of payment sites are the most secure?

The questions you want to answer for your e-commerce site are,:
  • Which of the following scenarios apply
  • How secure is the handling of the payment card?
  • What is the risk?
 
Malicious URL Merchant URL Acquirer or Payment Gateway URL
How secure is this method? This site is compromised. Leave immediately. Less secure More secure
How does this method work? The merchant's website is manipulated by malicious individuals to forward your credit card information to criminals. Criminals can be quite creative when stealing from you. They may do things like adding code to the merchant website, or to one of the script sites used by the merchant. They may make a convincing looking clone of the merchant's site. The merchant website either directly receives your credit card information or makes the payment form that collects your credit card info.Your credit card info is then forwarded to either (1) the merchant bank (also called the acquirer), or (2) a payment gateway. This method is vulnerable to attack because there is a much higher chance of the merchant's systems or its payment form codes being compromised by criminals. Effort required by the merchant to secure this type of web page is high. This relies on a concept called IFRAME (inline frame) provided by the acquirer or payment gateway.The IFRAME provides a 'sandbox' isolating environment between the merchant website and the 'frame' where the credit card info is entered.In this method, the credit card info is not easily accessed or exploited by malicious individuals. The acquirer or payment gateway is required to be PCI DSS compliant. Note: All URLs should start with "https://".
 

How would you check the security of a website’s payment card input?

This process allows you to look through the website’s code to see how and where they are using IFRAMEs to process payment card data. The procedure is simple and will take you directly to the code we want to look at. Firstly, once you land on the payment page, press [F12] on your keyboard to display the web code for the page. The code will be in either the Elements tab (Google Chrome and Microsoft Edge) or the Inspector tab (Mozilla Firefox). Click on each image below to enlarge them and view in greater detail.

1. Right click on the credit card number box and select Inspect Element

Click to View Full Size Image

2. Your browser will display something like this

Click to View Full Size Image

3. Search up and down the code in the Inspector field, until you locate the IFRAME

Ensure when you hover your mouse over the piece of IFRAME code, it reflects the credit card number box. Then your IFRAME should have the following:
  • An IFRAME tag with a source to another encrypted website, such as <iframe src = ”https://...” . And
  • The source web site name is coming from any of the acquirer or payment gateway domains listed below. 
Click to View Full Size Image

4. If you cannot find the IFRAME treat the site as less secure

At this point, if you haven't located the payment IFRAME or you are uncertain you should treat the site as less secure. While a detailed deep dive into the technicalities is beyond the scope of this article, if you are a merchant compliance officer, project manager, or system owner and have reached this point you should get a more in-depth analysis from someone skilled in e-commerce security.

List of Canadian Acquirers & Payment Gateways

The following is a partial list of acquirers and processors that provide IFRAME payment page support in Canada.
  • Caisse Populaire Desjardins (bambora.com or beanstream.com)
  • Own (Eigev.com)
  • Global Payments (gtpaysecure.net)
  • Moneris (moneris.com)
  • PayPal (paypal.com)
  • Paysafe (paysafe.com )
  • TD Merchant Solutions  (bambora.com or beanstream.com)
Note  this is not a complete list and there may be other compliant IFRAME payment page providers.

Decision Flow

Based on what you find you should be able to answer the following:    

Sample Merchant Web Pages

Payment IFRAME example 1

This web site uses an IFRAME to redirect to Paysafe's payment gateway.    

Payment IFRAME example 2 – IFRAME URL to acquirer Moneris

This web site uses an IFRAME to redirect to Moneris' payment gateway.  

Other (non-IFRAME) payment example

This web site uses a web form to collect and process payments.

Non-payment IFRAME example

This web page is using an IFRAME to support web tracking and advertising.

Learn More About E-Commerce Insecurity

The following articles illustrate the security problems faced by many e-commerce websites:

[post_title] => How can I tell if the site I shop from is secure? [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => how-can-i-tell-if-the-site-i-shop-from-is-secure [to_ping] => [pinged] => [post_modified] => 2018-12-06 20:45:05 [post_modified_gmt] => 2018-12-06 20:45:05 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1877 [menu_order] => 24 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 1895 [post_author] => 2 [post_date] => 2018-11-07 05:29:57 [post_date_gmt] => 2018-11-07 05:29:57 [post_content] => To accept credit cards in Canada, businesses need to be PCI compliant. Becoming PCI compliant can be difficult in the first place and keeping up with the changes even more so. In May 2018 the Payment Card Industry (PCI) Security Standards Council (formed to regulate security for the payment card industry) released an updated list of compliance requirements known as the PCI Data Security Standard (DSS) v3.2.1. Let us guide you through these new requirements. We found hundreds of wording changes, most of them innocuous and helpful clarifications, however, a small number of these changes will require some attention in order to maintain compliance after December 2018. This article focuses on changes to the DSS standard.  There were also significant changes to the reporting template which we introduce here and will report on more fully in a follow-up article. Continue reading for everything you need to know about PCI DSS v3.2.1 or contact us now and let us guide you through PCI Compliance.

What Are the Largest Impacts of PCI DSS v3.2.1?

The Changes Amount to Almost Nothing, Except E-Commerce Web Redirection Servers, Reporting Instructions

The changes in DSS 3.2.1 are mostly administrative clarifications, minor fixes, and clean-up of now-expired future-dated requirements. There were hundreds of wording changes, 4 numbering changes, and 3 testing procedures removed. On the surface, these amount to virtually no impact to customer compliance effort. The largest impacts we identified in PCI DSS 3.2.1 are actually not due to changes in the DSS itself but the interpretation of the intent. The changes are most evident in the PCI Self-Assessment Questionnaire A (SAQ-A). Whether an entity is completing an SAQ or a Report on Compliance, e-commerce web redirection servers that utilize iframe or Full URL redirection are now subject to increased requirements, now adding requirement patch management (DSS 6.2) to these system components. This slight increase in compliance footprint size may seem small, and for many organizations doing the right thing it won't be a problem. However, since these changes are quietly buried in the SAQ documents and are not part of the announced DSS changes, we anticipate that this seemingly tiny change will catch many service providers and merchants by surprise and will result in compliance validation delays. Another surprise, is there are significant changes in the reporting instructions that will affect organizations undergoing "level 1" onsite assessments.

What Is the Difference Between PCI DSS v3.2 and PCI DSS v3.2.1?

In addition to the hundreds of wording changes, 4 numbering changes, and 3 testing procedures removed, there were:

19 Total Discrete Change Clusters

  • 19 of these changes have an impact rating of None. These changes have a negligible impact on compliance and help to improve clarity and understanding on intent.
  • 0 of these changes have an impact rating of Low. These changes have a low impact on compliance and are a new incremental change that potentially alter compliance efforts.
  • 0 of these changes have an impact rating of High. These changes have a high impact on compliance and are typically a new requirement or involve potentially significant effort to achieve or sustain compliance.

Zero Evolving (New or Changed) Requirements

  • There are no new or changed “evolving” requirements, which is good news.

Change Analysis - the DSS Standard

There are several other significant differences between PCI DSS V3.2 and PCI DSS V3.2.1. We have prepared a quick overview of the changes in our Change Analysis Brief. We have also prepared a Before & After Redline View if you would like to see every word that changed.

Change Analysis - Report on Compliance Templates (coming soon)

Given the relatively minor nature of this update we were not expecting a lot a changes to the Reporting Templates.  Reporting Templates are mandatory instructions for QSA's working with organizations considered "Level 1's" that must undergo onsite assessments and complete Reports on Compliance. We found there is an increased emphasis on the specifics required in the answers. While we don't believe the intent of the instructions have changed, some organizations may find that RoC's will require additional time and effort to satisfy these changes.

References:

Becoming PCI Compliant can be difficult, so why not let Control Gap guide you. We are the largest dedicated PCI compliance company in Canada. Contact us today and learn more about how we can help you: Get PCI Compliant. Stay PCI Compliant.   [post_title] => PCI DSS v3.2.1 - What You Need to Know to Stay PCI Compliant [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-dss-v3-2-1-what-you-need-to-know-to-stay-pci-compliant [to_ping] => [pinged] => [post_modified] => 2018-11-07 05:29:57 [post_modified_gmt] => 2018-11-07 05:29:57 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1895 [menu_order] => 29 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 3 [current_post] => -1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 1678 [post_author] => 2 [post_date] => 2019-01-28 14:49:25 [post_date_gmt] => 2019-01-28 14:49:25 [post_content] => Big changes are coming to payment security in 2019. PCI is launching a grand experiment in payment security - Software PIN on COTS (SPoC) - a subset of "PIN-on-glass". SPoC is intended to make payments using devices like phones and tablets both easy and secure. The approach is both interesting and a departure from previous payment security standards. SPoC has generated a lot market interest but will face challenges with complexity and potentially with acceptance.  This article looks at what SPoC is, its new security model, and some of the challenges. We also present a timeline on the standard including known mandates. The PCI Council which oversees 10 different standards and a dozen programs is in the process of updating and rolling out standards that will have a big impact on payment security.  In addition to SPoC, 2019 will see a new software security standard & framework to replace PA-DSS, improvements to the 3DS standard to benefit card-not-present & mobile payments, a new Qualified PIN Assessor (QPA) program, and a Contact-less payments on COTS standard.

What is PIN- on-Glass and Software-PIN-on-COTS?

Simply put, PIN-on-Glass is a general payments use case where a customer PIN is entered on the merchant's touch screen.  This includes both certified payment terminals and also non-certified solutions.  Software PIN on COTS (Commercial-Off-The-Shelf) is a use case where the customer PIN is entered into a commercial device like a phone, or tablet while the card is processed via small secure device.

What concerns surround PIN- on-Glass and SPoC?

There are two main concerns that arise from the new form factor and the new architecture these are:
  1. Security - Regardless of the input mechanism, how does the device secure your PIN?
  2. Accessibility - With only a touch screen, what issues arise with visually impaired customers, and accessibility laws?
From a security perspective, PTS approved touch screen payment terminals already exist and are there are no additional security complications.  Securing a PIN entered into any general purpose computing device is challenging to say the least. At this time, there are exactly zero certified SPoC solutions!  There are however, many uncertified solutions - many of which are insecure. From an accessibility perspective, with any PIN on Glass or SPoC solution merchants need to do their due diligence as they may find themselves on the wrong end of a legal action if they cannot accommodate customers with disabilities. We will discuss all of these later in the article.

How is SPoC Secure?

SPoC is, at least in part, a response to initiatives by companies like Square. The existing PCI software standard, PA-DSS, simply didn't and couldn't support this use case. In fact, payment applications for COTS devices are specifically not permitted under PA-DSS. The only approved mobile security model for PCI prior to SPoC was to use a mobile POS with a P2PE approved terminal solution rendering the COTS mPOS out of scope. SPoC is a radical departure and required completely rethinking the approach to software security. The basic idea behind SPoC is to reduce risk by splitting up sensitive data, actively monitor the operation of the solution, and react in real-time. By supporting EMV, SPoC also rejects the use of static authentication data (i.e. magnetic stripe). The approach buys security at the cost of additional  monitoring and attestation complexity. SPoC solutions consist of several parts:
  • A PTS approved Secure Card Reader PIN (SCRP) device
  • An approved SPoC Solution
    • A PIN Cardholder Verification Method (CVM) application
    • Back-end decryption, and attestation monitoring service
  •  A COTS device such as a phone or tablet
  • A PCI DSS compliant back-end processing environment hosting the SPoC back-end
The SCRP connects to the COTS device and provides:
  • EMV contact card reader with no magnet stripe or manual entry capability
  • A method of establishing PIN exchange keys with the PIN CVM application
  • Decryption of SCRP PIN data received from application
  • Encryption of the payment card data (from SCRP) and PIN (from CVM) using a PTS SRED approved mechanism for transmission to the back-end
The PIN CVM application running inside the COTS device provides:
  • Active monitoring of the COTS device's security state for signs of software tampering, debuggers, rooting & jail-breaking
  • Reporting and attestation of the COTS device security state to the back-end
  • PIN entry, encryption, and transport to the SCRP
  • Relay of SRED encrypted data to the back-end from the SCRP
The back-end provides:
  • Monitoring of COTS device status and attestations, and real-time response/reactions
  • Decryption of the SPoC request
  • Transaction processing
SPoC is a buying tool for merchants and consumers. In addition to using approved PTS SCRP devices, solution providers will need to validate the PIM CVM and backend software with an approved SPoC lab. The solution provider's back-end environment will also be validated  against the enhanced PCI DSS requirements known as DESV. The following diagram from the PCI Council illustrates the architecture:

Accessibility and the Law

Many jurisdictions, including the US, Canada, and the EU, have laws aimed at providing accessibility for disabled individuals. The scope and breadth of these laws varies. While a merchant using SPoC "line-busters" backed up by traditional PIN pads should have no problems, a merchant offering payment only via SPoC could be at risk under many of these laws as there have been a number of lawsuits filed in the US over the use of touch screens and apps. Learn more:

Consumer Trust and Adoption

Regardless of demand, a percentage of the population may simply refuse to trust these solutions.  This is particularly true in places that have had active "Protect your PIN" awareness programs. Buy-in from other payment networks could be an important factor.  Just because the major card brands are on-board doesn't mean that other payment networks will be. The Canadian market is a good example of where PINs are more strongly associated with the major banks, trust companies, credit unions,  and Interac, the national ATM and debit network, which took an early lead in promoting EMV and contactless payments than brands like Visa and MasterCard.  The Canadian experience with PIN based magnetic stripe credit card payments has been almost non-existent.  Canadians are very comfortable with using PINs for payment which may help adoption. However, the success of SPoC in Canada will be heavily influenced by  whether or not Interac buys into SPoC and how protective Canadian consumers feel about their PINs. It is also unclear if recent trends in data breaches will dim enthusiasm for this type of solution.

Hacked COTS devices?

SPoC is designed with defense in depth in mind.
  • The attestation and monitoring components are designed to detect and prevent the use of compromised COTS devices and PIN CVM applications.
  • Segregating the PIN and card data is designed to ensure that a successful compromise of the COTS/CVM could expose only the PIN
  • The SCRP design ensures that neither plain-text card data nor decryption keys are available to the COTS device.
  • By using only EMV cards, a criminal couldn't clone your card and would need to steal it.
One of the more radical parts of SPoC is the PIN CVM monitoring.  The ability and effectiveness of active tamper detection mechanisms designed to ensure that phones and tablets will not be run jail-broken or with debuggers remains an open question.

Phantom Terminals and Non-approved Solutions

In order for a criminal to get both your card data and PIN, they would need to compromise or replace both the SCRP device and the PIN CVM application. The use of fake or non-compliant card readers and PIN CVM applications presents the largest risk to consumers using SPoC. A number of existing non-certified COTS card readers are known to be insecure. Recent tests of Bluetooth enabled payment devices used by Square, PayPal, Zettle, and SumUp finds lots of vulnerabilities https://www.forbes.com/sites/thomasbrewster/2018/08/09/these-bluetooth-hacks-can-steal-your-credit-card-pin/ By limiting SPoC to EMV only and eliminating the use of static authentication data (i.e. magnetic stripe) the risk should be reduced. Consumers will be hard pressed to identify a legitimate SPoC device.  The exclusion of magnetic stripe readers (MSR) provides a a teachable point as the presence of an MSR should raise a huge red-flag that the device is not certified. However, a proposal under consideration to allow pin-less MSR on SPoC may jeopardize this important clue.

SPoC Mandates and Un-certified Solutions

The PCI Council does not set compliance deadlines as these are left to the individual card brands. For instance, there are no requirements within PCI DSS to use certified SPoC solutions. However, without them the heavy burden of compliance proof will fall to the merchant. Visa has announced a mandate to sunset all non-approved SPoC solutions:
PCI Software-based PIN Entry on COTS Device Standard and Program Published REGIONS: US, AP, Canada, CEMEA, LAC, Europe 26 JUL 2018 The Payment Card Industry Security Standards Council (PCI SSC) has published a standard for protecting PIN-based transactions on commercial off-the-shelf (COTS) devices. Merchants accepting PIN-based transactions via COTS devices must use or transition to a PCI-validated software-based PIN entry on COTS solution by 31 July 2019.
Source: https://usa.visa.com/support/merchant/library/visa-merchant-business-news-digest.html Realistically, implementing new payment systems at acquirers and merchants can take months. With no available certified solutions and only seven months to the sunset date, the deadline seems unrealistic.

SPoC and PIN-less Magnetic Stripe?

In the original release of the standard, MSRs were completely excluded. Last week the PCI Council announced that it is considering some form of transitional support for non-PIN magnetic stripe transactions. A 90-day feedback cycle will begin on this shortly. For more information see the announcements for SPoC and Contactless in 2019 https://blog.pcisecuritystandards.org/pci-spoc-and-contactless-standards-what-to-expect-in-2019/

Conclusion

Innovation and security frequently seem at odds. Tension between the promise of bright shiny new tools, and the rigor needed to ensure they're secure seems constant. Easier, faster, and more powerful things can be exploited by those with both good intentions and bad. Over the last decade payment software has been changing far more rapidly than the approved security framework increasing the tension. PCI SPoC is a radical departure from PA-DSS. SPoC represents a new approach and an attempt to strike a new balance between payment innovation and security.

Learn More

PCI Documents and Articles

The following is a list of official PCI SPoC resources: Related articles

SPoC Program Timeline

This is a list of key events in the development of SPoC:

Square and Mobile PIN

[post_title] => PCI SPoC (PIN on COTS) - Grand Experiment in Mobile Payments [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-spoc-pin-on-cots-grand-experiment-in-mobile-payments [to_ping] => [pinged] => [post_modified] => 2019-01-28 14:49:27 [post_modified_gmt] => 2019-01-28 14:49:27 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1678 [menu_order] => 15 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 51 [max_num_pages] => 17 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => 1 [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => 1 [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => 0573d79d0a353cbc766661db59ba41a2 [query_vars_changed:WP_Query:private] => 1 [thumbnails_cached] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) )
WP_Query Object ( [query] => Array ( [post_type] => post [post_status] => publish [cat] => 14, 134, 1 [orderby] => date [order] => desc [posts_per_page] => 3 [paged] => 1 [ignore_sticky_posts] => 1 ) [query_vars] => Array ( [post_type] => post [post_status] => publish [cat] => 14 [orderby] => date [order] => DESC [posts_per_page] => 3 [paged] => 1 [ignore_sticky_posts] => 1 [error] => [m] => [p] => 0 [post_parent] => [subpost] => [subpost_id] => [attachment] => [attachment_id] => 0 [name] => [static] => [pagename] => [page_id] => 0 [second] => [minute] => [hour] => [day] => 0 [monthnum] => 0 [year] => 0 [w] => 0 [category_name] => charity [tag] => [tag_id] => [author] => [author_name] => [feed] => [tb] => [meta_key] => [meta_value] => [preview] => [s] => [sentence] => [title] => [fields] => [menu_order] => [embed] => [category__in] => Array ( ) [category__not_in] => Array ( ) [category__and] => Array ( ) [post__in] => Array ( ) [post__not_in] => Array ( ) [post_name__in] => Array ( ) [tag__in] => Array ( ) [tag__not_in] => Array ( ) [tag__and] => Array ( ) [tag_slug__in] => Array ( ) [tag_slug__and] => Array ( ) [post_parent__in] => Array ( ) [post_parent__not_in] => Array ( ) [author__in] => Array ( ) [author__not_in] => Array ( ) [update_post_term_cache] => 1 [suppress_filters] => [cache_results] => 1 [lazy_load_term_meta] => 1 [update_post_meta_cache] => 1 [nopaging] => [comments_per_page] => 50 [no_found_rows] => ) [tax_query] => WP_Tax_Query Object ( [queries] => Array ( [0] => Array ( [taxonomy] => category [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id [operator] => IN [include_children] => 1 ) ) [relation] => AND [table_aliases:protected] => Array ( [0] => wpcm_term_relationships ) [queried_terms] => Array ( [category] => Array ( [terms] => Array ( [0] => 14 [1] => 134 [2] => 1 ) [field] => term_id ) ) [primary_table] => wpcm_posts [primary_id_column] => ID ) [meta_query] => WP_Meta_Query Object ( [queries] => Array ( ) [relation] => [meta_table] => [meta_id_column] => [primary_table] => [primary_id_column] => [table_aliases:protected] => Array ( ) [clauses:protected] => Array ( ) [has_or_relation:protected] => ) [date_query] => [request] => SELECT SQL_CALC_FOUND_ROWS wpcm_posts.ID FROM wpcm_posts LEFT JOIN wpcm_term_relationships ON (wpcm_posts.ID = wpcm_term_relationships.object_id) WHERE 1=1 AND ( wpcm_term_relationships.term_taxonomy_id IN (1,14,134) ) AND wpcm_posts.post_type = 'post' AND ((wpcm_posts.post_status = 'publish')) GROUP BY wpcm_posts.ID ORDER BY wpcm_posts.menu_order, wpcm_posts.post_date DESC LIMIT 0, 3 [posts] => Array ( [0] => WP_Post Object ( [ID] => 1678 [post_author] => 2 [post_date] => 2019-01-28 14:49:25 [post_date_gmt] => 2019-01-28 14:49:25 [post_content] => Big changes are coming to payment security in 2019. PCI is launching a grand experiment in payment security - Software PIN on COTS (SPoC) - a subset of "PIN-on-glass". SPoC is intended to make payments using devices like phones and tablets both easy and secure. The approach is both interesting and a departure from previous payment security standards. SPoC has generated a lot market interest but will face challenges with complexity and potentially with acceptance.  This article looks at what SPoC is, its new security model, and some of the challenges. We also present a timeline on the standard including known mandates. The PCI Council which oversees 10 different standards and a dozen programs is in the process of updating and rolling out standards that will have a big impact on payment security.  In addition to SPoC, 2019 will see a new software security standard & framework to replace PA-DSS, improvements to the 3DS standard to benefit card-not-present & mobile payments, a new Qualified PIN Assessor (QPA) program, and a Contact-less payments on COTS standard.

What is PIN- on-Glass and Software-PIN-on-COTS?

Simply put, PIN-on-Glass is a general payments use case where a customer PIN is entered on the merchant's touch screen.  This includes both certified payment terminals and also non-certified solutions.  Software PIN on COTS (Commercial-Off-The-Shelf) is a use case where the customer PIN is entered into a commercial device like a phone, or tablet while the card is processed via small secure device.

What concerns surround PIN- on-Glass and SPoC?

There are two main concerns that arise from the new form factor and the new architecture these are:
  1. Security - Regardless of the input mechanism, how does the device secure your PIN?
  2. Accessibility - With only a touch screen, what issues arise with visually impaired customers, and accessibility laws?
From a security perspective, PTS approved touch screen payment terminals already exist and are there are no additional security complications.  Securing a PIN entered into any general purpose computing device is challenging to say the least. At this time, there are exactly zero certified SPoC solutions!  There are however, many uncertified solutions - many of which are insecure. From an accessibility perspective, with any PIN on Glass or SPoC solution merchants need to do their due diligence as they may find themselves on the wrong end of a legal action if they cannot accommodate customers with disabilities. We will discuss all of these later in the article.

How is SPoC Secure?

SPoC is, at least in part, a response to initiatives by companies like Square. The existing PCI software standard, PA-DSS, simply didn't and couldn't support this use case. In fact, payment applications for COTS devices are specifically not permitted under PA-DSS. The only approved mobile security model for PCI prior to SPoC was to use a mobile POS with a P2PE approved terminal solution rendering the COTS mPOS out of scope. SPoC is a radical departure and required completely rethinking the approach to software security. The basic idea behind SPoC is to reduce risk by splitting up sensitive data, actively monitor the operation of the solution, and react in real-time. By supporting EMV, SPoC also rejects the use of static authentication data (i.e. magnetic stripe). The approach buys security at the cost of additional  monitoring and attestation complexity. SPoC solutions consist of several parts:
  • A PTS approved Secure Card Reader PIN (SCRP) device
  • An approved SPoC Solution
    • A PIN Cardholder Verification Method (CVM) application
    • Back-end decryption, and attestation monitoring service
  •  A COTS device such as a phone or tablet
  • A PCI DSS compliant back-end processing environment hosting the SPoC back-end
The SCRP connects to the COTS device and provides:
  • EMV contact card reader with no magnet stripe or manual entry capability
  • A method of establishing PIN exchange keys with the PIN CVM application
  • Decryption of SCRP PIN data received from application
  • Encryption of the payment card data (from SCRP) and PIN (from CVM) using a PTS SRED approved mechanism for transmission to the back-end
The PIN CVM application running inside the COTS device provides:
  • Active monitoring of the COTS device's security state for signs of software tampering, debuggers, rooting & jail-breaking
  • Reporting and attestation of the COTS device security state to the back-end
  • PIN entry, encryption, and transport to the SCRP
  • Relay of SRED encrypted data to the back-end from the SCRP
The back-end provides:
  • Monitoring of COTS device status and attestations, and real-time response/reactions
  • Decryption of the SPoC request
  • Transaction processing
SPoC is a buying tool for merchants and consumers. In addition to using approved PTS SCRP devices, solution providers will need to validate the PIM CVM and backend software with an approved SPoC lab. The solution provider's back-end environment will also be validated  against the enhanced PCI DSS requirements known as DESV. The following diagram from the PCI Council illustrates the architecture:

Accessibility and the Law

Many jurisdictions, including the US, Canada, and the EU, have laws aimed at providing accessibility for disabled individuals. The scope and breadth of these laws varies. While a merchant using SPoC "line-busters" backed up by traditional PIN pads should have no problems, a merchant offering payment only via SPoC could be at risk under many of these laws as there have been a number of lawsuits filed in the US over the use of touch screens and apps. Learn more:

Consumer Trust and Adoption

Regardless of demand, a percentage of the population may simply refuse to trust these solutions.  This is particularly true in places that have had active "Protect your PIN" awareness programs. Buy-in from other payment networks could be an important factor.  Just because the major card brands are on-board doesn't mean that other payment networks will be. The Canadian market is a good example of where PINs are more strongly associated with the major banks, trust companies, credit unions,  and Interac, the national ATM and debit network, which took an early lead in promoting EMV and contactless payments than brands like Visa and MasterCard.  The Canadian experience with PIN based magnetic stripe credit card payments has been almost non-existent.  Canadians are very comfortable with using PINs for payment which may help adoption. However, the success of SPoC in Canada will be heavily influenced by  whether or not Interac buys into SPoC and how protective Canadian consumers feel about their PINs. It is also unclear if recent trends in data breaches will dim enthusiasm for this type of solution.

Hacked COTS devices?

SPoC is designed with defense in depth in mind.
  • The attestation and monitoring components are designed to detect and prevent the use of compromised COTS devices and PIN CVM applications.
  • Segregating the PIN and card data is designed to ensure that a successful compromise of the COTS/CVM could expose only the PIN
  • The SCRP design ensures that neither plain-text card data nor decryption keys are available to the COTS device.
  • By using only EMV cards, a criminal couldn't clone your card and would need to steal it.
One of the more radical parts of SPoC is the PIN CVM monitoring.  The ability and effectiveness of active tamper detection mechanisms designed to ensure that phones and tablets will not be run jail-broken or with debuggers remains an open question.

Phantom Terminals and Non-approved Solutions

In order for a criminal to get both your card data and PIN, they would need to compromise or replace both the SCRP device and the PIN CVM application. The use of fake or non-compliant card readers and PIN CVM applications presents the largest risk to consumers using SPoC. A number of existing non-certified COTS card readers are known to be insecure. Recent tests of Bluetooth enabled payment devices used by Square, PayPal, Zettle, and SumUp finds lots of vulnerabilities https://www.forbes.com/sites/thomasbrewster/2018/08/09/these-bluetooth-hacks-can-steal-your-credit-card-pin/ By limiting SPoC to EMV only and eliminating the use of static authentication data (i.e. magnetic stripe) the risk should be reduced. Consumers will be hard pressed to identify a legitimate SPoC device.  The exclusion of magnetic stripe readers (MSR) provides a a teachable point as the presence of an MSR should raise a huge red-flag that the device is not certified. However, a proposal under consideration to allow pin-less MSR on SPoC may jeopardize this important clue.

SPoC Mandates and Un-certified Solutions

The PCI Council does not set compliance deadlines as these are left to the individual card brands. For instance, there are no requirements within PCI DSS to use certified SPoC solutions. However, without them the heavy burden of compliance proof will fall to the merchant. Visa has announced a mandate to sunset all non-approved SPoC solutions:
PCI Software-based PIN Entry on COTS Device Standard and Program Published REGIONS: US, AP, Canada, CEMEA, LAC, Europe 26 JUL 2018 The Payment Card Industry Security Standards Council (PCI SSC) has published a standard for protecting PIN-based transactions on commercial off-the-shelf (COTS) devices. Merchants accepting PIN-based transactions via COTS devices must use or transition to a PCI-validated software-based PIN entry on COTS solution by 31 July 2019.
Source: https://usa.visa.com/support/merchant/library/visa-merchant-business-news-digest.html Realistically, implementing new payment systems at acquirers and merchants can take months. With no available certified solutions and only seven months to the sunset date, the deadline seems unrealistic.

SPoC and PIN-less Magnetic Stripe?

In the original release of the standard, MSRs were completely excluded. Last week the PCI Council announced that it is considering some form of transitional support for non-PIN magnetic stripe transactions. A 90-day feedback cycle will begin on this shortly. For more information see the announcements for SPoC and Contactless in 2019 https://blog.pcisecuritystandards.org/pci-spoc-and-contactless-standards-what-to-expect-in-2019/

Conclusion

Innovation and security frequently seem at odds. Tension between the promise of bright shiny new tools, and the rigor needed to ensure they're secure seems constant. Easier, faster, and more powerful things can be exploited by those with both good intentions and bad. Over the last decade payment software has been changing far more rapidly than the approved security framework increasing the tension. PCI SPoC is a radical departure from PA-DSS. SPoC represents a new approach and an attempt to strike a new balance between payment innovation and security.

Learn More

PCI Documents and Articles

The following is a list of official PCI SPoC resources: Related articles

SPoC Program Timeline

This is a list of key events in the development of SPoC:

Square and Mobile PIN

[post_title] => PCI SPoC (PIN on COTS) - Grand Experiment in Mobile Payments [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-spoc-pin-on-cots-grand-experiment-in-mobile-payments [to_ping] => [pinged] => [post_modified] => 2019-01-28 14:49:27 [post_modified_gmt] => 2019-01-28 14:49:27 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1678 [menu_order] => 15 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1877 [post_author] => 2 [post_date] => 2018-12-05 12:40:40 [post_date_gmt] => 2018-12-05 12:40:40 [post_content] => Payment card breaches concern customers and businesses alike. A recent epidemic of e-commerce breaches is focusing attention on what makes a website more or less secure than others. The old advice of looking for the “security lock” and the “green location bar” are simply not-adequate anymore. While fully evaluating the security of an e-commerce site is a bit technical and involved, we wanted to provide a simpler resource to help people understand the risks. It isn’t uncommon for a merchant’s compliance department, project manager, or system owner to not know the details of their website. Rather than asking the web developer/maintainer, our idea was to present a simpler procedure that could be quickly used by anyone, even a curious consumer. This method doesn’t require sophisticated security tools or skills, just your browser and a little patience.

Why are "Locks" and "Bars" not enough?

Much of the standard advice on secure shopping focuses on knowing your merchant (good advice) and external technical indicators like "locks" and "bars" which aren't enough.

Under-the-covers, many e-commerce websites are insecure

To understand why "locks" and "bars" aren't enough, it necessary to look beneath the covers at how most e-commerce websites are built. Merchants want to provide their customers with a rich, full-featured, easy-to-use website and a great shopping experience. They also want to be able to optimize their website using sophisticated analytics and tracking tools. Payment processing is typically a tiny portion of the website commonly implemented a form that accepts card data and directly posts it back to the merchant's payment processor. A typical e-commerce website embeds third-party scripts from potentially dozens of websites. Every script on the page has visibility into that form. Every third-party website and every change made to them can potentially impact the security of the website and your card data.  This is a key selling point for a number of legitimate tracking and web replay software. However, many of these have been shown to have security problems. It's also exploited by criminals. Yet many website developers are either unaware or unconcerned with this risk and aren't addressing it. As a direct consequence of this development style and lack of focus on supply-chain security a number of organized criminal gangs have been using this method to actively exploit e-commerce sites. To date over 100,000 sites have been compromised including Newegg, British Airways, and Ticket Master. These attacks are collectively known as "Magecart". For more information on Magecart and the problems with Web Replay software see "Learn More About E-Commerce Insecurity" at the end of this article. One of the best ways to defend against these attacks and errors is to use IFRAMEs rather that direct-post forms.  The IFRAME will effectively sand-box the card entry to the processors site. And while it won't eliminate all risks, it will provide a significant security boost. Alternatively, a full redirection to the payment processors website will provide a similar defense.

Which types of payment sites are the most secure?

The questions you want to answer for your e-commerce site are,:
  • Which of the following scenarios apply
  • How secure is the handling of the payment card?
  • What is the risk?
 
Malicious URL Merchant URL Acquirer or Payment Gateway URL
How secure is this method? This site is compromised. Leave immediately. Less secure More secure
How does this method work? The merchant's website is manipulated by malicious individuals to forward your credit card information to criminals. Criminals can be quite creative when stealing from you. They may do things like adding code to the merchant website, or to one of the script sites used by the merchant. They may make a convincing looking clone of the merchant's site. The merchant website either directly receives your credit card information or makes the payment form that collects your credit card info.Your credit card info is then forwarded to either (1) the merchant bank (also called the acquirer), or (2) a payment gateway. This method is vulnerable to attack because there is a much higher chance of the merchant's systems or its payment form codes being compromised by criminals. Effort required by the merchant to secure this type of web page is high. This relies on a concept called IFRAME (inline frame) provided by the acquirer or payment gateway.The IFRAME provides a 'sandbox' isolating environment between the merchant website and the 'frame' where the credit card info is entered.In this method, the credit card info is not easily accessed or exploited by malicious individuals. The acquirer or payment gateway is required to be PCI DSS compliant. Note: All URLs should start with "https://".
 

How would you check the security of a website’s payment card input?

This process allows you to look through the website’s code to see how and where they are using IFRAMEs to process payment card data. The procedure is simple and will take you directly to the code we want to look at. Firstly, once you land on the payment page, press [F12] on your keyboard to display the web code for the page. The code will be in either the Elements tab (Google Chrome and Microsoft Edge) or the Inspector tab (Mozilla Firefox). Click on each image below to enlarge them and view in greater detail.

1. Right click on the credit card number box and select Inspect Element

Click to View Full Size Image

2. Your browser will display something like this

Click to View Full Size Image

3. Search up and down the code in the Inspector field, until you locate the IFRAME

Ensure when you hover your mouse over the piece of IFRAME code, it reflects the credit card number box. Then your IFRAME should have the following:
  • An IFRAME tag with a source to another encrypted website, such as <iframe src = ”https://...” . And
  • The source web site name is coming from any of the acquirer or payment gateway domains listed below. 
Click to View Full Size Image

4. If you cannot find the IFRAME treat the site as less secure

At this point, if you haven't located the payment IFRAME or you are uncertain you should treat the site as less secure. While a detailed deep dive into the technicalities is beyond the scope of this article, if you are a merchant compliance officer, project manager, or system owner and have reached this point you should get a more in-depth analysis from someone skilled in e-commerce security.

List of Canadian Acquirers & Payment Gateways

The following is a partial list of acquirers and processors that provide IFRAME payment page support in Canada.
  • Caisse Populaire Desjardins (bambora.com or beanstream.com)
  • Own (Eigev.com)
  • Global Payments (gtpaysecure.net)
  • Moneris (moneris.com)
  • PayPal (paypal.com)
  • Paysafe (paysafe.com )
  • TD Merchant Solutions  (bambora.com or beanstream.com)
Note  this is not a complete list and there may be other compliant IFRAME payment page providers.

Decision Flow

Based on what you find you should be able to answer the following:    

Sample Merchant Web Pages

Payment IFRAME example 1

This web site uses an IFRAME to redirect to Paysafe's payment gateway.    

Payment IFRAME example 2 – IFRAME URL to acquirer Moneris

This web site uses an IFRAME to redirect to Moneris' payment gateway.  

Other (non-IFRAME) payment example

This web site uses a web form to collect and process payments.

Non-payment IFRAME example

This web page is using an IFRAME to support web tracking and advertising.

Learn More About E-Commerce Insecurity

The following articles illustrate the security problems faced by many e-commerce websites:

[post_title] => How can I tell if the site I shop from is secure? [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => how-can-i-tell-if-the-site-i-shop-from-is-secure [to_ping] => [pinged] => [post_modified] => 2018-12-06 20:45:05 [post_modified_gmt] => 2018-12-06 20:45:05 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1877 [menu_order] => 24 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 1895 [post_author] => 2 [post_date] => 2018-11-07 05:29:57 [post_date_gmt] => 2018-11-07 05:29:57 [post_content] => To accept credit cards in Canada, businesses need to be PCI compliant. Becoming PCI compliant can be difficult in the first place and keeping up with the changes even more so. In May 2018 the Payment Card Industry (PCI) Security Standards Council (formed to regulate security for the payment card industry) released an updated list of compliance requirements known as the PCI Data Security Standard (DSS) v3.2.1. Let us guide you through these new requirements. We found hundreds of wording changes, most of them innocuous and helpful clarifications, however, a small number of these changes will require some attention in order to maintain compliance after December 2018. This article focuses on changes to the DSS standard.  There were also significant changes to the reporting template which we introduce here and will report on more fully in a follow-up article. Continue reading for everything you need to know about PCI DSS v3.2.1 or contact us now and let us guide you through PCI Compliance.

What Are the Largest Impacts of PCI DSS v3.2.1?

The Changes Amount to Almost Nothing, Except E-Commerce Web Redirection Servers, Reporting Instructions

The changes in DSS 3.2.1 are mostly administrative clarifications, minor fixes, and clean-up of now-expired future-dated requirements. There were hundreds of wording changes, 4 numbering changes, and 3 testing procedures removed. On the surface, these amount to virtually no impact to customer compliance effort. The largest impacts we identified in PCI DSS 3.2.1 are actually not due to changes in the DSS itself but the interpretation of the intent. The changes are most evident in the PCI Self-Assessment Questionnaire A (SAQ-A). Whether an entity is completing an SAQ or a Report on Compliance, e-commerce web redirection servers that utilize iframe or Full URL redirection are now subject to increased requirements, now adding requirement patch management (DSS 6.2) to these system components. This slight increase in compliance footprint size may seem small, and for many organizations doing the right thing it won't be a problem. However, since these changes are quietly buried in the SAQ documents and are not part of the announced DSS changes, we anticipate that this seemingly tiny change will catch many service providers and merchants by surprise and will result in compliance validation delays. Another surprise, is there are significant changes in the reporting instructions that will affect organizations undergoing "level 1" onsite assessments.

What Is the Difference Between PCI DSS v3.2 and PCI DSS v3.2.1?

In addition to the hundreds of wording changes, 4 numbering changes, and 3 testing procedures removed, there were:

19 Total Discrete Change Clusters

  • 19 of these changes have an impact rating of None. These changes have a negligible impact on compliance and help to improve clarity and understanding on intent.
  • 0 of these changes have an impact rating of Low. These changes have a low impact on compliance and are a new incremental change that potentially alter compliance efforts.
  • 0 of these changes have an impact rating of High. These changes have a high impact on compliance and are typically a new requirement or involve potentially significant effort to achieve or sustain compliance.

Zero Evolving (New or Changed) Requirements

  • There are no new or changed “evolving” requirements, which is good news.

Change Analysis - the DSS Standard

There are several other significant differences between PCI DSS V3.2 and PCI DSS V3.2.1. We have prepared a quick overview of the changes in our Change Analysis Brief. We have also prepared a Before & After Redline View if you would like to see every word that changed.

Change Analysis - Report on Compliance Templates (coming soon)

Given the relatively minor nature of this update we were not expecting a lot a changes to the Reporting Templates.  Reporting Templates are mandatory instructions for QSA's working with organizations considered "Level 1's" that must undergo onsite assessments and complete Reports on Compliance. We found there is an increased emphasis on the specifics required in the answers. While we don't believe the intent of the instructions have changed, some organizations may find that RoC's will require additional time and effort to satisfy these changes.

References:

Becoming PCI Compliant can be difficult, so why not let Control Gap guide you. We are the largest dedicated PCI compliance company in Canada. Contact us today and learn more about how we can help you: Get PCI Compliant. Stay PCI Compliant.   [post_title] => PCI DSS v3.2.1 - What You Need to Know to Stay PCI Compliant [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-dss-v3-2-1-what-you-need-to-know-to-stay-pci-compliant [to_ping] => [pinged] => [post_modified] => 2018-11-07 05:29:57 [post_modified_gmt] => 2018-11-07 05:29:57 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1895 [menu_order] => 29 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 3 [current_post] => -1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 1678 [post_author] => 2 [post_date] => 2019-01-28 14:49:25 [post_date_gmt] => 2019-01-28 14:49:25 [post_content] => Big changes are coming to payment security in 2019. PCI is launching a grand experiment in payment security - Software PIN on COTS (SPoC) - a subset of "PIN-on-glass". SPoC is intended to make payments using devices like phones and tablets both easy and secure. The approach is both interesting and a departure from previous payment security standards. SPoC has generated a lot market interest but will face challenges with complexity and potentially with acceptance.  This article looks at what SPoC is, its new security model, and some of the challenges. We also present a timeline on the standard including known mandates. The PCI Council which oversees 10 different standards and a dozen programs is in the process of updating and rolling out standards that will have a big impact on payment security.  In addition to SPoC, 2019 will see a new software security standard & framework to replace PA-DSS, improvements to the 3DS standard to benefit card-not-present & mobile payments, a new Qualified PIN Assessor (QPA) program, and a Contact-less payments on COTS standard.

What is PIN- on-Glass and Software-PIN-on-COTS?

Simply put, PIN-on-Glass is a general payments use case where a customer PIN is entered on the merchant's touch screen.  This includes both certified payment terminals and also non-certified solutions.  Software PIN on COTS (Commercial-Off-The-Shelf) is a use case where the customer PIN is entered into a commercial device like a phone, or tablet while the card is processed via small secure device.

What concerns surround PIN- on-Glass and SPoC?

There are two main concerns that arise from the new form factor and the new architecture these are:
  1. Security - Regardless of the input mechanism, how does the device secure your PIN?
  2. Accessibility - With only a touch screen, what issues arise with visually impaired customers, and accessibility laws?
From a security perspective, PTS approved touch screen payment terminals already exist and are there are no additional security complications.  Securing a PIN entered into any general purpose computing device is challenging to say the least. At this time, there are exactly zero certified SPoC solutions!  There are however, many uncertified solutions - many of which are insecure. From an accessibility perspective, with any PIN on Glass or SPoC solution merchants need to do their due diligence as they may find themselves on the wrong end of a legal action if they cannot accommodate customers with disabilities. We will discuss all of these later in the article.

How is SPoC Secure?

SPoC is, at least in part, a response to initiatives by companies like Square. The existing PCI software standard, PA-DSS, simply didn't and couldn't support this use case. In fact, payment applications for COTS devices are specifically not permitted under PA-DSS. The only approved mobile security model for PCI prior to SPoC was to use a mobile POS with a P2PE approved terminal solution rendering the COTS mPOS out of scope. SPoC is a radical departure and required completely rethinking the approach to software security. The basic idea behind SPoC is to reduce risk by splitting up sensitive data, actively monitor the operation of the solution, and react in real-time. By supporting EMV, SPoC also rejects the use of static authentication data (i.e. magnetic stripe). The approach buys security at the cost of additional  monitoring and attestation complexity. SPoC solutions consist of several parts:
  • A PTS approved Secure Card Reader PIN (SCRP) device
  • An approved SPoC Solution
    • A PIN Cardholder Verification Method (CVM) application
    • Back-end decryption, and attestation monitoring service
  •  A COTS device such as a phone or tablet
  • A PCI DSS compliant back-end processing environment hosting the SPoC back-end
The SCRP connects to the COTS device and provides:
  • EMV contact card reader with no magnet stripe or manual entry capability
  • A method of establishing PIN exchange keys with the PIN CVM application
  • Decryption of SCRP PIN data received from application
  • Encryption of the payment card data (from SCRP) and PIN (from CVM) using a PTS SRED approved mechanism for transmission to the back-end
The PIN CVM application running inside the COTS device provides:
  • Active monitoring of the COTS device's security state for signs of software tampering, debuggers, rooting & jail-breaking
  • Reporting and attestation of the COTS device security state to the back-end
  • PIN entry, encryption, and transport to the SCRP
  • Relay of SRED encrypted data to the back-end from the SCRP
The back-end provides:
  • Monitoring of COTS device status and attestations, and real-time response/reactions
  • Decryption of the SPoC request
  • Transaction processing
SPoC is a buying tool for merchants and consumers. In addition to using approved PTS SCRP devices, solution providers will need to validate the PIM CVM and backend software with an approved SPoC lab. The solution provider's back-end environment will also be validated  against the enhanced PCI DSS requirements known as DESV. The following diagram from the PCI Council illustrates the architecture:

Accessibility and the Law

Many jurisdictions, including the US, Canada, and the EU, have laws aimed at providing accessibility for disabled individuals. The scope and breadth of these laws varies. While a merchant using SPoC "line-busters" backed up by traditional PIN pads should have no problems, a merchant offering payment only via SPoC could be at risk under many of these laws as there have been a number of lawsuits filed in the US over the use of touch screens and apps. Learn more:

Consumer Trust and Adoption

Regardless of demand, a percentage of the population may simply refuse to trust these solutions.  This is particularly true in places that have had active "Protect your PIN" awareness programs. Buy-in from other payment networks could be an important factor.  Just because the major card brands are on-board doesn't mean that other payment networks will be. The Canadian market is a good example of where PINs are more strongly associated with the major banks, trust companies, credit unions,  and Interac, the national ATM and debit network, which took an early lead in promoting EMV and contactless payments than brands like Visa and MasterCard.  The Canadian experience with PIN based magnetic stripe credit card payments has been almost non-existent.  Canadians are very comfortable with using PINs for payment which may help adoption. However, the success of SPoC in Canada will be heavily influenced by  whether or not Interac buys into SPoC and how protective Canadian consumers feel about their PINs. It is also unclear if recent trends in data breaches will dim enthusiasm for this type of solution.

Hacked COTS devices?

SPoC is designed with defense in depth in mind.
  • The attestation and monitoring components are designed to detect and prevent the use of compromised COTS devices and PIN CVM applications.
  • Segregating the PIN and card data is designed to ensure that a successful compromise of the COTS/CVM could expose only the PIN
  • The SCRP design ensures that neither plain-text card data nor decryption keys are available to the COTS device.
  • By using only EMV cards, a criminal couldn't clone your card and would need to steal it.
One of the more radical parts of SPoC is the PIN CVM monitoring.  The ability and effectiveness of active tamper detection mechanisms designed to ensure that phones and tablets will not be run jail-broken or with debuggers remains an open question.

Phantom Terminals and Non-approved Solutions

In order for a criminal to get both your card data and PIN, they would need to compromise or replace both the SCRP device and the PIN CVM application. The use of fake or non-compliant card readers and PIN CVM applications presents the largest risk to consumers using SPoC. A number of existing non-certified COTS card readers are known to be insecure. Recent tests of Bluetooth enabled payment devices used by Square, PayPal, Zettle, and SumUp finds lots of vulnerabilities https://www.forbes.com/sites/thomasbrewster/2018/08/09/these-bluetooth-hacks-can-steal-your-credit-card-pin/ By limiting SPoC to EMV only and eliminating the use of static authentication data (i.e. magnetic stripe) the risk should be reduced. Consumers will be hard pressed to identify a legitimate SPoC device.  The exclusion of magnetic stripe readers (MSR) provides a a teachable point as the presence of an MSR should raise a huge red-flag that the device is not certified. However, a proposal under consideration to allow pin-less MSR on SPoC may jeopardize this important clue.

SPoC Mandates and Un-certified Solutions

The PCI Council does not set compliance deadlines as these are left to the individual card brands. For instance, there are no requirements within PCI DSS to use certified SPoC solutions. However, without them the heavy burden of compliance proof will fall to the merchant. Visa has announced a mandate to sunset all non-approved SPoC solutions:
PCI Software-based PIN Entry on COTS Device Standard and Program Published REGIONS: US, AP, Canada, CEMEA, LAC, Europe 26 JUL 2018 The Payment Card Industry Security Standards Council (PCI SSC) has published a standard for protecting PIN-based transactions on commercial off-the-shelf (COTS) devices. Merchants accepting PIN-based transactions via COTS devices must use or transition to a PCI-validated software-based PIN entry on COTS solution by 31 July 2019.
Source: https://usa.visa.com/support/merchant/library/visa-merchant-business-news-digest.html Realistically, implementing new payment systems at acquirers and merchants can take months. With no available certified solutions and only seven months to the sunset date, the deadline seems unrealistic.

SPoC and PIN-less Magnetic Stripe?

In the original release of the standard, MSRs were completely excluded. Last week the PCI Council announced that it is considering some form of transitional support for non-PIN magnetic stripe transactions. A 90-day feedback cycle will begin on this shortly. For more information see the announcements for SPoC and Contactless in 2019 https://blog.pcisecuritystandards.org/pci-spoc-and-contactless-standards-what-to-expect-in-2019/

Conclusion

Innovation and security frequently seem at odds. Tension between the promise of bright shiny new tools, and the rigor needed to ensure they're secure seems constant. Easier, faster, and more powerful things can be exploited by those with both good intentions and bad. Over the last decade payment software has been changing far more rapidly than the approved security framework increasing the tension. PCI SPoC is a radical departure from PA-DSS. SPoC represents a new approach and an attempt to strike a new balance between payment innovation and security.

Learn More

PCI Documents and Articles

The following is a list of official PCI SPoC resources: Related articles

SPoC Program Timeline

This is a list of key events in the development of SPoC:

Square and Mobile PIN

[post_title] => PCI SPoC (PIN on COTS) - Grand Experiment in Mobile Payments [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => pci-spoc-pin-on-cots-grand-experiment-in-mobile-payments [to_ping] => [pinged] => [post_modified] => 2019-01-28 14:49:27 [post_modified_gmt] => 2019-01-28 14:49:27 [post_content_filtered] => [post_parent] => 0 [guid] => http://controlgap.com/?p=1678 [menu_order] => 15 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 51 [max_num_pages] => 17 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => 1 [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => 1 [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => 0573d79d0a353cbc766661db59ba41a2 [query_vars_changed:WP_Query:private] => 1 [thumbnails_cached] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) )
PCI SPoC (PIN on COTS) – Grand Experiment in Mobile Payments
January 28 2019

Big changes are coming to payment security in 2019. PCI is launching a grand experiment in payment security – Software PIN on COTS (SPoC) – a subset of “PIN-on-glass”. SPoC is intended to make payments using devices like phones and tablets both easy and secure. The approach is both interesting and a departure from previous payment

Read More
How can I tell if the site I shop from is secure?
December 5 2018

Payment card breaches concern customers and businesses alike. A recent epidemic of e-commerce breaches is focusing attention on what makes a website more or less secure than others. The old advice of looking for the “security lock” and the “green location bar” are simply not-adequate anymore. While fully evaluating the security of an e-commerce site

Read More
PCI DSS v3.2.1 – What You Need to Know to Stay PCI Compliant
November 7 2018

To accept credit cards in Canada, businesses need to be PCI compliant. Becoming PCI compliant can be difficult in the first place and keeping up with the changes even more so. In May 2018 the Payment Card Industry (PCI) Security Standards Council (formed to regulate security for the payment card industry) released an updated list

Read More

e-newsletter

Want important PCI information delivered to you? Sign-up to our e-newsletter and be the first one to know about industry news and trend, offers and promotions.

×

Contact

×

PCI Pilot™ is coming soon!

Our highly-anticipated online tool will be launching very soon to make your PCI SAQ process quick and seamless.

Sign-up today and be among the first to know when PCI Pilot™ is live!