18 August 2013

Authentication

Posts relating to the category tag "authentication" are listed below.

09 October 2009

Website Password Requirements

Sometimes you read someone else's blog post and think "I wish I had written that".

Well, Jeremiah Grossman has blogged All about Website Password Policies which neatly sums up password policies for typical web sites and web applications.

While the process seems straightforward, organization should never take choosing passwords lightly as it will significantly affect the user experience, customer support volume, and the level of security/fraud.

The suggested policy is not for your online bank, but the sort of web sites most developers have to work on day-to-day. He also has a good brief explanation of how to store passwords in a hash digest form (but also read the associated comments).

I do think, however, that there is never a reason to have passwords stored in plain text—password recovery mechanisms can be built that do not need to send the actual password. But also, I agree with the comment that passwords truncation should be done with care and that allowing users to have longer pass phrases (containing space characters) can be beneficial. Let the user decide on what they are happy with, above the minimum standards.

My own password related posts are Is Password Complexity Too Complex to Implement? and Guessable Usernames and Passwords.

Posted on: 09 October 2009 at 10:15 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

29 September 2009

IP Address Restrictions and Exceptions

It's common for access to some web sites to be restricted to users from particular Internet Protocol (IP) addresses. This is usually in addition to some other identification and authentication method. But other IP addresses are often added to this "allow list" and these should not necessarily be trusted in the same way.

Photograph of a sign with an exclamation mark on a yellow triangle that reads 'Caution - Traffic management Trial - DO NOT MOVE' on a construction site boundary's wire barrier

In a typical scenario, a web site hosted on the internet that is used to administer another web application might be restricted to the company's own IP addresses. Then the developers say they need to check something on the live site, or another server needs to index the content, or someone wants to work from home for a while, or the site needs to be demonstrated at a client's location. All these additional IP addresses are added to the "allow list". These restrictions may be being applied at a network firewall, traffic management system, at the web server, in the application itself, in intrusion detection systems or in log analytical software, or in many of these. These are difficult to manage and in time there will be many IP addresses that no-one knows why they are allowed unless they are carefully documented, and subject to a fixed time limit when they are confirmed again by an appropriate person or removed. These extra addresses are quite often hard for someone else to guess.

However, there is another area where IP addresses are added to "allow lists", and this is for remote monitoring and testing services. These might be checking uptime, response times, content changes, HTML validation or security testing. The service providers publish the IP addresses of the source systems so that companies can specifically allow access to their web sites. Since the number of these services is relatively small, it's not too difficult to find which one might give access to areas of a web site or web application that the public (and malicious people) should not be able to get to. The particular danger here is that the IP addresses might be excluded from monitoring and logging, and therefore even a diligent web site manager might not realise for example the uptime monitoring service is making unusual, or excessive, requests.

Although it is not likely a malicious person is using this "trusted" address unless routing has been compromised as well, problems can go undetected, from what might seem to be a legitimate source. The IP address may have been typed incorrectly, or worse, the restrictions/exceptions may not have been implemented correctly allowing more addresses to have the privileged access than intended. Not logging a user's session is privileged access.

Allow traffic through, but be very specific what is allowed and monitor what's going on. Review all the exceptions periodically. Be especially careful about anything that bypasses authentication (such as allowing a search engine to crawl restricted-access content) on an otherwise public site.

Posted on: 29 September 2009 at 10:18 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

18 August 2009

Phishing Protection or Phishing Enabler?

A friend forwarded me a wine offer from his bank. But the email from his bank included additional information meant to verify the authenticity of the sender.

The bank included the last part of his postcode in the body of the message as well as his title and family name. If those were meant to be for verification purposes, why did it suggest he forward the email to someone else?

Partial screen capture of an email message showing the text inviting the recipient to forward the message to a friend with some words obscured 'Hello ************** Recommend ************** to a friend by forwarding this email to them and you could both be celebrating with 12 bottles of wine each.  Ask them to click on one of the links below and follow the instructions - simple! Find out more here.  So if your mates would be happy to receive this offer, forward this email and make a friend **************
************** P.S. We hope you enjoy your wine, but please drink it responsibly.'

Yes, the forwarded email has all the verification details embedded in it. No, it's not the username and password, but it's everything someone would need to construct a phishing email that would be very hard to distinguish from a real one.

Partial screen capture showing the start of the forwarded email which includes the verification postcode and account holder's name - if you're not sure what the postcode is, there's even a link to explain what the number and letters are

This has the feel of using a security measure as a marketing gimmick. Mixing marketing emails and those necessary for servicing a bank account is a difficult balance, but this is way off the mark.

Posted on: 18 August 2009 at 08:13 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

07 July 2009

Password Masking Update

Last week I highlighted Jakob Nielsen's advice on Password Masking, which I believe to be misguided.

Nielsen's Alerbox generated a wide-ranging discussion—in particular there are some excellent points of view at Web Security Mailing List, and a comment on this blog from Robert Campbell. I was surprised that "security guru" Bruce Schneier seemed to agree with Nielsen and this has been widely reported such as Usability and Security Gurus Agree That Masked Passwords Should Go.

Bruce Schneier now admits he was "probably" wrong The Pros and Cons of Password Masking. Good, let's hope that becomes as widely reported.

Posted on: 07 July 2009 at 12:34 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

26 June 2009

Don't Stop Password Masking

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

Password masking has become common for no reasons other than (a) it's easy to do, and (b) it was the default in the Web's early days.

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.

Let's clean up the Web's cobwebs and remove stuff that's there only because it's always been there.

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.

Posted on: 26 June 2009 at 08:43 hrs

Comments Comments (2) | Permalink | Send Send | Post to Twitter

16 June 2009

FTP is not an Option

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.

... [I] also put the info in the client file folders (actual paper client folders) for future reference and sometimes in Outlook business Contact Manager...

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.

Posted on: 16 June 2009 at 09:28 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

13 March 2009

What is Authentication Bypass?

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.

Photograph of the small red locker boxes, one unlocked and open

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.

Posted on: 13 March 2009 at 08:33 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

06 March 2009

Is Password Complexity Too Complex to Implement?

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.

Partial screen capture showing a change password form, asking for the current password, new password and conformation of the new password - dynamic grey text next to the new password field says 'Great' suggesting the password complexity is high

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:

Partial screen capture showing the same change password form after submission; the 'Great' password has been replaced with a red text 'Must be ASCII'

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.

Posted on: 06 March 2009 at 08:32 hrs

Comments Comments (1) | Permalink | Send Send | Post to Twitter

24 February 2009

Guessable Usernames and Passwords

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:

... The court documents list the username as "theblackstonegroup" and the password as "blackstone"...

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.

Posted on: 24 February 2009 at 08:58 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

19 December 2008

New OWASP Testing Guide

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.

Partial view of a page from the OWASP Testing Guide V3.0 showing 'Brief summary', 'Description of issue' and 'Black box testing and examples' headings for a control.

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

Partial view of a page from the OWASP Testing Guide V3.0 showing 'References - whitepapers' and 'References - tools' headings for a control.

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.

Posted on: 19 December 2008 at 09:43 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

More Entries

Authentication : Web Security, Usability and Design
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Requested by 107.22.70.215 on Saturday, 19 April 2014 at 23:06 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2008-2014 clerkendweller.com