WebApp Sec mailing list archives
RE: PCI standards & Should login pages be protected by SSL?
From: "Lyal Collins" <lyal.collins () key2it com au>
Date: Wed, 22 Jun 2005 17:38:52 +1000
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
Current thread:
- Should login pages be protected by SSL? Amir Herzberg (Jun 20)
- Re: Should login pages be protected by SSL? Andrew van der Stock (Jun 20)
- Re: Should login pages be protected by SSL? Amir Herzberg (Jun 21)
- Re: Should login pages be protected by SSL? Andrew van der Stock (Jun 21)
- Re: Should login pages be protected by SSL? (and comment to moderator) Amir Herzberg (Jun 21)
- Re: Should login pages be protected by SSL? (and comment to moderator) Andrew van der Stock (Jun 21)
- Re: PCI standards & Should login pages be protected by SSL? Peter Watkins (Jun 21)
- RE: PCI standards & Should login pages be protected by SSL? Lyal Collins (Jun 22)
- Re: Should login pages be protected by SSL? (and comment to moderator) Amir Herzberg (Jun 21)
- Re: Should login pages be protected by SSL? Amir Herzberg (Jun 21)
- Re: Should login pages be protected by SSL? Andrew van der Stock (Jun 20)
- Re: Should login pages be protected by SSL? Steve Shah (Jun 21)
- Re: Should login pages be protected by SSL? Amir Herzberg (Jun 21)
- [summary] Re: Should login pages be protected by SSL? Steve Shah (Jun 22)
- Re: [summary] Re: Should login pages be protected by SSL? Ole Kasper Olsen (Jun 23)
- Rephrased: Should login pages be protected by SSL - although it won'thelp most users? Amir Herzberg (Jun 23)
- Re: [summary] Re: Should login pages be protected by SSL? Devdas Bhagat (Jun 23)
- Re: [summary] Re: Should login pages be protected by SSL? Michael Silk (Jun 23)
- Re: [summary] Re: Should login pages be protected by SSL? Wolfgang Reder (Jun 24)
- Re: [summary] Re: Should login pages be protected by SSL? Michael Silk (Jun 24)