Year 1 / Module 8 Computer systems, networks and security / Unit 7 / The password survives on deployability, not on security

The password survives on deployability, not on security

HCI1108 · Unit 7 of 10

Passwords persist because no proposed replacement retains the full set of properties they already provide, so the critique of passwords is an argument about who bears the cost rather than a demonstration that a better scheme exists.

The password survives on deployability, not on security

The password is the weakest mechanism in this module on almost every measure. It survives anyway. The claim argued here is narrower than a defence of passwords. No replacement retains the whole set of properties a password already provides, so the critique of passwords is an argument about who bears the cost, not a demonstration that a better scheme is waiting. The unit that follows asks what a second factor changes about the attacker.

The founding paper states a trade, not a solution

Morris and Thompson (1979) describe the design of the password scheme on a remotely accessed time-sharing system as a compromise between extreme security and ease of use. They reached it by countering observed attempts to penetrate the system.

The authors collected 3,289 passwords over a long period. Of those, 15 were a single character, 72 were two characters and 464 were three, and 2,831 of them, or 86 per cent, fell into a handful of guessable classes. A dictionary search that ran for five minutes recovered about a third of them. The authors responded in the mechanism rather than in the user. They had the entry program challenge any all-lowercase password shorter than six characters at creation. The sample is one system's users, so it dates the estimate rather than settling the general case. The method of estimating a population from its passwords is the part that carries forward.

Every guess became cheaper, and guessability became an estimate

Provos and Mazieres (1999) put numbers on the trend. The UNIX crypt function hashed fewer than four passwords per second when it was deployed in 1976. By 1999 an ordinary workstation running optimised software managed more than 200,000 crypt operations per second. Their conclusion is general. The cost of any secure password scheme must rise as hardware improves, which makes cost a parameter rather than an accident of the algorithm.

Narayanan and Shmatikov (2005) shrank the search space by modelling easy-to-remember passwords as text in the user's own language. They then enumerated what remained with a time-space tradeoff, recovering 67.6 per cent of real password hashes from two billion candidates. That rate is higher than the rainbow-table method they compare against, and they read it as calling the viability of human-memorable passwords into question.

Melicher and colleagues (2016) made the estimate personal. Their neural networks guessed passwords more effectively than probabilistic context-free grammars and Markov models, particularly beyond ten billion guesses. They compress to hundreds of kilobytes that run in the browser with sub-second latency. A service can now estimate what a password would cost a particular attacker as it is created.

The defender's lever is the cost of each guess

Because the attack is a search, the defender's lever is the price of one attempt, and that lever belongs to the service rather than the person signing in. Provos and Mazieres (1999) designed bcrypt so its cost can be raised as hardware improves. Biryukov and colleagues (2016) carry the idea further with Argon2. It requires a tunable amount of memory, and it imposes prohibitive time-memory and computation-memory tradeoffs on anyone trying to save memory. It fills that memory at 0.6 cycles per byte, and it is offered as resistance to custom hardware and to botnets.

Composition rules failed on their own terms

Komanduri and colleagues (2011) compared policies with more than 5,000 participants. One required a minimum of 16 characters. The other required at least eight, with an uppercase letter, a number, a symbol and a dictionary check. Both were expected to yield similar entropy, but the 16-character policy produced significantly less predictable passwords while being, by several measures, less onerous.

Ur and colleagues (2015) asked why users satisfy such rules so badly. In a think-aloud study, 49 participants created passwords for fictitious banking, email and news accounts. Some weak choices were deliberate, but others came from misconceptions. Among them were the belief that a trailing exclamation mark makes a password secure, and the belief that a birthday is safe to use because it is not on Facebook. The rule met an adversary they did not hold in mind.

Reuse is normal practice, and it is now an attack

The unit of risk is not one account. Florencio and Herley (2007) recorded 544,960 users of a browser toolbar over three months. They found an average of 6.5 passwords, each shared across 3.9 sites, about 25 password-protected accounts, eight passwords typed a day, and an average strength of 40.54 bits.

Pal and colleagues (2019) turn reuse into a measurable attack and a defence. Their similarity models were trained on 1.4 billion leaked email and password pairs. They predicted the variants a targeted attacker should try, compromising more than 16 per cent of accounts in fewer than a thousand guesses whenever another password of the user was known. A university case study confirmed it. The countermeasure is a personalised strength meter small enough to deploy.

A replacement has to be deployable, not merely stronger

Bonneau and colleagues (2012) tested the alternatives rather than assuming them. They rated 35 replacement schemes against 25 usability, deployability and security benefits. They found that none comes close to providing all of them, and none retains the full set that legacy passwords already provide. Every scheme did worse than passwords on deployability, the benefit that decides whether a mechanism reaches users. The authors attribute two decades of failed proposals to researchers rarely considering real-world constraints.

The nearest deployed substitute fails at the interface rather than in its cryptography. Silver and colleagues (2014) found significant differences in autofill policy between browser, mobile and third-party password managers. Several of those managers let a remote network attacker extract multiple passwords with no interaction from the user. The enhancements the authors propose close those routes.

The standard moved to where the evidence pointed

The current federal guideline now states conclusions the studies had reached. Temoshok and colleagues (2025) require a password used as a single factor to be at least 15 characters, and at least eight within multi-factor authentication. They forbid other composition rules and required periodic change, except where compromise is evidenced. They require every new password to be compared in full against a blocklist of commonly used, expected and compromised values. The same document states that passwords are not phishing-resistant, and it supersedes the 2017 guideline.

The concession came from measurement, not from persuading anyone to choose better passwords.

Contested question: has the replacement arrived, and who pays for the transition?

One position holds that the replacement exists and should be adopted now. Temoshok and colleagues (2025) require applications at one assurance level to offer a phishing-resistant option. They require federal agencies to require phishing-resistant authentication from their staff and contractors, while stating that a password is not phishing-resistant.

The opposing position holds that no candidate yet does what a password does. Bonneau and colleagues (2012) found every scheme in their comparison worse than passwords on deployability, and Silver and colleagues (2014) show the packaged substitute failing where it meets a person. The standard names a class, not a deployed replacement.

A third position moves from mechanisms to burden. Florencio and Herley (2007) measured reuse at population scale, and Komanduri and colleagues (2011) priced a policy in user effort and sentiment. Pal and colleagues (2019) place the useful defence in a check that travels with the user's own credentials rather than a rule imposed on them. The work decides.

The evidence that would settle it is a longitudinal comparison within one population. It would compare password-only accounts, accounts with a second factor, and accounts whose credential is a synchronised key pair, reporting account-takeover rates, recovery rates and measured user burden together. No study in this unit reports both sides of that ledger.

The evidence differs in kind on each side. The adoption position rests on a normative guideline rather than a measurement (Temoshok et al., 2025). The no-replacement position rests on a benefit comparison across 35 schemes (Bonneau et al., 2012) and on a study of packaged password managers (Silver et al., 2014). The burden position rests on a population measurement (Florencio and Herley, 2007) and on a controlled policy comparison (Komanduri et al., 2011). While the dispute is open, the designer withdraws the rules that move effort onto the user and measures the burden any replacement adds. The strongest objection is that this unit's anchor, the deployability comparison, is a rating exercise rather than a field trial, so a scheme can fail the rating and still succeed in use.

Where the argument is heading

Measurement is moving to the client, and the credential moves with it. Melicher and colleagues (2016) show a guessing model small enough to run inside the page at sub-second latency. Pal and colleagues (2019) show a personalised meter that warns against variants of the user's own breached passwords. Temoshok and colleagues (2025) have made blocklist screening mandatory and written synchronised authenticators into the guideline. Bonneau and colleagues (2012) offered their benefit list as a benchmark for later proposals, and it remains the honest test of any claim that a replacement has arrived. What stays unmeasured is the burden the transition places on the person making it, and the burden is not measured where the rule falls hardest: no study here reports it for readers in later life or for people who share a device.

The sources this unit rests on

  • Morris, R. and Thompson, K. (1979). Password security: a case history. Communications of the ACM, 22(11), 594-597. doi:10.1145/359168.359172 Presents the password scheme on a remotely accessed time-sharing system as a compromise between extreme security and ease of use, reached by countering attempts to penetrate it. It frames the problem as a design trade rather than a user failing.
  • Provos, N. and Mazieres, D. (1999). A future-adaptable password scheme. USENIX Annual Technical Conference. https://www.usenix.org/legacy/events/usenix99/provos/provos.pdf Reports that UNIX crypt hashed fewer than four passwords per second at its 1976 deployment and over 200,000 per second on a 1999 workstation, and that any secure scheme's cost must rise as hardware improves. It supplies bcrypt, the defender-side lever.
  • Narayanan, A. and Shmatikov, V. (2005). Fast dictionary attacks on passwords using time-space tradeoff. ACM Conference on Computer and Communications Security. doi:10.1145/1102120.1102168 Models easy-to-remember passwords as text in the user's language to shrink the search space, then enumerates what remains with a time-space tradeoff, recovering 67.6 per cent of real password hashes from two billion candidates. It makes the attacker's cost per guess the binding constraint.
  • Melicher, W., Ur, B., Segreti, S. M., Komanduri, S., Bauer, L., Christin, N. and Cranor, L. F. (2016). Fast, lean, and accurate: modelling password guessability using neural networks. USENIX Security Symposium. https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/melicher Trains neural networks to guess passwords, beating probabilistic context-free grammars and Markov models beyond ten billion guesses, compressing to hundreds of kilobytes and running client-side with sub-second latency. It makes guessability an estimate a service can compute per password.
  • Biryukov, A., Dinu, D. and Khovratovich, D. (2016). Argon2: new generation of memory-hard functions for password hashing. IEEE European Symposium on Security and Privacy. doi:10.1109/eurosp.2016.31 Presents Argon2, which requires a tunable amount of memory, imposes prohibitive time-memory and computation-memory tradeoffs on any attempt to save memory, and fills that memory at 0.6 cycles per byte. It is the current form of the defender's lever.
  • Komanduri, S., Shay, R., Kelley, P. G., Mazurek, M. L., Bauer, L., Christin, N., Cranor, L. F. and Egelman, S. (2011). Of passwords and people: measuring the effect of password-composition policies. ACM CHI Conference on Human Factors in Computing Systems. doi:10.1145/1978942.1979321 Compares composition policies with more than 5,000 participants and reports that a 16-character minimum yielded significantly less predictable passwords than an eight-character minimum with character classes, while being less onerous. It shows the rule set, not the user, is the movable variable.
  • Ur, B., Noma, F., Bees, J., Segreti, S. M., Shay, R., Bauer, L., Christin, N. and Cranor, L. F. (2015). "I added '!' at the end to make it secure": observing password creation in the lab. Symposium on Usable Privacy and Security. https://www.usenix.org/conference/soups2015/proceedings/presentation/ur Observed 49 participants creating passwords while thinking aloud and traced many weak choices to misconceptions, including the belief that a trailing exclamation mark secures a password and that a birthday is safe if it is not on Facebook. It explains why composition rules fail on their own terms.
  • Florencio, D. and Herley, C. (2007). A large-scale study of web password habits. International Conference on the World Wide Web. doi:10.1145/1242572.1242661 Recorded 544,960 users over three months: an average of 6.5 passwords shared across 3.9 sites, about 25 password-protected accounts and eight passwords typed a day, at 40.54 bits average strength. It establishes reuse as normal practice.
  • Pal, B., Daniel, T., Chatterjee, R. and Ristenpart, T. (2019). Beyond credential stuffing: password similarity models using neural networks. IEEE Symposium on Security and Privacy. doi:10.1109/sp.2019.00056 Trained similarity models on 1.4 billion leaked pairs and report a targeted attack compromising more than 16 per cent of accounts in fewer than a thousand guesses where another password was known, confirmed at a university, with a personalised strength meter as the defence.
  • Bonneau, J., Herley, C., van Oorschot, P. C. and Stajano, F. (2012). The quest to replace passwords: a framework for comparative evaluation of web authentication schemes. IEEE Symposium on Security and Privacy. doi:10.1109/sp.2012.44 Rated 35 replacement schemes against 25 usability, deployability and security benefits and found none retains the full set legacy passwords provide, with every scheme doing worse on deployability. It is the unit's anchoring claim.
  • Silver, D., Jana, S., Boneh, D., Chen, E. and Jackson, C. (2014). Password managers: attacks and defences. USENIX Security Symposium. https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver Found significant differences in autofill policy between browser, mobile and third-party password managers, several letting a remote network attacker extract multiple passwords with no user interaction, and proposed enhancements managers can adopt. The substitute fails at its interface.
  • Temoshok, D., Fenton, J. L., Choong, Y. Y., Lefkovitz, N., Regenscheid, A., Galluzzo, R. and Richer, J. P. (2025). Digital identity guidelines: authentication and authenticator management. NIST Special Publication 800-63B-4. doi:10.6028/NIST.SP.800-63b-4 Requires a single-factor password to be at least 15 characters and at least eight within multi-factor authentication, forbids further composition rules and required periodic change, and requires each password to be compared in full against a blocklist of commonly used, expected and compromised values. It states that passwords are not phishing-resistant.

Check your understanding & apply it · 4 questions, 1 essay

1A service requires every password to contain a capital letter and a symbol, and users add them predictably at the start or the end of a dictionary word. Which diagnosis does the unit's evidence support?
2A breach exposes a credential store hashed with an old, fast function. What does the unit's evidence predict about the attacker's cost per guess?
3A proposal claims a new authentication scheme is better than a password because it scores higher on security alone. Which judgement does the unit's evidence support?
4A user's credential for one breached service is a small edit of their credential for another service. What does the unit's evidence predict about the second account?
5Essay A university service currently requires a minimum of eight characters with an uppercase letter, a number and a symbol, and forces every password to be changed on a fixed 90-day schedule. It proposes instead a minimum of 16 characters with no composition rules, mandatory screening of each new password against a blocklist of breached and common values, and a memory-hard storage function for the credential store. Using Bonneau and colleagues (2012), Komanduri and colleagues (2011), Ur and colleagues (2015), Florencio and Herley (2007), Pal and colleagues (2019), Biryukov and colleagues (2016), Silver and colleagues (2014) and Temoshok and colleagues (2025), write an assessment that (a) states what the proposed policy buys and what it moves rather than removes, (b) makes the strongest case for it, (c) makes the strongest case against it, and (d) names the measurement that would decide between the accounts and one observation that would count against the proposal.