The Peoples Republic of California is looking more and more like Europe everyday. In case you missed it: California retailers can't ask patrons for ZIP Codes, court rules.
In reading the story, the courts ruling seems like a noble one -- protect consumer privacy. But I feel this blanket decision totally ignores the rates merchants are charged processing these transaction with vs. without address verification information and all but ignores the security aspect for merchants requiring a ZIP code. To me, a ruling that merchants could not use any information associated with the processing of the payment for marketing or purposes, then it would have been fine. When I saw the headline, it was screaming: "CALIFORNIA WELCOMES ALL SCAMMERS AND FRAUDSTERS WITH OPEN ARMS!"
As to the rate difference, California card-present merchants will need to decide what to do in the event a card cannot be swiped: Don't ask for the ZIP code and accept the higher cost and higher potential for a fraudulent transaction OR ask for another form of payment. My advice with be the latter, but this may not be the optimum advice for all merchants.
The court touched on the security aspect, but it does leave a big hole: "....allows ZIP Codes to be collected under certain circumstances, such as at gas station pumps where the information is requested for security reasons..." -- why wouldn't all merchants fall under this "certain circumstance?"
And then the biggest little line in the entire story: "The court said retailers may still ask consumers to produce a driver's license for identification purposes but may not record the personal information on it." This advice from the courts goes against most (maybe all) merchant agreements. I'm not sure if this was a simple oversight by the courts showing lack of knowledge in payment processing regulations, or if this was an intentional warning shot over the bow of the card brands?
Monday, February 14, 2011
Wednesday, February 9, 2011
Forced Password Changes - good or bad?
For years now there has been a debate in the security community as to whether or not users should be forced to change password at regular intervals and if so, how often. On one side there is the argument that changing passwords frequently makes it harder for hackers to acquire a users password and limits the exposure if a hacker were to acquire a user's password. On the other side you have the argument that forcing users to change password increases the chances for forgotten passwords and more dangerous, the chance that users will write down passwords on paper or post-it notes stuck to their monitor or under their keyboard.
I'm one that argues the latter and I believe that most in the security community agree with this argument (at least today). I would argue that if you have sufficient controls in place to prevent, or at least throttle brute force attacks and notify users of last login successes and failures, then a user should never be forced to change their password. I would add a caveat that the password should be of sufficient length and complexity (7 character minimum, alpha and numeric, etc.) and if they are not, then a forced change should be required.
A few years back PCI decided to side with the first argument and mandate regular password changes. They believed this argument so much as to require what I believe to be a very short change interval of 90 days:
The 2005 OWASP best practice included the following:
The Problem: In several places in PA-DSS and PCI DSS, references are made to adopt best security practices and the latest security standards like OWASP -- but PCI mandated a 90 password change period. PCI does note specific exceptions in the case when these other security standards differ from PCI:
But, these notes appear to have limitations, in the case of PCI DSS:
So the problem is that while PCI SSC does realize that other best practice security standards may outpace PCI's requirements and they attempt to accommodate these discrepancies, they limit the use of these standards -- at least as far as compliance goes. To me, this can easily be correct by removing the limitations. With these limitations in place, this would be a case where “security” and “compliance” go different directions.
I welcome your thoughts.
I'm one that argues the latter and I believe that most in the security community agree with this argument (at least today). I would argue that if you have sufficient controls in place to prevent, or at least throttle brute force attacks and notify users of last login successes and failures, then a user should never be forced to change their password. I would add a caveat that the password should be of sufficient length and complexity (7 character minimum, alpha and numeric, etc.) and if they are not, then a forced change should be required.
A few years back PCI decided to side with the first argument and mandate regular password changes. They believed this argument so much as to require what I believe to be a very short change interval of 90 days:
“PCI DSS 8.5.9 Change user passwords at least every 90 days.
- 8.5.9.a For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days.
- 8.5.9.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change.”
The 2005 OWASP best practice included the following:
“Passwords are trivially broken and are unsuitable for high value systems. Therefore, ...
This tells me that in 2005 the OWASP people were leaning to the side of the first argument. Now, the latest 2010 OWASP states:- Relax password expiry requirements upon the strength of the password chosen – passwords between 8 and 16 that cannot be easily cracked should have an expiry of no less than 30 days, and pass phrases above 16 characters probably do not need a hard expiry limit, but a gentle reminder after (say) 90 days instead.”
“Password Guidelines...
While “frequently” is somewhat vague, I interpret this as OWASP is leaning toward the latter argument now.- Do not force folks to change passwords frequently as this results in the users writing the passwords down insecurely...”
The Problem: In several places in PA-DSS and PCI DSS, references are made to adopt best security practices and the latest security standards like OWASP -- but PCI mandated a 90 password change period. PCI does note specific exceptions in the case when these other security standards differ from PCI:
“However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.”
But, these notes appear to have limitations, in the case of PCI DSS:
“The vulnerabilities listed at 6.5.1 through 6.5.9 were current with industry best practices when this version of PCI DSS was published...”
and in PA-DSS:
“The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published...”
and in PA-DSS:
“The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published...”
So the problem is that while PCI SSC does realize that other best practice security standards may outpace PCI's requirements and they attempt to accommodate these discrepancies, they limit the use of these standards -- at least as far as compliance goes. To me, this can easily be correct by removing the limitations. With these limitations in place, this would be a case where “security” and “compliance” go different directions.
I welcome your thoughts.
Subscribe to:
Posts (Atom)