I was surprised to see the latest advice Stop Password Masking from Jakob Nielsen.

Jakob Nielsen's has raised many usability topics in his Alertbox but he is not always correct. Although I used to read his column with an open, somewhat sceptical, mind I gave up some time ago*.

No, password masking isn't just some legacy design artefact. Like other design choices relating to user identification and authentication, these have a significant impact on user trust and data privacy, confidentiality and integrity. It is wrong to suggest that masking should be removed by default. By all means inform users of the risks and let them choose to display the characters being typed, but don't have this status set by default. More-and-more web sites are being accessed away from home, and being overseen by other people or surveillance equipment is commonplace almost everywhere.

On e-commerce sites, the need to log in can often be removed completely, or made non-compulsory. Too often security controls are applied for other reasons, such as to generate information for sales and marketing reports, rather than to ease the purchasing process. For more critical data, the use of authentication mechanisms other than static passwords should be considered.

* I stopped reading Alertbox after Jakob Nielsen became very defensive about his training material only being available on DVD and not VHS tape, as many people had requested. His argument was that DVD players were so cheap, people should upgrade. Yet at the time, he was promoting the idea that web sites would render in all browsers—including old legacy ones.

Update 7th July 2009: Password Masking Update.

Many websites are updated using File Transfer Protocol (FTP). Don't do it.

A discussion thread How Do You Store FTP Login Information For Your Clients? highlighted what common practices are, but almost entirely missed the issues of transfer of login credentials over unencrypted channels, privileged access to the whole of the server, account sharing, password and user management.

It's no surprise that some of the most serious hacks are suspected of being undertaken using compromised FTP accounts.

FTP is not an option. Ask your hosting company or systems staff to disable FTP services and block all traffic to/from your web servers on TCP ports 20 and 21, at your network firewall.

Authentication bypass is when someone can get to restricted-access resources (data, files, functionality, etc) without approval.

As an example, my gym has issued me with a membership card. Each time I visit, I have to run the card through a reader that checks it is still valid, not already used by someone inside the gym and then lets me enter. My photograph is also displayed briefly to the reception staff so they can check if the person with the card is the same as the member.

But my gym has recently introduced some security boxes—small lockable stores for valuable items such as wallets, mobile phones and keys—located in sight of reception staff. To use these, you give your card to reception, they issue you with a key for a box and manually override the entrance gate.

It's possible that in this procedure the are no longer checking the card is valid, or that the stored photograph matches the person with the card. This would allow unauthorised access to the gym by anyone with a found, stolen or borrowed membership card. Similarly, walking through an open fire-escape door would achieve this.

So, why is this an issue for web application security? Many web sites start out with everything being freely available. It's usually not long before user registration, newsletter sign-up or customer-only requirements turn up. These are often added on, without proper consideration of how the authorisation processes will be applied consistently and thoroughly across all resources. It is not uncommon to find a login screen that provides access to, say, file downloads that can be accessed without signing in.

So the first step should be to identify all resources which have to be protected, and what people or groups can access them, under what conditions.

Enforcing complexity is one aspect of a good password policy. But web applications often implement this poorly.

Yesterday I had to change a password on a web application provided by an information security vendor. You'd think they'd have this sorted. It began promisingly:

• the page was only available on a page transmitted over secure HTTP
• the page was only available to currently authenticated users
• there was an explanation of the minimum password complexity requirements
• the form asked for the current password
• the form asked for a new password and provided a visual indicator of the password complexity (length and mix of characters)
• the new password wasn't allowed to be blank(!)
• confirmation of the new password was sought
• password fields were initially all blank and masked as you typed
• the submission was sent by the post method over secure HTTP
• the session was ended (forced log out) and the account locked after multiple failures to change the password correctly

Also, the form had some helpful client-side JavaScript validation—but did not rely this and, correctly, was also undertaken once submitted to the web server.

The client-side validation even included an indicator of password complexity. But I was surprised when my "great" new password was rejected apparently because it did not contain solely ASCII characters:

Well, I can assure you I did use ASCII characters. In this case the client-side and server-side validation are not identical. This suggests that there may be contradictory requirements in the specification or the validation has been implemented incorrectly, and there was inadequate testing and verification undertaken.

This is a usability error, and a potential security vulnerability.

A small issue, but it demonstrates how easy it is to have faults in applications. This may not have an impact on the application's security, but it would be an area a malicious user would explore further to see if the weakness could be exploited.

Did they or didn't they (share user credentials)? Abuse of copyright? Bad information security practices? Breach of contract? Poor authentication controls? It's all going to court soon.

The case is explained in a Reuters blog posting Financial Times finds new way to save newspapers and in SC Magazine's article FT sues Blackstone Group for sharing premium account login details .

It seems FT.com doesn't enforce password complexity:

Therefore, I suppose it could be argued that the username and password were guessed and used by third parties. Since it's probably not difficult to predict other FT.com clients, this information gives clues to what other login credentials might be. Known usernames are an essential starting point for breaking into web applications and when combined with passwords which can be broken by brute force, mean there is very little protection here.

A report by Pinsent Masons Firm sued over multiple use of individual's FT.com login also suggests that a discussion on "unique cookies" will also come into the case. Let's hope the court takes time to understand the possibilities for use and abuse.

Version 3 of the Open Web Application Security Project (OWASP) Testing Guide has been released after a 6-month period of addition, enhancement and review.

The OWASP Testing Guide is an ideal reference for both developers and testers—version 2 was fantastic, and this new version is even better. The testing framework now covers 66 controls and, like in the previous version, each control has a brief summary and is described in detail followed by black box (no additional knowledge) and grey/gray box (partial knowledge) testing methods and examples where appropriate.

The controls and testing methods are fully referenced to provide additional guidance and explanation.

The controls are grouped into ten categories, including new separate categories "Authorization" and "Configuration Management". I'm especially pleased to see the latter broken out on its own, since even a perfectly coded application can have vulnerabilities introduced during deployment and changes to the application.

The OWASP Testing Guide now also includes a "best practice" penetration testing framework and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues. More information is available on the Testing Project pages.

Functions to unsubscribe, be removed, cancel or opt out from newsletters, mailings and email alerts can be used to undermine web site security.

Many techniques are used to unsubscribe including:

• Email message to a particular address, possibly with a keyword like "unsubscribe" in the subject or body
• One click opt out unsubscribe hyperlinks
• Hyperlink to a form with additional validation
• Log into an account management area to make a change to communication preferences
• Pre-paid response postcard
• Telephone call to a helpdesk.

Some examples from email alerts are shown below:

It is important to make it simple for people to opt-out of such services, but there are a number of problems that can get built into such systems:

• Hyperlinks that only pass an email address as a parameter can be used to find whether particular addresses (such as known individuals) are registered/subscribers - this could be used for user name enumeration if there is a separate log in area and the user names are email addresses
• Hyperlinks with only predictable identifiers can be guessed
• Systems could be used maliciously to unsubscribe other people's accounts
• Hyperlink options could automatically log people in to their accounts - this should not occur since the links could be accidentally forwarded on to other people
• Any validation (authentication) systems must be at least as secure as other functions such as log in to access account details, so that the unsubscribe facility cannot be used to obtain log in credentials (e.g. limit the number of attempts possible, log failed attempts, lock accounts, add delays to failed attempts, etc)
• Unsubscribe by hyperlink or email must have the same level of checks (not more or less) as non-electronic means (telephone call, written, etc) otherwise the weakest method could be used by a malicious person
• Text-only versions either not including or not rendering the unsubscribe hyperlinks correctly (e.g. wrapping the link), so that only rich-text email users can see and use the links
• Anything sent by email is normally not considered secure
• Do not give away any other sensitive information on either successful, or unsuccessful completion (e.g. "Thank you Margot Dyson, we will send a letter to your address in Hastings to confirm this request")
• Clearly distinguish between opting out of particular correspondence, types of contact (e.g. direct marketing), all correspondence and closing accounts altogether - you may have to contact the person for some other valid reason.

In all cases, the completion of unsubscribing should be accompanied by a message to the person informing them of the change of status (by email or some other method). Where this hasn't closed their account, and they can log on to undertake other processes, the event should also be recorded for them to see in a list of recent actions.

The login usernames and passwords for access to the server(s) hosting your web site or application must be protected. If someone has access to your web site's files or the server's operating system, they can potentially alter, delete, copy or add anything they want.

This means every person who requires access having a unique login, and the process of identifying the person and authentication should occur over an encrypted channel (e.g. virtual private network (VPN)). Conventional file transfer protocol (FTP) should never be used, and the service should be disabled or uninstalled in the same way as any other un-necessary service. The FTP log in process is not secure and can lead to the details been stolen and sold to criminals.

Put restrictions on as many of these as possible:

• Who can log in
• What they need to know/have/be to log in
• From where can they log in
• What they can access once logged in

Passwords should be forced to expire, be complex (e.g. length, mixture of case, alphanumerics) and do not allow password re-use (changing a password back to one used recently). Ensure you:

• Change all usernames and passwords when your web site goes live
• Log all failed and successful login attempts
• Log what is done by users
• Review the logs frequently
• Review all user accounts periodically and their permissions
• Revoke accounts promptly which are no longer needed

Watch out especially for accounts used by external or temporary staff, as these can sometimes be forgotten about. Avoid giving access if you can - upload approved modifications yourself for example - at least you will have a record of what has been altered.

I'll include one of my favourite illustrations: the ICRA (formerly the Internet Content Rating Association) web content label generator tool, allows you (or your developers, designers, etc) to give ICRA your own FTP details:

"What happens next?" indeed.

Being able to identify users is a vital part of securing data. In practice too little or too much authentication information can be a problem.

In my posting last week on Personal Information Healthchecks Help Everyone I mentioned how the Which? Current Account Best Buy 2008 bank Smile were setting a bad example. David Lacey raised some good issues in Card fraud up - it's no surprise on his IT Security Blog where he discussed the need for mutual authentication between banks and their customers.

I have come across many banks, building societies, insurance companies, pensions funds and other organisations that phone their customers and ask for detailed sensitive information without authenticating who they are. Yes, banks regularly do this - especially when they suspect fraudulent use of your credit card or current account, but they have not thought how to prove their own identity.

But organisations often ask for too much information "for security reasons". This is getting rather like the catch-all "for health and safety" argument for petty issues or those that just require some good management. I have requested copies of bank leaflets by telephone that are readily available in their branches, but have been asked to provide account information. If I walked into the bank's branch, surely I could take a leaflet from the rack without providing details to identify who I am? Yet many web sites take this course as well, asking for all sorts of personal information to join an email list or to provide access to a document. I can understand some need to collect marketing data, but for example is a person's date of birth or full postal address really necessary? It is possible these may be used for later authentication, but it's often not clear.

When reviewing data controls, I like to think about:

• What information is being collected
• Why it is being collected
• What it will be used for
• How it will be looked after and destroyed at the end of its life
• If the data owner agreed to the above

Remember to explain to web site users why you are collecting particular data, like this good example from Classic FM:

Try to reduce the amount of data collected and stored - it's easier to manage it then, and you can't lose it.

It is not usually necessary to apply the same level of authentication to all types of data. Try to differentiate between security and marketing when asking web users to register. The security aspects are used subsequently to identify and authenticate someone - giving them access to data, processes, resources, and so on which other people are not allowed to access. Separately, marketing data might be used to analyse enquiries, to identify opportunities or to contact the person again.

An important setting in any web application is how long to allow a user to remain logged in, before timing out automatically, after a period of inactivity.

Long periods (greater than an hour) are not usually recommended, although some web sites like Amazon and Facebook do this to improve "user experience" (and reduce protection).

Session time outs are a protection mechanism for users who leave their computer unattended, or who walk away from a shared computer without logging out of an application. After the time out period, the user has to log in again. This is somewhat like a password-protected screen saver which starts after a number of minutes of inactivity on a computer.

But what session time out should be used? The Open Web Application Security Project's Development Guide suggests:

20 minutes is a good starting point, but a longer period may be advised where users have long forms to complete or have large amounts of text to read or write. In these cases, it may be worth considering mechanisms to extend the time out for particular pages, and provide a warning to the user of the approaching time out. The types of users and their web experience are also factors in this. Generally 20 minutes should be seen as a maximum, and anything greater than this needs to be assessed carefully. If you can, try 10 or 15 minutes.

It may be appropriate to let the user choose their own time out (within limits), so if they perhaps log in from their own personal computer at home the period is longer, but from a public computer (for example in a library or cafe) or via a shared connection on an untrusted network (for example WiFi on public transport), the period is shorter.

If you have longer session time outs, be aware of the additional risks and make sure you ask users to re-authenticate when more-sensitive requests are made (e.g. changing account details). Amazon does this by asking you to log in again when going to the check out and payment.

Of course, how you time someone out, how you terminate the session and what they see are also important.