I’ve written about passwords. It’s almost a neverending story. In this article I’ll share an update about year 2022’s situation with passwords.

TL;DR: there are a lot of alternatives for passwords. Still, most likely you have to use passwords in a few places.

Probably everyone is fed up with the hassle of passwords.

• you have to create a good, strong password
• how to store the password?
• the time it takes to recover a lost password

The mitigation of passwords comes from:

• new mechanisms in authentication
• getting more widespread coverage for existing passwordless methods
• educating technology leaders and software developers to consider alternatives to passwords
• educating the general public and all stakeholders about insecurities and inconvenience of passwords

Why do we use passwords?

Let’s get down to the basics first.

On your behalf, the password is a simple, known and familiar method. This is psychologically perhaps one of the things that keeps us clinging to passwords. We simply know what’s expected of us: just remember it, and everything is fine!

Whereas “2FA”, biometrics and other technologies might be a bit unfamiliar..

We use passwords in order to let a system (software) identify who we are. Daily examples:

• to read email
• log on to your laptop (Windows / Mac / Linux)
• when borrowing a book, using a library card or Library Web app
• log on to other services in Web
• file our taxes online
• access a remote server via a ‘ssh’ encrypted connection

Rising number of passwords thanks to the cloud

Passwords protect our data, whether it is in our email account, photo album, or our paid subscription to a magazine. Especially when we started living mostly with a web browser, mobile and the cloud-based services, passwords started to appear in our lives. Until then, you might have only had 1 password for the laptop, and another password for email.

Without passwords, software could not tell one user apart from other (this isn’t true anymore; there are alternatives, which we’ll talk later on).

How passwords are used and implemented in code

Password is a string: consecutive characters of some character set. Typically the password character set has been a 8-bit ASCII. Another is Unicode, albeit it has to be said there seems to be general advise against using Unicode characters in passwords.

ASCII means that there’s the usual suspects like A..Z Western alphabet, both in lower case and uppercase. Digits, some punctuations and special characters. The complete ASCII guide (from W3C consortium) is here.

Users are asked to set their password, when:

• user creates an account
• user wants to change an existing password to new one
• a password is known to have been compromised

Compromised passwords are such, whose equivalent hash value is known and stored in an attacker’s suite of tools. We’ll get to hashes (digests) later in this article. When a password is compromised, it has been discovered, and someone (or possibly many crackers) know the hash value. These lists are gathered both by security professionals and crackers. It doesn’t actually matter where the list has been compiled, but what matters is: is your password hash value in that list. If your hash is, then that particular password is considered compromised and can be easily cracked, within seconds.

The strength of a password is theoretically related strictly only to the number of combinations a cracker would have to guess. In theory:

• one character contains 255 different possibilities in password
• 8 characters contains 255^8 possibilities
• eight-character passwords should be almost unbreakable!
• in reality, 8-character passwords are quite weak

In mathematical models there’s an assumption of upon reaching cumulative count of 50% of the password space the cracker hits on a jackpot and guesses the correct password.

Even a single computer can guess around 100 billion attempts per second. There’s other mechanisms to speed up breaking passwords. Just for the fun of it, check out this web site to estimate your password strength => https://tmedweb.tulane.edu/content_open/bfcalc.php

Example:

• a 9 characters long pretty typical password would be cracked easily in less than 5 days (even back in year 2007)
• 13 characters long password would take significantly longer, over 900000 days

How is the magic achieved?

By ‘magic’ I mean:

How can we let a server know and “not know” the password contents at the same time?

Isn’t this kind of “weird” ? We set a password at some point during the user account setup, ie. when we ‘register’ to a site. How come the server iself and its storage of our password doesn’t become an obvious place of vulnerability to our security? How can the server check later a given password against the correct password, without compromising our own security in a major way?

Digests (aka. hashes)

Answer to that is a mathematical method called ‘hash’. A hash is a one-way function, from a given data to a digest.

Hash gives a unique, short string which is a fingerprint of a larger string.

The digest shows whether the given input was a particular unique set of bits. Two inputs never “map” into the same digest value. Thus the password-checking routine on a web page needs only to

a) read password from user

b) calculate hash using the same hash algorithm as previously

c) compare the 2 hashes together

d) if match, the password is correct, let user in! Otherwise not.

Hashes do not reveal the original password

There is also another important feature of a digest: they are not reversible: you cannot go from the digest back to the password character data.

This is what makes the digest usable in programming a password checking code. You can store the hashes (digests) rather safely on a server.

With digests, you can check a given password, but cannot derive a password from a given digest.

HOWEVER… this is not the whole story. There’s a couple of little details to be added:

1. hashes can have collisions, breaking the rule of “a hash digest being unique”
2. even digests can be used to crack passwords, by method known as brute force – and can be speeded up using precompiled tables of hashes, called rainbow tables

Hash collisions are mostly a theoretical issue, and as far as I understand, not helpful in real brute forcing. The thing how passwords are being brute forced (guessed), is by forming both totally random strings, and the strings that people are prone to make.

We humans are bad at really randomizing things. We tend to follow patterns, and be biased.

The list of bad passwords is a living proof of that. (See ‘rules’ file of a famous password-cracking software John The Ripper)

When passwords started to be used for the first time?

In the “really old days”, there were no shared resources to be even bothered with: computers were standalone, isolated from each other. They were almost always either public-use mainframes, or later on individual people’s Personal Computers.

With mainframes, the skill levels needed to interact with the computer were already a good protection. IT / computer skills were simply so rare, that psychologically again, this was thought to be a good enough deterrance for information theft. Besides, the people operating the mainframes knew each other by face. Mainframes themselves were such physically delicate and expensive devices, that they were probably physical locked away, anyway.

Thus the need for protecting the data residing within a computer was not thought to be of any practical value.

In addition, most computers were used for doing ‘mundane’ calculations, which people at least assumed would not interest any malicious third party – that is, an attacker. You didn’t have much of secrets stored on the computer.

Alternatives to actually end the need to use passwords?

• biometric identification
• dongles (devices)
• Yubikey
• blockchain
• cryptocurrencies

Dongles are essentially proprietary electronics devices, that are typically attached in a fixed manner to a laptop or PC. Dongles have been mostly used to maintain license restrictions in a way that is hard to break.

Password managers (software)

Passwords can be managed using software. Many experts point out that a password management software is better than trying to manually create and memoize passwords. Password managers are a good way to improve the current in-transition phase of information wildness.

2020 was actually supposed to be the year of saying goodbye to passwords!

Let’s go through some of the stuff related to the password ‘waste’ problem. We’ll understand why passwords are being created in the first place..

Web designer

Typically there’s a requirement for a new web site. Owner soon wants to have user registration implemented as a feature to the site. Still one of the most obvious template or pattern for action is to use usernames and passwords: user picks (enters) a string of characters as the username, and enters the password which he’ll use for identifying the next time.

And it seems all natural and innocent.

A few points to make here:

• forcing users to actually create an account explicilty is quite a major downer in terms of usability
• consider social login mechanism instead of passwords
• think twice, as designer / owner of a web site, why you’d really want users to register and create an account?
• if you decide to go with accounts, follow good code hygiene
• take into account both GDPR and other data protection schemes out in the wild (CCPA)

Authority on password prevalence

Web browser’s in-built features to support password saving

A cloud solution without passwords?

• why not
• how do users authenticate if not using passwords?
• what exactly is the use case and justification for requiring authentication in the first place?
• can security and comfortability exist at the same time?

Risks

• what has to give up, if we reach for the stars- ie both ease and secure?
• does implementation become costlier on developer side?

Inconvenience

Solutions to replace passwords

What’s snake oil in cryptography?

How cryptography relates to any of the subject matter?