- Email: [email protected]
Password practices on leading websites – revisited
FEATURE
Password practices on leading websites – revisited
Steven Furnell
Steven Furnell, Centre for Security, Communications and Network Research, University of Plymouth, UK Passwords are perhaps the most maligned example of security technology. People very readily dismiss them, and there is a good degree of evidence to support their reasons for doing so.1 However, while fully acknowledging that they have inherent limitations, the extent of the problem is arguably worse than it needs to be. Fundamentally, it is not impossible to use passwords more effectively (at least up to a certain threshold in terms of the number of them to be managed). The challenge is not so much the technology, but getting people to use it correctly. However, we must equally recognise that users’ natural behaviour will not necessarily be the correct behaviour, and so efforts need to be made to guide and shape it accordingly. When looking at password usage today, one aspect that is clear from the outset is that, while some sites and services have moved to supplement or supplant it with alternatives, the approach still reigns supreme. Similarly, when lists of common passwords are published, many of the old favourites are still prominent (suggesting that long-established guidance still isn’t finding its audience in an effective manner), and indeed further reports indicate that people have become no better at using passwords more generally.2,3 A timely illustration of this is provided by an incident reported while this article was being written, with the exposure of celebrity photos stored on Apple’s iCloud. While initial speculation suggested hacking of the service itself, Apple was quick to report that the actual cause was targeted attacks against accounts with poorlyselected passwords.4 With such problems in mind, it is relevant to consider the way in which password practices are encouraged and enforced December 2014
on leading websites. This study follows on from prior assessments performed in earlier years, with the original conducted in 2007 and a follow-up in 2011.5,6 The intervening period has seen increased attention towards non-password-based authentication through initiatives such as DARPA’s call for research into active authentication in early 2012, and the launch of the Fast IDentity Online (FIDO) Alliance just over a year later.7,8 Nonetheless, passwords remain dominant and, as such, it is timely to examine what has changed in the three years since the last assessment.
Website selection and assessment methodology As with the earlier versions of the study, the sites selected for assessment were iden-
tified from Alexa’s global list of ‘The top 500 sites on the web’ (see www.alexa.com/ topsites). The sample was taken in midAugust 2014, with the assessment targeting English-language sites and ignoring any regional variations of the same brands (eg, with Google.com already topping the list, high-ranked sites such as Google. co.in and Google.de – ranking at 13 and 24 respectively – were excluded). Also excluded were any sites that relied on the same login mechanisms as a site already benchmarked (eg, YouTube, ranked at number 3, and Blogspot.com, ranked at number 17, both used Google account login, while Bing at number 23 used the same credentials as Live.com). This yielded the set of sites listed in Table 1. Of these, Amazon, Facebook, Google, Microsoft and Yahoo have been consistently present in all three versions of the study, whereas other sites have come and gone. Bebo, Friendster, MySpace and YouTube had all disappeared in the 2011 version, although YouTube’s exclusion was
Site
Alexa ranking
Description
Google
1
Web portal.
Facebook
2
Social networking site.
Yahoo!
4
Web portal.
Wikipedia
6
Web-based collaborative encyclopaedia.
Twitter
7
Social networking and microblogging service.
Amazon
10
International online retailer.
Microsoft Live
11
Web portal.
LinkedIn
12
Business/Professional networking site.
WordPress.com
25
Open source blog tool and publishing platform.
Pinterest
26
Online pinboard
Table 1: The 10 most popular websites selected for assessment.
Computer Fraud & Security
5
FEATURE
Figure 1: Password instructions on Microsoft Live during sign-up.
due to it having been acquired by Google and consequently using the same login approach, rather than as a result of a drop down the Alexa rankings. By 2014, the only notable difference in the list is that eBay has now disappeared from the table as well, with Pinterest having ranked just high enough to make the cut ahead of it – eBay’s Alexa ranking was actually 27th at the time of the sample. As with the earlier studies, although 10 sites does not constitute a high-volume sample, it does capture a group of leading and well-recognised services whose password practices are likely to influence a significant community of end-users. In addition, other providers may see them as a standard against which to set the provisions on their own sites. For the evaluation, user accounts were created on the sites in order to determine the password selection requirements. The passwords were then updated using the available change and reset procedures. More specifically, each site was assessed to determine whether: UÊ ÌÊ«ÀÛ`i`Ê>ÞÊ}Õ`>ViÊÊÊÀi>ÌÊ to password selection, and (if so) the extent of the coverage. UÊ ÞÊÀiÃÌÀVÌÃÊÜiÀiÊ«Ãi`ÊÊ«iÀmissible passwords, in order to reduce the user’s potential for making poor choices (this included prevention of the user’s surname or user ID as their password, the prevention of the use of the word ‘password’ itself, prevention of dictionary words, and some requirement for users to compose their passwords multiple character types). UÊ Êi>ÃÊÜ>ÃÊvviÀi`ÊÌÊÀiÃiÌÊÊÀÊ recover passwords, and (if so) the process involved. UÊ / iÊÃÌiÊ«iÀÌÌi`ÊÌ iÊÀiÕÃiÊvÊ old passwords. 6
Computer Fraud & Security
UÊ Ê«>ÃÃÜÀ`ÊÃÌÀi}Ì ÊiÌiÀÊÜ>ÃÊ«Àvided, and if so, how it worked. UÊ / iÀiÊÜ>ÃÊ>ÞÊi>ÃÊvÀÊÕÃiÀÃÊÌÊ supplement their passwords with additional protection – eg, via one-time passcodes sent to their mobile device.
Provision of password guidance The first element of the evaluation examined whether the sites provided their users with any guidance on good password selection and/or management practices. The assessment here was looking for something more tangible than simply providing messages that indicate the password requirements that are being enforced. While such messages are clearly useful, they do not necessarily serve to provide any related advice. For example, Facebook asserts that, “Your password must be at least 6 characters long” if the user tries to submit a shorter one. Meanwhile, Microsoft Live does not provide any explanatory guidance around password selection, but details Site
of the enforced restrictions appear when the password box is in use, as shown in Figure 1. Neither of these examples are considered to qualify as guidance, as they indicate what the user is expected to do, but do not help them to understand why. As such, it is relevant to take a look at what further support is present, and Table 2 indicates whether or not any guidance was provided at each of the key stages where it would have been relevant. This in itself paints a fairly revealing picture, with only a single site (Google) providing users with access to password guidance at all points where they might actually benefit from it. It should be noted the table does not assess the extent or quality of the guidance, and in practice it can be observed that this was variable. As an example, while Google has a link available to substantive password guidance at all stages, LinkedIn’s offering (available during password change or reset) was limited to a statement indicating that “A good password should contain a mix of capital and lower-case letters, numbers and symbols”. While this can still be classed as advice, it is clearly of a rather minimal nature. Providing guidance is one thing, but it does not necessarily mean that sites will require users to follow it. Indeed, using Amazon as an example, when it finally gets around to providing some tips (at the password reset stage – see Figure 2), it still
Guidance provided Sign-up
Password change
Password reset
Amazon
✗
✗
✓
Facebook
✗
✗
✓
Google
✓
✓
✓
LinkedIn
✗
✓
✓
Microsoft Live
✗
✗
✗
Pinterest
✗
✗
✗
Twitter
✗
✗
✓
Wikipedia
✗
✗
✗
WordPress
✓
✗
✓
Yahoo!
✗
✗
✗
Table 2: The provision of password guidance across each of the sites.
December 2014
FEATURE does nothing to actually ensure compliance, and indeed allows all of the things it advises against.
Enforcement of password restrictions Given that guidance alone may not work (and it is often absent in any case), it is relevant to assess the degree to which password restrictions are actually enforced, as this ultimately reflects the quality of the passwords that users are permitted to choose. With this in mind, Table 3 summarises the restrictions that are enforced during initial registration. The passwords selected at sign-up are particularly important insofar as none of the sites ever enforces password expiration by default, and so the user’s initial choice could persist for years. (As an aside, the Microsoft Live site was unique in giving the user an option to make the password expire, with a tick-box “Make me change my password every 72 days” being offered during password change – but not at initial sign-up or password reset). Another point worth noting is that the aspects enforced at sign-up are not necessarily the same at other stages (as discussed further below), and so it should not be assumed that the restrictions presented in the table are applied consistently for the password update and reset aspects in each site. The rightmost colSite
Figure 2: Amazon password tips – provided but not enforced.
still makes no attempt to enforce good practice beyond having a minimum password length (and even this was absent in the original 2007 assessment), while Wikipedia still only prevents the use of the user ID as the password. Meanwhile, the sites that appeared the strongest in the earlier studies (eg, Google and Microsoft) have remained so in the latest version, with some further improvements also being noted (eg, Google now prevents the use of surnames, and Microsoft Live prevents password reuse). The most notable case of improvement since the last evaluation appears to be from Yahoo, with the password length minimum have increased from six to eight, and the checking having been hardened to prevent dictionary
umns of the table indicate whether there are any supporting features in terms of password strength ratings (again, specifically reflecting provision at the sign-up stage), availability of extra protection such as two-step verification, and prevention of password reuse when users later change or reset their passwords. In most cases the table presents a clear indication of whether sites pass or fail in relation to each criterion. However, there are some cases in which partial compliance is recorded (denoted as ~), and these are explained as the discussion proceeds. For some sites that were present in earlier versions of the study there is not a lot of progress to show over the seven-year period. For example, Amazon
Restrictions enforced at sign-up Enforces min length
Prevents Surname
Prevents User ID
Other support Prevents ‘password’
Enforces Prevents composition dictionary words
6
✗
✗
✗
✗
✗
Facebook
6
✓
✗
✗
✗
✗
Google
8
✓
✓
✓
✗
✓
LinkedIn
6
✗
✗
✓
✗
Microsoft Live
8
✓
✓
✓
Pinterest
6
✗
✓
Twitter
6
✗
Wikipedia
✗
WordPress
Amazon
Yahoo!
Password meter ✗
Extra protection
Prevents reuse
✗
✗
✓
✓
✓
✓
✓
~
✗
✗
✗
✓
✗
✗
✓
✓
✓
✗
✗
✗
✗
✓
✓
✓
✗
~
✓
✓
✓
✗
✓
✗
✗
✗
✗
✗
✗
6
✗
✓
✓
~
✓
✓
✗
✓
8
✓
✓
✓
✓
✓
✗
✗
✓
Rating s
Table 3: Enforcement of password restrictions and provision of additional support across the target sites.
December 2014
Computer Fraud & Security
7
FEATURE scored a pass, but the blocking of only one would give a partial pass. In addition, if either or both were blocked then a few additional words were then used to further Figure 3: An example of the auto-generated strong password from WordPress. test the limits of the filtering process. In some cases, the two choices would be UÊ 9> tÊ>VVi«Ìi`ʼ*>ÃÃÜÀ`£½Ê>ÃÊÌÊiÌÊ automatically prevented as a result of the words, enforce character composition, the composition criteria of including length or composition rules. For example, and prevent reuse. a number and an uppercase letter. Microsoft Live requires at least two charLooking at the first few columns in In terms of enforcing password composi- acter types, and so typing the word in all Table 3, the nature of the restrictions tion, the basic requirement to get a tick lowercase would be blocked, but varying being tested, and the associated findings, in Table 3 was whether a site required the the case (eg, ‘Diamonds’) was permitted. are fairly self-evident. However, although use of more than one character type – ie, Meanwhile, in Yahoo’s case the basic use of it is relevant to observe that preventing upper or lower case alphabetic, numeric, or dictionary words is more fully prevented the use of the user’s surname as a passspecial/punctuation characters. As can be by the requirement to include a number word is only feasible if sites collect this seen, this in itself was relatively rare, and it and so it scores a pass on this criterion. information as part of the enrolment is also worth noting that none of the sites However, it can be noted that a noneprocess – not all of them do, and so too-inventive variant such as ‘diamonds1’ some fail this criterion by default. For the enforcing composition explicitly required the use of non-alphanumeric characters. would still be accepted. Twitter scored a other restriction-related columns some WordPress was a special case in the sense partial pass in this case because, while it filfurther discussion is relevant to explain tered some dictionary words (eg, ‘monkey’, the details. The first such issue is whether that it made decisions on the basis of a combination of composition and length. ‘secret’, ‘diamond’ and ‘computer’ were sites prevent the use of ‘password’ as the Specifically, shorter passwords needed to all blocked), the string ‘diamonds’ was password, and at the surface level the have a combination of character types still accepted. Similarly, LinkedIn blocked table suggests a reasonable degree of suc(eg, diamonde would be rejected as too ‘monkey’ (as with ‘password’, it appeared cess (with 7/10 sites doing so). However, weak, whereas ‘diamond!’ was accepted), to accept it initially, but forced a change the evaluation itself went a little further but longer ones could be a single character at first login), but accepted ‘diamonds’. than this and sought to discover whether type (eg, ‘assessment’ was accepted). As WordPress blocked all of the aforemenobvious variants such as ‘password1’ and ‘Password’ were acceptable. The following such, it would be most accurate to say that tioned words as being too common, but it enforces a minimum acceptable passthe word ‘dictionary’ was then accepted examples illustrate that some of the sites word space. WordPress was also unique (which seemed somewhat ironic!). that blocked ‘password’ do not take their among the sites under test for offering an Google was resilient to all of the precedchecking too much further: option to automatically generate a strong ing options, but was ultimately found to UÊ i`Ê>««i>Ài`ÊÌÊ>VVi«Ìʼ«>ÃÃpassword, which would in turn utilise all accept ‘Dictionary’, which was rated ‘Fair’ word’ as a valid choice at signup, of the aforementioned character types. by the password meter. but yielded a demand for password Finally, having commented upon the change on the first attempt to sign in However, a potential downside of this otherwise helpful idea is that the passwords general paucity of password guidance, it is with it. The use of ‘password1’ was also rejected in the same way, but the that are generated may not actually be very worth noting that some of the prompts/ memorable (as illustrated by the example messages that appear in relation to the choice of ‘Password’ was accepted in Figure 3). password restrictions are (sometimes) at without further challenge. least partially informative. For example, UÊ *ÌiÀiÃÌÊLVi`ʼ*>ÃÃÜÀ`½]ÊLÕÌÊ on WordPress, if you try to use ‘pass‘password1’ was acceptable. Permissible words word’ as the password there is a resulting UÊ /ÜÌÌiÀÊ``ÊÌÊ>ÜÊ>ÞÊvÊÌ iÊ prompt indicating that “Your password is aforementioned choices, but ‘passThe permissibility (or otherwise) of dicone of the most common passwords used word2’ was accepted (with the mestionary words was principally assessed by on the web. Try something a little more sage “Password is okay”). The string using the strings ‘monkey’ and ‘diamonds’ unique”. Meanwhile, Twitter’s response ‘passwo’ was also accepted (for users (the former was chosen because of its wanting to be obvious, but too lazy apparent prominence in lists of commonly in the same situation is a message stating “Password is too obvious”, which is a little to even type the whole word!). used passwords, while the latter was an less informative about why. The feedback UÊ 7À`*ÀiÃÃÊÃÕVViÃÃvÕÞÊLVi`Ê example that would satisfy the longer ‘passsword1’, but ‘Password’ and minimum length thresholds of some sites). messages can be similarly vague in relation to passwords that are permitted. For ‘password2’ were both acceptable. If both of these were blocked then the site 8
Computer Fraud & Security
December 2014
FEATURE example, staying with Twitter, while it accepted the dictionary word ‘diamonds’ as a valid password, it did also indicate, “Password could be more secure”. From a guidance perspective, the problem here is still that it is only going part of the way; it is flagging the weakness, but not giving any indication of how the user might address it – ie, what does a ‘more secure’ password look like?
Enabling password reset or recovery In common with the 2011 version, a positive observation from this study was that all of the sites offer reset rather than recovery in the event of a user forgetting their password. This is significant in terms of the implications if the ‘forgotten password’ process was to be exploited by an attacker. Given the recognised tendency to use the same password over multiple accounts, the risk of a recovery option is that it could inadvertently expose credentials that could then be used elsewhere. Meanwhile, an impostor performing a password reset would serve to alert the legitimate user to the compromise of their account, as their expected password would cease to work. Back in 2007, two of the 10 sites were sending the current password to the registered email address (which was clearly a risk if this account had been compromised), and it is good to see that the practice has not returned. Having said this, the password update page of the Twitter site nonetheless made a rather misleading claim in this respect, indicating that you can “Change your password or recover your current one” (see Figure 4). Moreover, clicking on the ‘Forgot your password?’ link then claimed to send a reminder. However, what it actually did was to send a password reset link to the registered email address.
Figure 4: A false impression of offering password recovery rather than reset.
presented to the user was not conveying an accurate impression of what was going on. For example, Figure 5 presents the password change interface from Facebook. While this all looks perfectly sensible on the basis of what appears to be shown, it is actually less so when one realises that Facebook does not actually trap dictionary words (eg, ‘monkey’, ‘secret’ and ‘diamond’ were all accepted without question). What is actually being blocked in Figure 5 is an attempt to use the user’s surname as the password. Another example is provided during the password change process in Yahoo. Attempting to reuse a previous password choice (a string ending in 12) yielded a message saying, “Your password is too similar to one you’ve used before”. While this seems fine, it was then found that ending an identical string with 13 rather than 12, or indeed omitting the number altogether, resulted in acceptable choices. As such, contrary to the message, the site only appeared to be checking for exact matches to previous passwords and not for similarity.
A further (and potentially more problematic) category of misleading messages is arguably the feedback that users might receive from password meters. Although offering a meter and some sort of rating clearly has the potential to make a useful contribution, the behaviour of the meters themselves was not exactly consistent between sites. While this version of the study did not seek to specifically document the rules by which different meters awarded different ratings (for those interested, the 2011 study did document this for the sites under test at the time), there was clear potential for different sites to give different ratings to the same password, as well as for certain choices to be overrated in terms of the strength offered. Indeed, others have made similar observations, to the extent of dismissing the meters as mere “eye candy”.9 While this may be a bit harsh in some cases, it would certainly be desirable for these approaches to be strengthened where possible, which in turn calls for some standardisation in the use of underlying password metrics.10
Misleading messages There were a few other occasions during the evaluation when the information December 2014
Figure 5: Implying a prevention of dictionary words when preventing the user’s surname.
Computer Fraud & Security
9
FEATURE
Vive la difference? Another observation worthy of call-out is the surprising number of variations that exist within the same sites, with different behaviours observed at sign-up, change and reset stages. This was actually true for the earlier studies as well, and the discussion here aims to give a sense of the inconsistencies. Indeed, a couple have already been observed in the earlier discussion, such as Microsoft Live’s option to set a 72-day limit on password usage only being present if the user elects to manually change their password in the first place. Similarly Table 2 has already presented evidence of significant variation in whether or not sites provide any password selection guidance, with half of the sites exhibiting inconsistency in this regard. Specifically, some sites provide guidance at sign-up but not at password change (or vice versa), while three sites only provide guidance at the password reset stage. Although the latter context provides a more overt justification for needing guidance (ie, users have already demonstrated their ability to forget their previous choice, and so may require assistance to choose something more effectively), it clearly does not preclude the value of providing guidance at other stages as well. In addition to the above, further differences can also be observed in terms of the password restrictions, feedback messages, and use of password meters: UÊ 7 iÊÃiÌÌ}Ê«>ÃÃÜÀ`ÃÊ>ÌÊÃ} up, Yahoo! requires that they meet a series of length and composition criteria (specifically insisting upon 8-32 characters, including a number, and upper and lower case letters). However, password change does not enforce the composition requirements, and so users can change to a less secure password than they originally chose. The restrictions are then reinstated again at the password reset stage. Meanwhile, the password change stage does include a password strength meter, which is not present at other points. 10
Computer Fraud & Security
UÊ i`Ê >`Ê>Ê«>ÃÃÜÀ`ÊiÌiÀÊ>ÌÊ the password change and reset stages, which was not present during signup. Even so, it was still found to accept some password choices that the meter rated as ‘Weak’. UÊ /ÜÌÌiÀÊ >ÃÊ>Ê«>ÃÃÜÀ`ÊiÌiÀÊ>ÌÊ sign-up and reset, but it disappears during the password change phase. As with LinkedIn, the site allows the use of passwords that the meter rates as ‘Weak’. Another inconsistency observed on Twitter related to the feedback offered to users when their password choices were rejected. For example, using ‘password’ yielded the comment “Password is too obvious” at signup, but then prompted the rather terse “Contains banned password” when attempted at the reset stage. While none of these are dire problems, neither do they aid the task of promoting understanding and enforcing good practice to the best extent possible.
Reflecting upon the findings Seven years on from the original study one of the main observations remains the same – is it any wonder that password practice is variable when we do so little to guide and support it? Whereas quite a tangible degree of difference was observed between the 2007 and 2011 versions of the study (eg, in the original study only a minority of sites were preventing choices such as the User ID or ‘password’, and none were checking dictionary words), the difference from 2011 to 2014 is far less marked. Sites could, of course, argue that the world hasn’t ended as a result (although some have had highly publicised password incidents, it’s been down to bulk theft rather than weak individual cases). Nonetheless they have still made little contribution towards getting passwords to be used better. All the while, passwords have continued to be derided and have indeed been replaced or supplemented in some contexts
Referring back to Table 2, we can see that from a total of 30 opportunities to provide password guidance, only a third were actually taken. This is a significant omission – not only because it is something that is very straightforward to provide, but also because doing so can make a tangible difference to password quality as a result. Indeed, our findings from other research provide a strong indication that the mere provision of guidance at an appropriate point can have an effect, with (for example) study participants being significantly more likely to choose passwords of at least eight characters and to incorporate non-alphanumeric characters into their passwords if actually provided with guidance to do so (with 85% choosing longer passwords and 62% using other characters when a brief list of guidance was displayed on the password selection page, versus only 50% and 7% doing so when left to the make their selections without further information).11 It should be noted that the provision of guidance resulted in improved passwords without enforcement of any related restrictions, and so adding this as an extra layer could clearly improve things further. However, the latest research again shows that significant gaps exist. Taking a crude measure across the whole set of possible sign-up checks from Table 3, 25 out of 60 (42%) were not made (and even this is when counting checks such as enforcing a minimum password length of six characters, which is arguably not sufficient). As such, there is still a clear opportunity for sites to improve their practices, and guide users into stronger password choices as a consequence. The fact that such gaps remain continues to suggest that sites remain more interested in getting users to sign-up than getting them to do so securely. While sites may argue it is not their place to provide the security lessons, they do have a more tangible responsibility in terms of the duty of care for the data they are collecting. Allowing their users to select weak passwords to protect their accounts essentially puts that data at greater risk (as the earlier-cited iCloud December 2014
FEATURE incident, and others like it, readily serve to illustrate).
Managing passwords Of course, one of the remaining problems with passwords comes down to their manageability once you end up dealing with a multitude of systems and accounts that require them – as observed at the outset of the paper, they can be used more effectively, but up to a threshold. Once you reach a certain number, there is the temptation to lapse into bad practices in order to make them easier to remember. Even here though, there are other ways that the situation can be handled. One tip, from Microsoft, is to reserve the effort of using strong passwords for systems that actually require them, with weak choices being quite acceptable for sites that are not being entrusted with valuable information.12 While this may not apply to many of the sites tested here, it is at least a strategy that can ease the burden in cases where sites are seemingly asking users to create accounts for the sake of it. Another strategy (especially for sites that are going to hold sensitive information but are expected to be used infrequently) is to always choose a strong password, but not even attempt to remember it – an approach that can be termed ‘set and forget’. The idea here is to ensure that the account is strongly protected, and then rely upon the password reset facility to regain access to it later. A final option that is increasingly available is to let the system choose a strong password and remember it for you (eg, the Safari browser can generate strong passwords, which can then be stored and shared between the users’ devices via the iCloud Keychain). The obvious disadvantage (and perhaps psychological discomfort) here is that a password is then generated that the system knows but which the user never even tried to remember and so probably cannot reproduce without the system’s assistance. When all is said and done, it is impossible to remove all of the potential disadvantages of passwords. However, the alter-
December 2014
natives offered by other approaches are not utopian either, and so it makes sense to optimise the experience and the likelihood of success where possible. As things stand, there is currently no reason to assume that most (if not all) of the leading sites won’t still be using passwords if a further version of this study is conducted in a few years time. The question will be whether their practices will have improved more tangibly than this time around.
About the author Steven Furnell is a professor of information systems security and leads the Centre for Security, Communications & Network Research at Plymouth University. He is also an Adjunct Professor with Edith Cowan University in Western Australia. His research interests include usability of security and privacy technologies, security management and culture, and technologies for user authentication and intrusion detection. He has authored over 250 papers in refereed international journals and conference proceedings, as well as books including Cybercrime: Vandalizing the Information Society (2001) and Computer Insecurity: Risking the System (2005). Furnell is the BCS representative to Technical Committee 11 (security and privacy) within the International Federation for Information Processing, and is a member of related working groups on security management, security education, and human aspects of security. He also chairs the academic partnership committee and southwest branch of the Institute of Information Security Professionals.
References 1. Rubens, P. ‘Has the flawed password system finally had its day?’. BBC News, 29 Aug 2014. www.bbc.co.uk/ news/technology-28891938. 2. Kelly, H. ‘“123456” tops list of worst passwords”. CNN.com, 22 Jan 2014. http://edition.cnn.com/2014/01/22/ tech/web/most-common-passwords/. 3. ‘Password Misuse is Rampant at US Businesses’. InfoSecurity Magazine, 21 Jul 2014. www.infosecuritymagazine.com/view/39408/passwordmisuse-is-rampant-at-us-businesses/.
4. Clover, J. ‘Celebrity iCloud Accounts Compromised by Weak Passwords, Not iCloud Breach’. MacRumours, 2 Sep 2014. www.macrumors. com/2014/09/02/apple-no-celebrityicloud-breach/. 5. Furnell, S. ‘An assessment of website password practices’. Computers & Security, vol. 26, nos. 7-8, 2007, pp.445-451. 6. Furnell, S. ‘Assessing password guidance and enforcement on leading websites’. Computer Fraud & Security, Dec 2011, pp.10-18. www. sciencedirect.com/science/article/pii/ S1361372311701233. 7. DARPA. 2012. Broad Agency Announcement – Active Authentication DARPA-BAA-12-06. Defense Advanced Research Projects Agency. 12 Jan 2012. 8. Fido Alliance. ‘Lenovo, Nok Nok Labs, PayPal, and Validity Lead an Open Industry Alliance to Revolutionize Online Authentication’. Press Release, 12 Feb 2013. https://fidoalliance.org/news/ item/auto_replace14. 9. Winder, D. ‘Why following Get Safe Online’s advice could leave you anything but’. IT PRO, 11 Jun 2014. www.itpro.co.uk/security/22453/ why-following-get-safe-onlinesadvice-could-leave-you-anything-but. 10. Mattord, HJ; Levy, Y; Furnell, S. ‘Factors for Measuring PasswordBased Authentication Practices’. Journal of Information Privacy and Security, vol.10, no.2, 71-94, DOI: 10.1080/15536548.2014.924812. 11. Furnell, S; Bär, N. ‘Essential Lessons Still not Learned? Examining the Password Practices of End-users and Service Providers’. In Proceedings of HCI International 2013, Las Vegas, Nevada, 21-26 July 2013. 12. Hern, A. ‘Microsoft tells users to stop using strong passwords everywhere’. The Guardian, 16 Jul 2014. www. theguardian.com/technology/2014/ jul/16/microsoft-stop-using-strongpasswords-everywhere.
Computer Fraud & Security
11
Password practices on leading websites – revisited
Steven Furnell
Steven Furnell, Centre for Security, Communications and Network Research, University of Plymouth, UK Passwords are perhaps the most maligned example of security technology. People very readily dismiss them, and there is a good degree of evidence to support their reasons for doing so.1 However, while fully acknowledging that they have inherent limitations, the extent of the problem is arguably worse than it needs to be. Fundamentally, it is not impossible to use passwords more effectively (at least up to a certain threshold in terms of the number of them to be managed). The challenge is not so much the technology, but getting people to use it correctly. However, we must equally recognise that users’ natural behaviour will not necessarily be the correct behaviour, and so efforts need to be made to guide and shape it accordingly. When looking at password usage today, one aspect that is clear from the outset is that, while some sites and services have moved to supplement or supplant it with alternatives, the approach still reigns supreme. Similarly, when lists of common passwords are published, many of the old favourites are still prominent (suggesting that long-established guidance still isn’t finding its audience in an effective manner), and indeed further reports indicate that people have become no better at using passwords more generally.2,3 A timely illustration of this is provided by an incident reported while this article was being written, with the exposure of celebrity photos stored on Apple’s iCloud. While initial speculation suggested hacking of the service itself, Apple was quick to report that the actual cause was targeted attacks against accounts with poorlyselected passwords.4 With such problems in mind, it is relevant to consider the way in which password practices are encouraged and enforced December 2014
on leading websites. This study follows on from prior assessments performed in earlier years, with the original conducted in 2007 and a follow-up in 2011.5,6 The intervening period has seen increased attention towards non-password-based authentication through initiatives such as DARPA’s call for research into active authentication in early 2012, and the launch of the Fast IDentity Online (FIDO) Alliance just over a year later.7,8 Nonetheless, passwords remain dominant and, as such, it is timely to examine what has changed in the three years since the last assessment.
Website selection and assessment methodology As with the earlier versions of the study, the sites selected for assessment were iden-
tified from Alexa’s global list of ‘The top 500 sites on the web’ (see www.alexa.com/ topsites). The sample was taken in midAugust 2014, with the assessment targeting English-language sites and ignoring any regional variations of the same brands (eg, with Google.com already topping the list, high-ranked sites such as Google. co.in and Google.de – ranking at 13 and 24 respectively – were excluded). Also excluded were any sites that relied on the same login mechanisms as a site already benchmarked (eg, YouTube, ranked at number 3, and Blogspot.com, ranked at number 17, both used Google account login, while Bing at number 23 used the same credentials as Live.com). This yielded the set of sites listed in Table 1. Of these, Amazon, Facebook, Google, Microsoft and Yahoo have been consistently present in all three versions of the study, whereas other sites have come and gone. Bebo, Friendster, MySpace and YouTube had all disappeared in the 2011 version, although YouTube’s exclusion was
Site
Alexa ranking
Description
1
Web portal.
2
Social networking site.
Yahoo!
4
Web portal.
Wikipedia
6
Web-based collaborative encyclopaedia.
7
Social networking and microblogging service.
Amazon
10
International online retailer.
Microsoft Live
11
Web portal.
12
Business/Professional networking site.
WordPress.com
25
Open source blog tool and publishing platform.
26
Online pinboard
Table 1: The 10 most popular websites selected for assessment.
Computer Fraud & Security
5
FEATURE
Figure 1: Password instructions on Microsoft Live during sign-up.
due to it having been acquired by Google and consequently using the same login approach, rather than as a result of a drop down the Alexa rankings. By 2014, the only notable difference in the list is that eBay has now disappeared from the table as well, with Pinterest having ranked just high enough to make the cut ahead of it – eBay’s Alexa ranking was actually 27th at the time of the sample. As with the earlier studies, although 10 sites does not constitute a high-volume sample, it does capture a group of leading and well-recognised services whose password practices are likely to influence a significant community of end-users. In addition, other providers may see them as a standard against which to set the provisions on their own sites. For the evaluation, user accounts were created on the sites in order to determine the password selection requirements. The passwords were then updated using the available change and reset procedures. More specifically, each site was assessed to determine whether: UÊ ÌÊ«ÀÛ`i`Ê>ÞÊ}Õ`>ViÊÊÊÀi>ÌÊ to password selection, and (if so) the extent of the coverage. UÊ ÞÊÀiÃÌÀVÌÃÊÜiÀiÊ«Ãi`ÊÊ«iÀmissible passwords, in order to reduce the user’s potential for making poor choices (this included prevention of the user’s surname or user ID as their password, the prevention of the use of the word ‘password’ itself, prevention of dictionary words, and some requirement for users to compose their passwords multiple character types). UÊ Êi>ÃÊÜ>ÃÊvviÀi`ÊÌÊÀiÃiÌÊÊÀÊ recover passwords, and (if so) the process involved. UÊ / iÊÃÌiÊ«iÀÌÌi`ÊÌ iÊÀiÕÃiÊvÊ old passwords. 6
Computer Fraud & Security
UÊ Ê«>ÃÃÜÀ`ÊÃÌÀi}Ì ÊiÌiÀÊÜ>ÃÊ«Àvided, and if so, how it worked. UÊ / iÀiÊÜ>ÃÊ>ÞÊi>ÃÊvÀÊÕÃiÀÃÊÌÊ supplement their passwords with additional protection – eg, via one-time passcodes sent to their mobile device.
Provision of password guidance The first element of the evaluation examined whether the sites provided their users with any guidance on good password selection and/or management practices. The assessment here was looking for something more tangible than simply providing messages that indicate the password requirements that are being enforced. While such messages are clearly useful, they do not necessarily serve to provide any related advice. For example, Facebook asserts that, “Your password must be at least 6 characters long” if the user tries to submit a shorter one. Meanwhile, Microsoft Live does not provide any explanatory guidance around password selection, but details Site
of the enforced restrictions appear when the password box is in use, as shown in Figure 1. Neither of these examples are considered to qualify as guidance, as they indicate what the user is expected to do, but do not help them to understand why. As such, it is relevant to take a look at what further support is present, and Table 2 indicates whether or not any guidance was provided at each of the key stages where it would have been relevant. This in itself paints a fairly revealing picture, with only a single site (Google) providing users with access to password guidance at all points where they might actually benefit from it. It should be noted the table does not assess the extent or quality of the guidance, and in practice it can be observed that this was variable. As an example, while Google has a link available to substantive password guidance at all stages, LinkedIn’s offering (available during password change or reset) was limited to a statement indicating that “A good password should contain a mix of capital and lower-case letters, numbers and symbols”. While this can still be classed as advice, it is clearly of a rather minimal nature. Providing guidance is one thing, but it does not necessarily mean that sites will require users to follow it. Indeed, using Amazon as an example, when it finally gets around to providing some tips (at the password reset stage – see Figure 2), it still
Guidance provided Sign-up
Password change
Password reset
Amazon
✗
✗
✓
✗
✗
✓
✓
✓
✓
✗
✓
✓
Microsoft Live
✗
✗
✗
✗
✗
✗
✗
✗
✓
Wikipedia
✗
✗
✗
WordPress
✓
✗
✓
Yahoo!
✗
✗
✗
Table 2: The provision of password guidance across each of the sites.
December 2014
FEATURE does nothing to actually ensure compliance, and indeed allows all of the things it advises against.
Enforcement of password restrictions Given that guidance alone may not work (and it is often absent in any case), it is relevant to assess the degree to which password restrictions are actually enforced, as this ultimately reflects the quality of the passwords that users are permitted to choose. With this in mind, Table 3 summarises the restrictions that are enforced during initial registration. The passwords selected at sign-up are particularly important insofar as none of the sites ever enforces password expiration by default, and so the user’s initial choice could persist for years. (As an aside, the Microsoft Live site was unique in giving the user an option to make the password expire, with a tick-box “Make me change my password every 72 days” being offered during password change – but not at initial sign-up or password reset). Another point worth noting is that the aspects enforced at sign-up are not necessarily the same at other stages (as discussed further below), and so it should not be assumed that the restrictions presented in the table are applied consistently for the password update and reset aspects in each site. The rightmost colSite
Figure 2: Amazon password tips – provided but not enforced.
still makes no attempt to enforce good practice beyond having a minimum password length (and even this was absent in the original 2007 assessment), while Wikipedia still only prevents the use of the user ID as the password. Meanwhile, the sites that appeared the strongest in the earlier studies (eg, Google and Microsoft) have remained so in the latest version, with some further improvements also being noted (eg, Google now prevents the use of surnames, and Microsoft Live prevents password reuse). The most notable case of improvement since the last evaluation appears to be from Yahoo, with the password length minimum have increased from six to eight, and the checking having been hardened to prevent dictionary
umns of the table indicate whether there are any supporting features in terms of password strength ratings (again, specifically reflecting provision at the sign-up stage), availability of extra protection such as two-step verification, and prevention of password reuse when users later change or reset their passwords. In most cases the table presents a clear indication of whether sites pass or fail in relation to each criterion. However, there are some cases in which partial compliance is recorded (denoted as ~), and these are explained as the discussion proceeds. For some sites that were present in earlier versions of the study there is not a lot of progress to show over the seven-year period. For example, Amazon
Restrictions enforced at sign-up Enforces min length
Prevents Surname
Prevents User ID
Other support Prevents ‘password’
Enforces Prevents composition dictionary words
6
✗
✗
✗
✗
✗
6
✓
✗
✗
✗
✗
8
✓
✓
✓
✗
✓
6
✗
✗
✓
✗
Microsoft Live
8
✓
✓
✓
6
✗
✓
6
✗
Wikipedia
✗
WordPress
Amazon
Yahoo!
Password meter ✗
Extra protection
Prevents reuse
✗
✗
✓
✓
✓
✓
✓
~
✗
✗
✗
✓
✗
✗
✓
✓
✓
✗
✗
✗
✗
✓
✓
✓
✗
~
✓
✓
✓
✗
✓
✗
✗
✗
✗
✗
✗
6
✗
✓
✓
~
✓
✓
✗
✓
8
✓
✓
✓
✓
✓
✗
✗
✓
Rating s
Table 3: Enforcement of password restrictions and provision of additional support across the target sites.
December 2014
Computer Fraud & Security
7
FEATURE scored a pass, but the blocking of only one would give a partial pass. In addition, if either or both were blocked then a few additional words were then used to further Figure 3: An example of the auto-generated strong password from WordPress. test the limits of the filtering process. In some cases, the two choices would be UÊ 9> tÊ>VVi«Ìi`ʼ*>ÃÃÜÀ`£½Ê>ÃÊÌÊiÌÊ automatically prevented as a result of the words, enforce character composition, the composition criteria of including length or composition rules. For example, and prevent reuse. a number and an uppercase letter. Microsoft Live requires at least two charLooking at the first few columns in In terms of enforcing password composi- acter types, and so typing the word in all Table 3, the nature of the restrictions tion, the basic requirement to get a tick lowercase would be blocked, but varying being tested, and the associated findings, in Table 3 was whether a site required the the case (eg, ‘Diamonds’) was permitted. are fairly self-evident. However, although use of more than one character type – ie, Meanwhile, in Yahoo’s case the basic use of it is relevant to observe that preventing upper or lower case alphabetic, numeric, or dictionary words is more fully prevented the use of the user’s surname as a passspecial/punctuation characters. As can be by the requirement to include a number word is only feasible if sites collect this seen, this in itself was relatively rare, and it and so it scores a pass on this criterion. information as part of the enrolment is also worth noting that none of the sites However, it can be noted that a noneprocess – not all of them do, and so too-inventive variant such as ‘diamonds1’ some fail this criterion by default. For the enforcing composition explicitly required the use of non-alphanumeric characters. would still be accepted. Twitter scored a other restriction-related columns some WordPress was a special case in the sense partial pass in this case because, while it filfurther discussion is relevant to explain tered some dictionary words (eg, ‘monkey’, the details. The first such issue is whether that it made decisions on the basis of a combination of composition and length. ‘secret’, ‘diamond’ and ‘computer’ were sites prevent the use of ‘password’ as the Specifically, shorter passwords needed to all blocked), the string ‘diamonds’ was password, and at the surface level the have a combination of character types still accepted. Similarly, LinkedIn blocked table suggests a reasonable degree of suc(eg, diamonde would be rejected as too ‘monkey’ (as with ‘password’, it appeared cess (with 7/10 sites doing so). However, weak, whereas ‘diamond!’ was accepted), to accept it initially, but forced a change the evaluation itself went a little further but longer ones could be a single character at first login), but accepted ‘diamonds’. than this and sought to discover whether type (eg, ‘assessment’ was accepted). As WordPress blocked all of the aforemenobvious variants such as ‘password1’ and ‘Password’ were acceptable. The following such, it would be most accurate to say that tioned words as being too common, but it enforces a minimum acceptable passthe word ‘dictionary’ was then accepted examples illustrate that some of the sites word space. WordPress was also unique (which seemed somewhat ironic!). that blocked ‘password’ do not take their among the sites under test for offering an Google was resilient to all of the precedchecking too much further: option to automatically generate a strong ing options, but was ultimately found to UÊ i`Ê>««i>Ài`ÊÌÊ>VVi«Ìʼ«>ÃÃpassword, which would in turn utilise all accept ‘Dictionary’, which was rated ‘Fair’ word’ as a valid choice at signup, of the aforementioned character types. by the password meter. but yielded a demand for password Finally, having commented upon the change on the first attempt to sign in However, a potential downside of this otherwise helpful idea is that the passwords general paucity of password guidance, it is with it. The use of ‘password1’ was also rejected in the same way, but the that are generated may not actually be very worth noting that some of the prompts/ memorable (as illustrated by the example messages that appear in relation to the choice of ‘Password’ was accepted in Figure 3). password restrictions are (sometimes) at without further challenge. least partially informative. For example, UÊ *ÌiÀiÃÌÊLVi`ʼ*>ÃÃÜÀ`½]ÊLÕÌÊ on WordPress, if you try to use ‘pass‘password1’ was acceptable. Permissible words word’ as the password there is a resulting UÊ /ÜÌÌiÀÊ``ÊÌÊ>ÜÊ>ÞÊvÊÌ iÊ prompt indicating that “Your password is aforementioned choices, but ‘passThe permissibility (or otherwise) of dicone of the most common passwords used word2’ was accepted (with the mestionary words was principally assessed by on the web. Try something a little more sage “Password is okay”). The string using the strings ‘monkey’ and ‘diamonds’ unique”. Meanwhile, Twitter’s response ‘passwo’ was also accepted (for users (the former was chosen because of its wanting to be obvious, but too lazy apparent prominence in lists of commonly in the same situation is a message stating “Password is too obvious”, which is a little to even type the whole word!). used passwords, while the latter was an less informative about why. The feedback UÊ 7À`*ÀiÃÃÊÃÕVViÃÃvÕÞÊLVi`Ê example that would satisfy the longer ‘passsword1’, but ‘Password’ and minimum length thresholds of some sites). messages can be similarly vague in relation to passwords that are permitted. For ‘password2’ were both acceptable. If both of these were blocked then the site 8
Computer Fraud & Security
December 2014
FEATURE example, staying with Twitter, while it accepted the dictionary word ‘diamonds’ as a valid password, it did also indicate, “Password could be more secure”. From a guidance perspective, the problem here is still that it is only going part of the way; it is flagging the weakness, but not giving any indication of how the user might address it – ie, what does a ‘more secure’ password look like?
Enabling password reset or recovery In common with the 2011 version, a positive observation from this study was that all of the sites offer reset rather than recovery in the event of a user forgetting their password. This is significant in terms of the implications if the ‘forgotten password’ process was to be exploited by an attacker. Given the recognised tendency to use the same password over multiple accounts, the risk of a recovery option is that it could inadvertently expose credentials that could then be used elsewhere. Meanwhile, an impostor performing a password reset would serve to alert the legitimate user to the compromise of their account, as their expected password would cease to work. Back in 2007, two of the 10 sites were sending the current password to the registered email address (which was clearly a risk if this account had been compromised), and it is good to see that the practice has not returned. Having said this, the password update page of the Twitter site nonetheless made a rather misleading claim in this respect, indicating that you can “Change your password or recover your current one” (see Figure 4). Moreover, clicking on the ‘Forgot your password?’ link then claimed to send a reminder. However, what it actually did was to send a password reset link to the registered email address.
Figure 4: A false impression of offering password recovery rather than reset.
presented to the user was not conveying an accurate impression of what was going on. For example, Figure 5 presents the password change interface from Facebook. While this all looks perfectly sensible on the basis of what appears to be shown, it is actually less so when one realises that Facebook does not actually trap dictionary words (eg, ‘monkey’, ‘secret’ and ‘diamond’ were all accepted without question). What is actually being blocked in Figure 5 is an attempt to use the user’s surname as the password. Another example is provided during the password change process in Yahoo. Attempting to reuse a previous password choice (a string ending in 12) yielded a message saying, “Your password is too similar to one you’ve used before”. While this seems fine, it was then found that ending an identical string with 13 rather than 12, or indeed omitting the number altogether, resulted in acceptable choices. As such, contrary to the message, the site only appeared to be checking for exact matches to previous passwords and not for similarity.
A further (and potentially more problematic) category of misleading messages is arguably the feedback that users might receive from password meters. Although offering a meter and some sort of rating clearly has the potential to make a useful contribution, the behaviour of the meters themselves was not exactly consistent between sites. While this version of the study did not seek to specifically document the rules by which different meters awarded different ratings (for those interested, the 2011 study did document this for the sites under test at the time), there was clear potential for different sites to give different ratings to the same password, as well as for certain choices to be overrated in terms of the strength offered. Indeed, others have made similar observations, to the extent of dismissing the meters as mere “eye candy”.9 While this may be a bit harsh in some cases, it would certainly be desirable for these approaches to be strengthened where possible, which in turn calls for some standardisation in the use of underlying password metrics.10
Misleading messages There were a few other occasions during the evaluation when the information December 2014
Figure 5: Implying a prevention of dictionary words when preventing the user’s surname.
Computer Fraud & Security
9
FEATURE
Vive la difference? Another observation worthy of call-out is the surprising number of variations that exist within the same sites, with different behaviours observed at sign-up, change and reset stages. This was actually true for the earlier studies as well, and the discussion here aims to give a sense of the inconsistencies. Indeed, a couple have already been observed in the earlier discussion, such as Microsoft Live’s option to set a 72-day limit on password usage only being present if the user elects to manually change their password in the first place. Similarly Table 2 has already presented evidence of significant variation in whether or not sites provide any password selection guidance, with half of the sites exhibiting inconsistency in this regard. Specifically, some sites provide guidance at sign-up but not at password change (or vice versa), while three sites only provide guidance at the password reset stage. Although the latter context provides a more overt justification for needing guidance (ie, users have already demonstrated their ability to forget their previous choice, and so may require assistance to choose something more effectively), it clearly does not preclude the value of providing guidance at other stages as well. In addition to the above, further differences can also be observed in terms of the password restrictions, feedback messages, and use of password meters: UÊ 7 iÊÃiÌÌ}Ê«>ÃÃÜÀ`ÃÊ>ÌÊÃ} up, Yahoo! requires that they meet a series of length and composition criteria (specifically insisting upon 8-32 characters, including a number, and upper and lower case letters). However, password change does not enforce the composition requirements, and so users can change to a less secure password than they originally chose. The restrictions are then reinstated again at the password reset stage. Meanwhile, the password change stage does include a password strength meter, which is not present at other points. 10
Computer Fraud & Security
UÊ i`Ê >`Ê>Ê«>ÃÃÜÀ`ÊiÌiÀÊ>ÌÊ the password change and reset stages, which was not present during signup. Even so, it was still found to accept some password choices that the meter rated as ‘Weak’. UÊ /ÜÌÌiÀÊ >ÃÊ>Ê«>ÃÃÜÀ`ÊiÌiÀÊ>ÌÊ sign-up and reset, but it disappears during the password change phase. As with LinkedIn, the site allows the use of passwords that the meter rates as ‘Weak’. Another inconsistency observed on Twitter related to the feedback offered to users when their password choices were rejected. For example, using ‘password’ yielded the comment “Password is too obvious” at signup, but then prompted the rather terse “Contains banned password” when attempted at the reset stage. While none of these are dire problems, neither do they aid the task of promoting understanding and enforcing good practice to the best extent possible.
Reflecting upon the findings Seven years on from the original study one of the main observations remains the same – is it any wonder that password practice is variable when we do so little to guide and support it? Whereas quite a tangible degree of difference was observed between the 2007 and 2011 versions of the study (eg, in the original study only a minority of sites were preventing choices such as the User ID or ‘password’, and none were checking dictionary words), the difference from 2011 to 2014 is far less marked. Sites could, of course, argue that the world hasn’t ended as a result (although some have had highly publicised password incidents, it’s been down to bulk theft rather than weak individual cases). Nonetheless they have still made little contribution towards getting passwords to be used better. All the while, passwords have continued to be derided and have indeed been replaced or supplemented in some contexts
Referring back to Table 2, we can see that from a total of 30 opportunities to provide password guidance, only a third were actually taken. This is a significant omission – not only because it is something that is very straightforward to provide, but also because doing so can make a tangible difference to password quality as a result. Indeed, our findings from other research provide a strong indication that the mere provision of guidance at an appropriate point can have an effect, with (for example) study participants being significantly more likely to choose passwords of at least eight characters and to incorporate non-alphanumeric characters into their passwords if actually provided with guidance to do so (with 85% choosing longer passwords and 62% using other characters when a brief list of guidance was displayed on the password selection page, versus only 50% and 7% doing so when left to the make their selections without further information).11 It should be noted that the provision of guidance resulted in improved passwords without enforcement of any related restrictions, and so adding this as an extra layer could clearly improve things further. However, the latest research again shows that significant gaps exist. Taking a crude measure across the whole set of possible sign-up checks from Table 3, 25 out of 60 (42%) were not made (and even this is when counting checks such as enforcing a minimum password length of six characters, which is arguably not sufficient). As such, there is still a clear opportunity for sites to improve their practices, and guide users into stronger password choices as a consequence. The fact that such gaps remain continues to suggest that sites remain more interested in getting users to sign-up than getting them to do so securely. While sites may argue it is not their place to provide the security lessons, they do have a more tangible responsibility in terms of the duty of care for the data they are collecting. Allowing their users to select weak passwords to protect their accounts essentially puts that data at greater risk (as the earlier-cited iCloud December 2014
FEATURE incident, and others like it, readily serve to illustrate).
Managing passwords Of course, one of the remaining problems with passwords comes down to their manageability once you end up dealing with a multitude of systems and accounts that require them – as observed at the outset of the paper, they can be used more effectively, but up to a threshold. Once you reach a certain number, there is the temptation to lapse into bad practices in order to make them easier to remember. Even here though, there are other ways that the situation can be handled. One tip, from Microsoft, is to reserve the effort of using strong passwords for systems that actually require them, with weak choices being quite acceptable for sites that are not being entrusted with valuable information.12 While this may not apply to many of the sites tested here, it is at least a strategy that can ease the burden in cases where sites are seemingly asking users to create accounts for the sake of it. Another strategy (especially for sites that are going to hold sensitive information but are expected to be used infrequently) is to always choose a strong password, but not even attempt to remember it – an approach that can be termed ‘set and forget’. The idea here is to ensure that the account is strongly protected, and then rely upon the password reset facility to regain access to it later. A final option that is increasingly available is to let the system choose a strong password and remember it for you (eg, the Safari browser can generate strong passwords, which can then be stored and shared between the users’ devices via the iCloud Keychain). The obvious disadvantage (and perhaps psychological discomfort) here is that a password is then generated that the system knows but which the user never even tried to remember and so probably cannot reproduce without the system’s assistance. When all is said and done, it is impossible to remove all of the potential disadvantages of passwords. However, the alter-
December 2014
natives offered by other approaches are not utopian either, and so it makes sense to optimise the experience and the likelihood of success where possible. As things stand, there is currently no reason to assume that most (if not all) of the leading sites won’t still be using passwords if a further version of this study is conducted in a few years time. The question will be whether their practices will have improved more tangibly than this time around.
About the author Steven Furnell is a professor of information systems security and leads the Centre for Security, Communications & Network Research at Plymouth University. He is also an Adjunct Professor with Edith Cowan University in Western Australia. His research interests include usability of security and privacy technologies, security management and culture, and technologies for user authentication and intrusion detection. He has authored over 250 papers in refereed international journals and conference proceedings, as well as books including Cybercrime: Vandalizing the Information Society (2001) and Computer Insecurity: Risking the System (2005). Furnell is the BCS representative to Technical Committee 11 (security and privacy) within the International Federation for Information Processing, and is a member of related working groups on security management, security education, and human aspects of security. He also chairs the academic partnership committee and southwest branch of the Institute of Information Security Professionals.
References 1. Rubens, P. ‘Has the flawed password system finally had its day?’. BBC News, 29 Aug 2014. www.bbc.co.uk/ news/technology-28891938. 2. Kelly, H. ‘“123456” tops list of worst passwords”. CNN.com, 22 Jan 2014. http://edition.cnn.com/2014/01/22/ tech/web/most-common-passwords/. 3. ‘Password Misuse is Rampant at US Businesses’. InfoSecurity Magazine, 21 Jul 2014. www.infosecuritymagazine.com/view/39408/passwordmisuse-is-rampant-at-us-businesses/.
4. Clover, J. ‘Celebrity iCloud Accounts Compromised by Weak Passwords, Not iCloud Breach’. MacRumours, 2 Sep 2014. www.macrumors. com/2014/09/02/apple-no-celebrityicloud-breach/. 5. Furnell, S. ‘An assessment of website password practices’. Computers & Security, vol. 26, nos. 7-8, 2007, pp.445-451. 6. Furnell, S. ‘Assessing password guidance and enforcement on leading websites’. Computer Fraud & Security, Dec 2011, pp.10-18. www. sciencedirect.com/science/article/pii/ S1361372311701233. 7. DARPA. 2012. Broad Agency Announcement – Active Authentication DARPA-BAA-12-06. Defense Advanced Research Projects Agency. 12 Jan 2012. 8. Fido Alliance. ‘Lenovo, Nok Nok Labs, PayPal, and Validity Lead an Open Industry Alliance to Revolutionize Online Authentication’. Press Release, 12 Feb 2013. https://fidoalliance.org/news/ item/auto_replace14. 9. Winder, D. ‘Why following Get Safe Online’s advice could leave you anything but’. IT PRO, 11 Jun 2014. www.itpro.co.uk/security/22453/ why-following-get-safe-onlinesadvice-could-leave-you-anything-but. 10. Mattord, HJ; Levy, Y; Furnell, S. ‘Factors for Measuring PasswordBased Authentication Practices’. Journal of Information Privacy and Security, vol.10, no.2, 71-94, DOI: 10.1080/15536548.2014.924812. 11. Furnell, S; Bär, N. ‘Essential Lessons Still not Learned? Examining the Password Practices of End-users and Service Providers’. In Proceedings of HCI International 2013, Las Vegas, Nevada, 21-26 July 2013. 12. Hern, A. ‘Microsoft tells users to stop using strong passwords everywhere’. The Guardian, 16 Jul 2014. www. theguardian.com/technology/2014/ jul/16/microsoft-stop-using-strongpasswords-everywhere.
Computer Fraud & Security
11