PayPal's 'pay by mobile' application does not use NFC. Instead, it generates and shows the code which can be read (and keyed) by cashier or POS scanner. I suggested this technology 3 years ago. It was wrong time and... wrong place.
Video from PayPal:
Video with my solution:
Dual NFC/EMV debit MasterCard was introduced in South Africa - they claim this is the first card with combined NFC ("Tap & Go") and EMV ("Chip & Pin") functionality: http://bit.ly/Jsn5QY
Interesting article in SearchSecurity: "P2P encryption for mobile is not an technology endorsement, says PCI Council". So on the one hand, in their recent mobile payments guide for merchants, they present the P2PE as the only way to secure mobile payments. On the other hand, they say " We’re not endorsing specific technology here". I am not sure I understand the point they are trying to make.
Review of PCI mobile payments guidance for merchants:
Article in SearchSecurity:
Moxie Marlinspike and Trevor Perrin have submitted a proposal to the Internet Engineering Task Force (IETF). The draft document describes a new way of server certificate validation based on the trust accumulated and shared by multiple clients. The proposed TLS protocol extension is called Trust Assertions for Certificate Keys (TACK) and based on public key cryptography, however, it does not use the Public Key Infrastructure (certificates and certificate authorities).
The text of the proposal:
The article in InfoSecurity magazine:
Billing company WHMCS was hacked on Monday by the group of hackers called UGNazi. 500,000 records, including user passwords ("hashed") and credit card information ("although encrypted ... maybe at risk"), have been stolen. According to the company blog, it was social engineering attack.
Forbes article with my comment:
Company blog entry with the breach description:
The company blog entry about the social engineering attack scenario:
The stolen data was posted here:
It looks like OCSP Stapling currently is not the best alternative to classic CRL validation. First, because current implementation has serious limitation: only one certificate can be validated during the initial SSL/TLS handshaking session. However, as part of the server certificate checkup, the SSL client must validate the entire certificate chain -- until the root (self-signed) certificate -- which may contain more than one certificate. Second, it is not widely supported yet: not all the clients and server implementation are OCSP Stapling ready. For instance, it is still unclear whether Microsoft WCF hosting process (alternative to IIS) would support it - at least, it is not officially documented.
Original post 05/10/2012:
Future of the SSL certificate revocation validationweb-services-with-ssl.html
My article about using SSL in .NET Web Services application:
Based on information received from PCI Council, it turns out that payment application vendors do not necessarily have to go through QIR program, which is designed primarily for third parties that do not have enough knowledge and experience with PCI security standards.
Original post 05/13/2012: Questions about new PCI QIR certification program which was just announced by PCI Council
EMET (Enhanced Mitigation Experience Toolkit) is free Microsoft toolkit for application memory hardening. According to Microsoft, EMET is “designed to help prevent hackers from gaining access to your system”.
“For users who get attacked before the latest updates have been applied or who get attacked before an update is even available in cases such as 0 day attacks, the results can be devastating: malware, loss of PII, loss of business data etc. Security mitigation technologies are designed to make it impossible or more difficult for an attacker to exploit vulnerabilities in a given piece of software. EMET allows users to leverage these technologies on their system”.
When installed on target system and properly configured, it protects applications from known and zero day malware attacks.
EMET Provided Mitigations:
- Structure Exception Handler Overwrite Protection (SEHOP)
- Dynamic Data Execution Prevention (DEP)
- Heapspray Allocations
- Null page allocation
- Mandatory Address Space Layout Randomization (ASLR)
- Export Address Table Access Filtering (EAF)
- Bottom-up randomization
It works on any Windows version starting from XP SP 3 / Server 2003 SP 1.
However, it is not “out of the box” tool and require custom configuration and testing.I am running it on my machine and so far it did not do anything wrong.
EMET Info Page:
EMET Support Page:
EMET protecting 0-day attacks on Adobe:
PCI Security Standards Council just released "customized fact sheet" - guidance for merchants on how to securely implement mobile payments. According to this document called "Accepting Mobile Payments with a Smartphone or Tablet" (but for some reason referenced in press-release as "At a Glance: Mobile Payment Acceptance Security"), Point-to-Point Encryption solution -- validated and certified by P2PE QSA using recently launched PCI P2PE assessment program, and listed on PCI SSC website -- "may help you in your responsibilities under PCI DSS" and "leverages a mobile device’s display and communication functions to secure mobile payments". The only diagram in this document, which illustrates the architecture of mobile payment solution, shows P2PE solution provider accepting and processing merchant's mobile payment transactions.