In October Securosis published a free paper concerning the security of "big data" systems.

Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments focuses on the security aspects relating to the specifics of "big data" that are different architecturally and operationally to other environments rather than the, also important, security of the applications themselves. Thus, consideration of how nodes and client applications are vetted before joining the cluster, how data at rest is protected from unwanted inspection, the privacy of network communications, and how nodes are managed are covered.

The paper discusses what "big data" means, and the particular architectural and operational security issues that arise. It then presents six recommendations.

If you are considering using social sign-on on your web site, a recent paper is worth reading

Discovering Concrete Attacks on Website Authorization by Formal Analysis by Chetan Bansal, Karthikeyan Bhargavan and Sergio Maffeis, discusses the required security goals and related web-based attacks. In particular it explores the issue of cross-site request forgery (CSRF) which can be amplified by using social sign-on where the user is authenticated by a third party social web site using protocols such as OpenID (Google) and OAuth (Facebook).

The paper presents some more advanced mathematics and undertakes a formal analysis to identify some known attacks and predict others.

Do read the paper, even if you skip through some of the analysis.

Applications that accept payments and are installed on consumer mobile devices, not used exclusively used for a single payment application, such as smart phones, tablets and PDAs have been excluded from the PCI SSC's validation programme Payment Application Data Security Standard (PA-DSS). These types of mobile payment acceptance applications are known as Category 3 - payment applications operating on any consumer electronic handheld device that is not solely dedicated to payment acceptance for transaction processing.

Mobile payment Acceptance FAQs, published in June 2011, recommended that Category 3 applications intended for use in the cardholder data environment are developed using PA-DSS as a baseline for protection of payment card data and in support of PCI DSS compliance, until the development of appropriate advice, guidance, and/or standards to ensure that such applications are capable of supporting a merchant's PCI DSS compliance. On Friday the PCI SSC published new guidance for developers.

PCI Mobile Payment Acceptance Security Guidelines v1.0 September 2012, describes firstly 3 objectives and guidance for application payment transactions:

1. Prevent account data from being intercepted when entered into a mobile device
2. Prevent account data from compromise while processed or stored within the mobile device
3. Prevent account data from interception upon transmission out of the mobile device

Secondly, guidance on 15 risks and controls in the supporting environment (mobile platform and associated applications):

1. Prevent unauthorized logical-device access
2. Create server-side controls and report unauthorized access
3. Prevent escalation of privileges
4. Create the ability to remotely disable payment application
5. Detect theft or loss
6. Harden supporting systems
7. Prefer online transactions
8. Conform to secure coding, engineering, and testing
9. Protect against known vulnerabilities
10. Protect the mobile device from unauthorised applications
11. Protect the mobile device from malware
12. Protect the mobile device from unauthorized attachments
13. Create instructional materials for implementation and use
14. Support secure merchant receipts
15. Provide an indication of a secure state

Recognising that no one party has sole responsibility for security of Category 3 applications, a table in Appendix B of the guidance suggests responsibilities for the 18 practices. The responsibilities are assigned to device manufacturers (e.g. Apple, Huawei, Motorola, Nokia, Samsung), operating system developers (e.g. Apple, Google, Microsoft), application developers (e.g. you?), and merchants as end-users or payment acceptance service providers.

The guidance also provides a list of ten additional sources of information to support the guidance. Further advice and standards on mobile payments are expected from the PCISSC in 2013.

In the next post, I will discuss some related updated guidance from Visa.

Do you have questions about password hashing, storage and cracking? What is current best practice?

There have been a number of thought-stimulating articles in recent weeks about password cracking. If you have not read these, I would recommend taking a look. Each is fairly short.

• Why Passwords Have Never Been Weaker — And Crackers Have Never Been Stronger (Ars Technica) on the current issues around use of passwords and the status of cracking
• Password Cracking, Part I: How Much Has Cracking Improved? (Joseph Bonneau) on why you need to measure both power and efficiency to quantify advances in cracking
• Password Cracking, Part II: When Does Password Cracking Matter? (Joseph Bonneau) on why password cracking threats are often different for real world administrators
• Common Misconceptions of Password Cracking (Robert David Graham) on what matters when you are deciding how to hash passwords

What should you do in practice? Keep an eye on this draft cheat sheet on password storage from OWASP.

All types of functionality should provide be as similar as possible across all delivery channels (e.g. phone, web e-commerce, mobile) and also when there are alternative versions for accessibility reasons (e.g. device constraints, user ability, environmental conditions). This is especially true for security controls where a weakness in one channel could undermine the security of all channels.

For example in authentication, either utilising passwords or some other method of validating identity such as certificates or one-time tokens, it must not be possible to bypass the controls altogether. Nor should it be possible to circumvent a security control in one channel, or mode, that is required in another. All channels should have an equal degree of protection.

This was recently highlighted in a description of how the well-used reCAPTCHA could be broken by a weakness in the alternative audio version. Many sites use the service to help prevent automated submissions of data such as for user registration, feedback, enquiries, and even limit higher-rate usage of a site.

The attack against the audio version, which output six spoken words and masked them with background noise from static-laden radio broadcasts backwards, relied on the finding that the background noise did not include high sound frequencies, and thus it was possible to extract the words for analysis. The attacker's clever analysis was made slightly easier in that they found reCAPTCHA accepted multiple spellings of the solutions for some phonetically-similar words, making the problem easier to solve. The issue has since been addressed.

So check those web sites, alternative versions, administrative interfaces, mobile apps and anything else that shares the same users.

Frank Stajano, at the University of Cambridge, Computing Laboratory, presented a new paper at the IEEE Symposium on Security and Privacy in San Francisco a week or so ago.

In his pre-event announcement he described how the paper outlines a framework for comparative evaluation of password replacement schemes. The paper examines the usability, deployability and security of different alternatives to passwords, and the difficulties of their replacement.

Infographic No.1 : Comparative Evaluation of the Schemes Examined.

A new paper has been published by Joseph Bonneau, Sören Preibusch, and Ross Anderson of the Computing Laboratory at the University of Cambridge, which estimates the difficulty of guessing 4-digit Personal Identification Numbers (PINs).

In A Birthday Present Every Eleven Wallets? The Security of Customer-Chosen Banking PINs, the authors describe the history of PINs, standards & practices, and present a model to quantify resistance to guessing. The authors examined data on human-selected 4-digit PINs from two data sources and provide an analysis of the likelihood of a thief obtaining a wallet containing a bank card, which also has date-of-birth data, being able to guess the PIN.

And the conclusions? Well, banks (and others) should implement a blacklist of simple PINs, and no part of a person's date of birth should be allowed in the PIN which really means moving away from customer-chosen PINs.

The UK's Centre for the Protection of National Infrastructure (CPNI) has updated its guidance on protecting business applications with the publication this month of a new document on developing and implementing secure web applications.

Development and Implementation of Secure Web Applications is a well-written and digestible 81-page A4 document arranged in seven main sections:

• Introduction to web application security
• General aspects of web application security
• Access handling (authentication, session management and access control)
• Injection flaws
• Application users and security
• Thick client security
• Preparing the infrastructure

It appears to replace the good, but somewhat dated document "Briefing 10/2006 - Secure web Applications - Development, Installation and Security Testing" created by their predecessor National Infrastructure Security Co-ordination Centre (NISCC), and issued in April 2006. The new document is more compact and focused, and I think I prefer it. Yes of course it is more up-to-date, and while it would be possible to argue why some things are included and not others, these others things tend to be explained further in the references. It's clear there is considerable overlap with information from OWASP and the Microsoft SDL, but I'm sure the reverse is true to an extent too.

It is very encouraging CPNI have taken the time to produce an updated document, but that probably reflects the types of risks facing their audience. I am especially pleased to see the section on infrastructure, since application security cannot be an island on its own. I would say the guidance is probably on the medium-to-heavy weight side of advice, but that is probably appropriate for critical national infrastructure, and the document does discuss threat modelling initially. It might seem overwhelming to some organisations new to the subject, and that might need some help on what to do first.

I think the document could perhaps do with more cross-referencing to additional information resources elsewhere. Yes, documents can always be improved, and I am sure we will find niggles and faults with use, but threats evolve and so does our knowledge.

In 2005, the US Federal Financial Institutions Examination Council (FFIEC) published Authentication in an Internet Banking Environment building on their earlier work on electronic banking. A supplement to the 2005 guidance has now been published.

The 2005 guidance recommended periodic risk assessments so that control mechanisms can be adjusted to respond to changing internal and external threats. The guidance stated that authentication techniques should be appropriate to the risks associated with the product or service, but that single-factor authentication is inadequate. It also recommended building customer awareness, and minimum supervisory expectations for authentication controls relating to high-risk online transactions involving customer information and the movement of funds to other parties.

On 28th June 2011, the FFIEC announced its Supplemental Guidance on Internet Banking Authentication to reinforce the guidance's risk management framework and update the expectations for authentication, layered security and other controls in an increasingly hostile environment.

The supplementary guidance reiterates the need for risk assessments and authentication for higher-risk transactions. It also recommends a layered security approach "since virtually every authentication technique can be compromised". Its recommendations for layered security controls include fraud detection & monitoring, dual device authentication, out-of-band verification, positive pay & debit blocks, transactional limits, activity limits, geo-location IP address reputation monitoring, policies & processes for handling compromised devices and malicious users, monitoring of account maintenance activities and customer education.

So, useful information, and not just for internet banking. The guidance is a good reference source for anyone considering authentication controls for access to more sensitive information.

Thank you to Alexis Fitzgerald for bringing this document to my attention.

Last Friday, I was going to travel to Oxford by express coach, but there had been a road traffic accident which had caused delays to the normally frequent service. After standing in a very long queue at Marble Arch for 10 minutes, and seeing one full coach go past, I decided to catch the train from Paddington instead.

The earliest "off peak" train was at 19:17 hrs and I was intrigued to see on the display boards "TV Entertainment in coach D". Fearing having to watch a football match for the whole journey, I boarded the train just after coach F, expecting that to be coach E. But no, it was coach D. Rather than some sort of large screen at the end of the carriage, I was surprised to see airline-style back-of-seat type displays, and sat down before the rest of the crowd arrived.

I thought a description of the user interface might be of interest to some readers of this blog, especially considering that apart from headset jacks, a screen power button, volume and brightness controls, all interaction is using the touch screen. The interface constraints, need to allow for train vibration and use by untrained public users affect what's possible.

The video on-demand in-train entertainment system is provided by Volo who suggest on their website the mobile payments are integrated by RingGo. I had a look at the safety video which had stop, start and pause buttons available like a conventional media player. The "try me" button let you navigate the juke-box of television shows categorised by genre. The interface felt like "CD multi-media" rather than "web browser". After a while the nag dialogue box popped up in a couple of permutations.

The adjacent passenger seemed to want to go further, but without a valid payment code, their attempt to "log in" was rejected.

The code entry field indicated the required format with underscores and hyphens once touched, and a backspace key appeared once the first character was entered. It did not seem to be possible to enter longer codes than required.

Entry of an invalid "login" code, led to a 20s delay (see countdown timer bottom right) before another attempt could be made, but there did not seem to be any limit on the number of attempts allowed. It is possible the payment code activation period is time limited as well as being for a fixed duration, and they might even be train-specific. Therefore the 20s delay could have been deemed sufficient to protect against guessing unused codes (brute force attack). I would be intrigued to see the risk assessment for the system. The codes could theoretically be tied to seat numbers, but the "special offer" at the cafe didn't seem to suggest you needed to know your own seat number, and that might put off people going for a day's duration to cover their outward and return journeys.

Presumably codes are issued in real time, rather than from prepared lists, so the system will rely upon a semi-continuous communication connection. But it is nice to know if you have a problem, they have "controllers" rather than "helpdesk staff". The code entry screen also reverted back to the main welcome screen after 60s of inactivity.

Without logging in, not much else seemed to be available to the adjacent passenger, but they did manage to get another slightly amusingly worded message screen when randomly tapping on the screen just after starting to watch the safety video once more.

So some interesting constraints on authentication and access control to deal with. Spelling aside, the resolution and related font size does make some screens a little cramped. Having an on-screen keyboard which is only numerical plus A-F does feel a bit techie, and maybe old-fashioned when people are used to much greater flexibility with touch devices. It might indicate the range of values for each code character, and thus reveal something about how it is generated? The touch screen appears to be the only method of user input—perhaps no other way to increase accessibility. Will it be a success? Hard to tell, but very few early-evening commuters seemed to be interested—many had smartphones, game consoles, netbooks, laptops and e-readers to hand, or were asleep.

Perhaps that is why there apparently weren't any power sockets available at the seats.

On the short journey, maybe passengers would be more tempted by live news, travel and weather, or even web browsing if mobile reception was poor, rather than old television shows. But on longer routes it will have greater appeal.