A few weeks ago I mentioned two new research papers about the use of passwords on website. Another new paper from Microsoft Research and Harvard University discusses how to avoid, and protect web sites from, users selecting popular passwords.

The paper Popularity is Everything: A New Approach to Protecting Passwords from Statistical-Guessing Attacks describes online and offline threats and defences against the sue of common popular passwords.

Password implementation policies can be guided by legacy approaches and various standards, but as mentioned previously, economics plays a large part too. Following a much publicised successful brute force against Twitter accounts, the company increased its password requirements. But rather than forcing passwords to be more complex, they instead took the decision to prevent the use of 370 common passwords. Whilst the list is culturally-biased, due to other breaches, there is similar data from other sites (e.g. here and here). But how does banning popular passwords help, and if the lists of common passwords are known, does this matter?

Firstly I'll mention here a couple of typical online tools for determining password complexity:

• Password meter providing an indication of complexity
• Hammer of God providing an estimate of how long it would take to obtain the password using a brute force attack

Don't put your real passwords into these sites or any other checkers! But these types of tools do not take into account popularity (e.g. '123456') or common manipulations (e.g. is 'P@ssword' really that much more secure than 'password'?). If attackers try popular passwords first (i.e. a dictionary attack), the time to break into a user's account may be much shorter.

The research paper, which does include some mathematics, suggests that simple passwords should be allowed providing they are not subject to statistical guessing attacks and proposes attack detection methods.

Good reading and inspiration for password-based authentication systems. I'm off to the station now, to get a train to Newcastle which was cancelled last night.

Software licensing may not be high on your agenda once a web site is operational. But software licences are an important part of ensuring your web site does not infringe any laws, regulations and contracts.

From 15:30 hrs today, train services from a number of operating companies including East Coast, First Capital Connect and Grand Central are being affected by a line-side fire involving acetylene cylinders near Grantham. This has led to cancellations and delays. But curiously an hour ago, the East Coast web site was showing something a little unexpected—only the words "LicenseException: License has expired." were being displayed:

Ooops. It is slightly odd that the web site issue is occurring at the same time as the fire—I wonder if it is due to a licence limit being reached caused by high demand from customers checking the status of their trains, or trying to make alternative arrangements. The wording "expiry" suggests it is simply time related, but it does seem a bit of a coincidence.

Doing a quick search for this error message suggests many other web sites have sent this response in the content whilst being indexed:

So that seems unexpectedly common. Interestingly, some of the sites seem to be development or staging sites (e.g. using just an IP address, or using a "staging." sub-domain). These might well have been using temporary licences, but why are search engines allowed access at all, and even if they are, why isn't the robots exclusion standard for compliant crawlers being used?

Apart from the legal aspects, commercial software licences need to be acquired to allow for the total number of installations, processors, usage (e.g. bandwidth) and concurrent users (however the licence is defined) for:

• peak stress loads allowed to reach the web, application and database servers
• supporting systems
• development, testing, staging and production environments
• clusterering, failover and disaster recovery.

Licensing of all components and third-party services (e.g. data providers, hosting) also need to be considered. Don't just cross your fingers and hope for the best! All types of licence, commercial or otherwise, need to comply fully with their terms (e.g. non-commercial use, one licence per server). Check what happens when licences expire or if limits are exceeded. The situation might occur when most eyes are looking at your organisation.

A lesser related issue is that your own site may be masking the server type quite well, but an error message like this can give the game away. Even if the message doesn't state the type of web server and operating system, another web site with the same message may provide the answer. This can help a malicious user who is probing the site for vulnerabilities.

Shortly afterwards, the normal East Coast Trains web site had returned; much sooner than you would expect if it needed a new licence agreed, purchased and installed. I'm still wondering if it was too many simultaneous users.

I'm hoping the fire is sorted soon so I can travel tomorrow morning, instead of this evening as originally planned.

PCI DSS and PA-DSS standards changes have been pre-announced by the Payment Card Industry Security Standards Council (PCI SCC).

Yesterday's announcement, which also includes notice of changes to PIN Transaction Security (PTS) requirements, provides a summary of the upcoming changes to v2.0 of PCI DSS and PA-DSS due in October 2010. Apart from increased alignment between the standards, the upcoming changes are meant to provide clarifications, additional guidance, new requirements and provide ways to improve organisations' flexibility to implement controls using a risk-based approach. There is also mention of a more forward-looking approach with guidance on managing evolving threats.

The indication that a risk-based approach is to be recommended for assessing vulnerabilities is a welcome change. This of course needs to be undertaken with a real regard of the risks to the business and its customers, clients and citizens, not just the data itself. The references to additional sources of good coding standards and vulnerabilities is encouraging.

The new standards are expected to be published on 28 October 2010 and will come into force on 1 January 2011. This will be quite a tight deadline for many operators to ensure they continue in compliance. The press release also includes details of upcoming meetings and webinars where additional information will be provided by the PCI SSC.

The UK Centre for the Protection of National Infrastructure (CPNI) have published new guidance on understanding and managing the risks from phishing and pharming.

Whilst most readers of this blog won't work on projects considered part of the national infrastructure, that doesn't mean you should ignore good, free advice.

The CPNI document discusses the threats and impacts (on employees, customers, clients and citizens), the modes of attack and possible countermeasures. I'm pleased to see that countermeasures to reduce the likelihood of successful attacks include both technical and cultural measures. Measures to mitigate the effects of successful attacks are also discussed.

Although some of the document is necessarily technical in places, the case studies in Appendix C should make sense to everyone. Remember, this is about business risk, not technical risk. The "I don't understand technical things" argument does not stand up.

Of course, assessing and implementing information security policies and controls is hardly ever simple or quick. But with the government's aim to reduce the number of different web sites this process may be a little easier. It's good to see such guidance, especially when the Central Office of Information (COI) has to date avoided the subject of security in its own web standards and guidelines. In view of the perception that the government isn't keeping up with threats (for example see the response to the petition to upgrade away from Internet Explorer 6), how are the CPNI phishing and pharming countermeasures being implemented by the government?

Knowledge about the degree to which the cultural countermeasures have been adopted within the government sector cannot be adequately measured from outside, and it would be good to see these included in work performed by the National Audit Office. Similarly most of the technical countermeasures would require privileged access to government networks (and permission!). However "use of SSL and TLS" and "signing of digital communications" should be easily observable, without doing any testing, from the outside world.

These two measures have security benefits beyond protection against phishing and pharming. They can assist citizens wanting to verify the identity of, and rely on the integrity of the information they see on what looks like a government web site, or receive in an official-looking email or other form of correspondence, perhaps during a national emergency. These types of event can attract themed phishing attacks for example. I haven't received any official government electronic communications recently apart from reminders from HMRC about tax deadlines and the like, so can't comment on how the sender and data integrity is verified. The tax reminders don't contain any sensitive data, and occur when there are known forthcoming business events or relate to actions undertaken by myself, so correctly don't need the same degree of verification.

But anyone can visit a web site, so what about those? Well, the CPNI web site appears to also be available over SSL/TLS as we'd expect. But, looking at https://www.direct.gov.uk using SSL (now more correctly called transport layer security, TLS) in the Chrome web browser, I was a bit surprised to see:

and this is the same for the prime minister's web site at https://www.number10.gov.uk/. Another possible primary governmental address is https://www.hmg.gov.uk which gives:

Maybe these have been deemed to be acceptable risks. But let's hope the other recommended countermeasures have been implemented.

Early last year I mentioned the security implications of the Web Content Accessibility Guidelines 2.0 and the scope for accessibility testing. I also spoke about whether an accessible web application be secure at the OWASP AppSec EU09 conference.

At that time, I found it fairly difficult to identify many web sites that were making WCAG 2.0 conformance claims.

The US Department of Justice is now seeking comments on proposed rule changes to the Americans with Disabilities Act that might make compliance to Level AA of WCAG 2.0 more widely mandated. A full analysis of the legal implications and timescales are presented on the Outlaw web site. As we see increased take-up in the US, it's likely similar levels of compliance will be required elsewhere.

In my conference presentation, I discussed how some security vulnerabilities could occur if WCAG 2.0 is implemented poorly.

The UK's Office of Fair Trading (OFT) promotes and protects consumers' interests by ensuring markets work well, and that businesses act fairly and competitively. The government has asked the OFT to develop a longer term national strategy for consumer protection and enforcement on the internet. The strategy is intended to promote a safe and vibrant internet market.

As part of this strategy development, the OFT has launched a consultation on E-consumer Protection. The objectives are to improve the effectiveness of online markets and increase the level of consumer trust, so that consumers have a real option to use the internet for transactions, as equally as any other channel. The aim is also to ensure that enforcement of consumer protection online is as good as anywhere else in the world.

The main consultation document outlines some useful statistics about the UK internet economy using data from the European Commission's Consumer Markets Scoreboard 2010, the OECD and the OFT's Attitudes to Online Markets (publication due shortly). For example, 71% of the UK's retailers use e-commerce/internet sales channel for retail, and internet/online accounted for 9.5% of UK retail trade (£38 billion) in 2009. Apparently UK consumers have a high level of trust in UK sellers/providers' protection of their consumer rights and that they are adequately protected. However, it is not all good news as almost 20% of UK internet users are not transacting online, with a third of these stating concerns about the security of their personal and financial information as the reason. Overall, two-thirds of all internet users are worried about unauthorised access to their personal information. There are also concerns about being conned by companies online. The consultation document outlines how consumers may be becoming complacent about security but that they lack awareness of issues such as mis-use of cookies and behavioural advertising.

The OFT suggests these problems reduce confidence, lead to lower levels of demand, and consequently lower levels of supply. Households can miss out on potential savings and this is especially problematic for low income households (LIH). The consultation document proposes that agencies should work together to empower consumers, promote business compliance and develop effective enforcement. It proposes a number of high-level actions under the themes of consumer education, tool provision and hardening, business information, cooperation and deterrence, and enforcement capability building, coordination and leveraging intelligence.

The outcome of this consultation will have a large impact on organisations in the business-to-consumer (B2C) sector (there is also some discussion of whether C2C should also be addressed). If you are an online retailer, perhaps get in touch with your trade organisation and ask them whether they are responding, or do so yourself.

There are five general response questions, and further more-detailed questions about the high-level actions and monitoring proposed. Responses can be submitted online, by email and by post. The consultation period closes on 13th October 2010.

This year I have mentioned web application security programmes, how software vulnerability testing recommended risk-based, application security programmes and generalised results from a survey about web application security programs.

But what are enterprises doing in real life and what are the issues? During the second day of OWASP AppSec Research 2010, Michael Craigue of Dell presented on Secure Application Development for the Enterprise: Practical, Real-World Tips. Although I missed it, people who did attend this track were enthusiastic about it and the video recording has now been published. I watched it last weekend.

Michael described Dell's 10-strong Global Information Security Services group and how it works with 3,000-5,000 developers in internal teams and how their appsec work is built on a published and maintained secure application development standard. Some of the problems encountered at Dell were platform diversity, security expert retention, the need to develop self-help documentation for the low and medium risk projects, lack of good metrics around security awareness training, high overhead of conventional threat modelling and the need to build security into the development lifecyle slowly, and in a business-focused manner.

At Dell, the project risk is calculated from ten factors including data classification, compliance requirements, whether it is externally facing, and the security knowledge of the development team. Interestingly, in the final questions from the audience, Michael mentioned Dell are using Open SAMM to identify gaps, measure how well their security programme is performing and to focus improvement efforts. Even projects that the group does not get involved with directly, are subject to quality checks and audit such as using Control Self Assessments (CSAs), which look for the artifacts required in the self-help documentation, even for low-risk applications.

There is another description of how software assurance practices at Ford in 2009, and recently published on US DHS's best practices web site Build Security In. The Ford programme is quite different. Every application security programme is unique because every organisation's culture, application and acceptance of risk is different.

What is yours like?

Until this week, I had thought this question would be answered by checking the vulnerability could be exploited and by determining whether there was any technical or business impact.

But I have just finished reading the Summer 2010 edition of Information Security Now, the quarterly magazine of the BCS Security Forum, incorporating the Information Security Specialist Group. One of the articles forced me to stop and think.

The article titled "Attack Spotting" describes the motivation for modern attackers and in particular attacks on application software. But the author introduces the idea of "non-vulnerability attacks". Just what might they be?

I was even more confused. I thought a vulnerability was any weakness that could be exploited by a threat (and a similar definition). The article's author goes on to describe that in "traditional vulnerability-based attacks", there is always the possibility of creating a signature to block the attack or of developing a patch for the application. In "non-vulnerability-based attacks" the author says there is no malicious payload and therefore it is not possible to create an attack signature or patch. The author helpfully provides three examples of non-vulnerability attacks:

• Brute force attack on authentication
• Web application vulnerability scanning
• Service flooding which exhaust server resources

No, no, no! These are all attacks against real vulnerabilities. These three are listed in Common Weakness Enumeration (CWE) (e.g. CWE-307, CWE-200 and CWE-410) and real examples are listed in Common Vulnerabilities and Exposures (CVE). The examples also fall into categories in the Web Application Security Consortium 's Threat Classification.

I have to disagree that these attack methods are new, and that they are not being detected. I may have misunderstood the article, but I believe there is plenty of guidance on building applications securely, security verification and for testing for these types of flaws. I also disagree with the article author's suggestion that the answer lies with expert systems to perform network behavioural analysis (NBA). Why bother? The application already knows right from wrong and doesn't need to guess. Implement application-based intrusion detection and prevention, on top of secure code, and benefit from very low false positives. At least, that's my view.

So, perhaps if it depends on your viewpoint. Maybe some traditional security folk see this other stuff as black magic? I hope not.

Mobile Web Application Best Practices has been published as a last call working draft by the W3C Mobile Web Best Practices Working Group.

Mobile Web Application Best Practices is intended to to aid the development of rich and dynamic mobile web applications. It includes guidance sections concerning application data, security & privacy, user awareness & control, (conservative) use of resources, user experience and handling variations in the delivery context.

The document defines "web application" as:

However it also states the 32 best practices are equally applicable to other kinds of web run-time, such as widgets and vendor-specific initiatives.

Unfortunately there is only one recommendation relating to security & privacy. If I had to choose just one security or privacy aspect to raise with mobile web application developers, I don't think it would be "Do not Execute Unescaped or Untrusted JSON data". From a business risk point of view, injection flaws would probably be my choice, and that may also be the same from the user's perspective. Worrying about privacy options is irrelevant if someone can steal all the information from the databases. Of course choosing just one is difficult but I believe additional, perhaps broader, guidance is needed here.

The W3C are seeking comments on the document which should be sent to public-bpwg-comments@w3.org before 6th August 2010. There are specific instructions for feedback from mobile web application implementers.

Visa Inc has released a guide to Card Data Tokenization Best Practices.

The intention is to provide guidance on using non-sensitive surrogate values (tokens) as a proxy for card data (typically the primary account number or PAN) by merchants, vendors, service providers and acquirers. This in turn can reduce where card data exists, and therefore the scope for compliance with the Payment Card Industry Security Standards Council (PCISSC) Data Security Standard (DSS). The guidance joins other information in Visa'a Cardholder Information Security Program (CISP).

The guidance describes Visa's best practices for the tokenization system, token generation, token mapping, the card data vault (the secure repository that maps tokens to cardholder data), cryptographic key management and the management of historical data.

However the guidance may not generally accepted and is being debated here and here, especially with regards to reversibility of the process and the use of salts when hashing, but Visa are seeking feedback on this first version, and have asked for responses by 31 August 2010 to be sent by email to inforisk@visa.com.