RE: PCI standards & Should login pages be protected by SSL?

["Lyal Collins" <lyal.collins () key2it com au>]

Having had some exposure to complying to Visa Asia's AIS program, I can add
that there is lots of room for interpretation and vagueness.

A few CISP/AIS/PCI comments to offer:
AIS, CISP and PCI need to suit a very broad set of platforms, OS's and
application architectures.  That's life. These are not documents about a
hardened version <insert OS here>.  Imho, these documents aim to deliver a
consistent benchmark across the industry rather than fix every security
issue under the sun. They are a good dtart, and can only get better over
time.
-encrypting password and not usernames - caters for some real-world
situations, like a windows logon where the username isn't encrypted, but the
password is hashed/encrypted across the internal network.
- there's no explicit need to encrypt card data flowing across 'internal'
networks, even if that include a national-widw WAN.
- a number of business processes mandated by the Card Schems cannot be
provided if the card number is un-readable, so encryption/'secure site'
options are the only real choice (or the business outsources those functions
to an issuing/acquiring bank.  MOTO refund handling, subscription
transactions are some simple examples.
- no, its not at all clear that the form seen by the consumer must SSL/TLS
protected, on tly that the data is encrypted.  But imho it's hard to not
encrypt the form, when every bank and ecommerce advisory says 'check the
padlock before entering sensitive details"

PCI/AIS/CISP/SDP all require encryption of 'data at rest'.  As far as I can
see, this will only assure data protection if the media is stolen or lost.
I can only see a few limited cases where encrypting databases actually makes
data safer in operational/transactional settings.  Arguably, this aspect can
be one of the most expensive elements to implement, especially for a 'full
service', high volume processor site.

As an aside the "AP_Encrypt_Clarification.pdf" document reflects one site
I've worked at where encrypting a zOS mainframe was going to be waaayyyy too
expensive and risky to cut over  (vendor products now seem to be emerging
that may actually be deployable in real life).


Regards,
Lyal


-----Original Message-----
From: Peter Watkins [mailto:peterw () usa net] 
Sent: Wednesday, 22 June 2005 3:24 AM
To: Andrew van der Stock
Cc: herzbea () macs biu ac il; webappsec () securityfocus com
Subject: Re: PCI standards & Should login pages be protected by SSL?


On Wed, Jun 22, 2005 at 12:25:05AM +1000, Andrew van der Stock wrote:
> On page two, it says for clients / card holders / admins / POS / ATM
> they state:
>
> "1 Network (e.g. Internet) - must have authentication and encrypted
> communication to web and/or application server"
>
> I don't think they get much clearer than that. MUST to my standards
> jaundiced eye means "no exceptions". AND means both authentication  
> and encryption at the same time. So basically, I think that covers  
> off SSL logins - in my book, Visa / MC require it for Internet  
> websites - no exceptions.

It's not clear to me that this document cover's Amit's concern of 
using https to encrypt/authenticate the <form> that asks for username/
password, credit card #, etc. 

By the way, I think the most interesting nugget in that document is the
suggestion that SHA-1 is acceptable for hashing (account # and expiration
date) data, but MD5 is not. I wonder if that would also include MD5-derived
functions like the prevalent BSD crypt() call? Given the nature of one-way
hashes, what would Visa Asia want a merchant who had MD5 hashes of account
numbers to do? Delete the data? Brute-force the original number (the 
universe of card #s is small, and the universe of expiration dates is tiny,
so anyone not using a salted hash like BSD's MD5-based crypt isn't buying
much protection by using a hash function [especially if they store the first
six digits or last four digits of an account #])?

Look at page one: "Baseline Clarifications . The MINIMUM account 
information that needs to be encrypted is the Visa account number 
and expiration date."

I'm not familiar w/ VISA Asia, but the US PCI standards 
 1) have a number of unclear, imprecise, or ambiguous sections
 2) also have language like the wording found on page one of that 
    "AP_Encrypt_Clarification.pdf" document that specifies what sorts
    of data must be protected.

> From the US PCI specs
 
(http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_mercha
nts.html)

 PCI Data Security Standard:
  Section 3.2 lists data that may not be stored 
    (mag stripe data, validation code, PIN)
  Section 3.4 talks about what data must be made "unreadable"
    ("payment card account number" -- unlike Asia, expire date not
included?)
  Section 4 talks about encrypting "transmission of cardholder and sensitive
    information across public networks" -- both web (section 4.1) and email
    (section 4.2) are explicitly covered.

 PCI Self-Assessment Questionnaire:
  Question 4.1: "Are transmissions of sensitive cardholder data encrypted 
    over public networks through the use of SSL or other industry 
    acceptable methods?"

The Visa-Asia doc makes sense to me like this:
 1) merchants must use this crypto for transmitting/receiving certain
    payment card data (e.g. card #, validation code, etc.)
 2) merchants must set up crypto for web transactions

In order to follow the 1st requirement, the 2nd must be in place. But I
don't see anything that requires crypto/auth for all interaction.

I think there's lots of good stuff in the PCI docs, but I also think they're
very messy. For instance, the PCI-DSS buries a requirement about encrypting 
passwords (but not usernames?) during transmission in section 8, which is
almost entirely devoted to non-customer infrastructure issues. Or PCI-DSS
suggests (section 4.1) that any SSL would be fine, while PCI-SAQ asks (sec
4.2) if the merchant "is using version 3.0 with 128-bit encryption". Is
PCI-SAQ implying that we should all disable SSL v2 (most big ecommerce sites
I've 
visited have SSL v2 enabled), or just that we make SSL v3 available? Why, in
December of 2004, don't the specs endorse TLS 1.0?

-Peter