Passwords

Passwords are one of the most common authentication technologies.

There are different kinds of passwords: Pins, Passwords and Passphrases.

PINs

Pins are short (4-10), contain most often only numbers and are insecure. To still make them a valid security feature add a short delay in between pins entered. After the 3rd wrong entry either lock the system and request a special PIN (like PUK for a Smartphone SIM cards) or add a massive penalty (1 minute) which increases during the next wrong entries. A negative side effect of this is that the system can be locked by a malicious actor…

Passwords

Passwords are longer than PINs. As with the current state of technology (cloud computing and GPUs) standard passwords have to be long to have a decent amount of security. To improve the situation you can push the user to create good passwords (high entropy thanks to a large character set, avoiding the top 100+ passwords, …)

Passphrases

Intentionally long passwords. If you create your product for a situation where a good keyboard is available or passwords are stored in password stores you should aim for that - or just do not artificially restrict password length and nudge users to use long passwords in a friendly way.

Entropy matters

Help the user to choose high-entropy passwords. Depending on the system the user is using there are several different approaches to generate high entropy passwords. Smartphone keyboards for example make it very difficult to enter special characters. Maybe go for long passphrases instead ? Also: Avoid the most common top 100+ passwords (google for them). Have a list in your app and block list them. Notify the user not to use those. If you have international users you should also have international top 100+ lists.

There is one exception where it is wise to use common passwords like “12345” or “password”: One time accounts without personal data attached. Things that can be stolen without pain to the user. But as a normal user will not be able to make this distinction - do not tell them that there is a situation when weak passwords are OK…

High entropy is based on length of the password and potential character set being used. This is why so many pages push people to have at least

  • Lower case
  • Upper case
  • Special character
  • A Number

In the password. As the code is simple to guarantee at least one of each is in the password it is done that way.

One example of password entropy is the famous Correct horse battery staple

Password hints

Don’t

Users will use them and enter some easy to research data.

Preventing copy & paste

Some developers had the idea to prevent copy & paste. Hoping that can prevent malware from accessing the password in the clipboard.

Maybe that was true. But current malware has many other tricks in addition. If malware is running on the system, it is game over.

The side effect of preventing copy & paste is that people will use shorter and simple passwords because their password stores will not work properly with your password entry.

And password cracking got a lot better thanks to improved computing power.

TL;DR: Do not block copy and paste

Forgot password

While creating an account enforce and verify a link to a mail address. This mail account is your “Trust Anchor” if the user forgets the password. Create a reset link and mail the user. Make sure not to spam the user. Do not revoke the old password until a new one is set.

Do not send a random password by mail but a (randomly generated) link to a page you have to set a new password.

TTL for passwords

If you force the user to renew the password regularly, store a hash of the last 3 passwords the user used and make sure they are not recycled.

Autofill trap

If you create a web page with a password form: Do not allow autofill without user interaction on your web-page password pages.

Malicious Ads are currently creating invisible forms to steal those passwords.

Princeton research

Stolen passwords

Malicious actors are hacking databases and extract the passwords from there. As users have the tendency to use the same password for different accounts this is troubling.

The project HaveIBeenPwned is collecting those stolen databases from the dark web and makes it searchable for your own credentials.

Hashes from there, cracked to 99%: Hash leaks

Besides locking down your database server you should also “hash and salt” the passwords you store. That way you prevent damage in case of a stolen database..

There are special passwords hashing algorithms that can be used.

Cracking passwords

The technology to crack passwords is quite advanced. Besides Rainbow tables, GPU based passwords cracking and Cloud Computing an old tool is word lists:

GPUs

With powerful GPUs and usable APIs available people started to use a cluster of those GPUs to crack hashes (later they shifted to Bitcoins).

This did beat the cracking capabilities of a CPU by a large factor. But people who invested into that had to specialize and offer hash cracking as a service to others. Reason for that is the investment into a bunch of the most powerful GPUs available (and re-investment a few GPU generations later).

Cloud

Cloud computing offers processing power at a discount (especially when going for the compute-spot market). Using thousands of Amazon VMs in parallel to crack some hashes can be the fastest and cheapest way. Investment into GPUs declined and people switch to cloud way of hash cracking.

Rainbow tables

Rainbow tables are attacker tools you should know about.

To crack hashes (and passwords are stored as hashes) attackers use Rainbow Tables. These are large databases with pre-compiled string->hash pairs. That way the attacker invests in storage, but reduces CPU power. If the attacker gets a large database dump with lots of Hashes, it is more efficient to match those two databases once and extract as many matching passwords as possible.

And this is just the Rainbow Table basics. Some more optimization is available.

Relevant for the defender: The attacker just reduced required CPU power and swapped it for HDD space requirements. Common passwords will be in this table and are easy to crack. Non-common passwords or salted passwords are better protected.

Word lists

Attackers use word lists to brute force passwords. It is more effective to use existing words and permutes them than to generate all potential character combinations.

Word lists are available online

Cracking Archive files

Multi threaded password brute forcing for archives: RARCrack %% rarcrack –threads 12 –type zip crypted.zip

Cracking with wordlists:

1 fcrackzip -u -D -p simple_wordlist.txt test_abc.zip

Web site scraping for wordlists

CEWL

Cewl example:

1 sudo apt install cewl
2 cewl -d 2 -m 5 -w docswords.txt https://example.com

Keyloggers

Keyloggers exist as hardware and as software variants. Hardware variants are USB dongles attached between keyboard and computer - external and internal. They record keystrokes and are later collected. Some even have WiFi - reducing the risk for the attacker. Those things are simple and can be deployed by cleaning staff.

Software Keyloggers are drivers installed on the OS. Quite often by malware. They log keys and send their data to the mother ship.

One way to defeat Keyloggers are on-screen keyboards. But at least for the software Keyloggers they fail. Those programs do screenshots as well as logging the physical keyboard.

The positive effect of on-screen keyboards is limited. Please think twice if it is the proper solution for your specific security problem or if it is just security theater.

IoT: Initial passwords

Especially IoT devices and Routers have initial passwords. Some important wisdom:

  • Force the user to change that on first use
  • Do never derive it from MAC address or other system specific number
    • No fancy maths will protect you if you do. And MAC is broadcasted on WiFi
  • Do not use a increment in the factory to initialise the first password
    • Add proper randomness instead

Salting

A salt is a random string/number.

This is added to the password, before it is hashed. The salt is stored together with the username and password-hash in the database - plain text.

By adding a random string/number to the password the user entered before it is hashed, we force the attacker to create a rainbow table for each of these salts.

Create a new random salt for every user. That way even if two users use the same standard password, the resulting hashes will be different.

Make the salt big.

Pepper

Pepper is similar to salt. But pepper is either stored in a different database or in a different configuration file - both the password database and the configuration file have to be hacked.

Or even not stored at all but is small. And then you brute force them when matching passwords to the database. When comparing the hash the computer will have to generate lots of hashes with password + all possible peppers.

You can afford the extra computing power - while the attacker trying to hack millions of your accounts can not.

Beyond passwords: “Two-factor authentication”

Technology that extends passwords is already a part of many products. In addition to passwords so called “two-factor authentication” is implemented.

A second factor - and a second communication channel - is required. This improves security.

The second factor is very often based on a hardware device.

Two major concepts are existing.

Time-based One-Time Password (TOTP)

The user has a device that shared an initial secret with the server. Based on this secret and the current time a short lived number is generated. The user enters this number in addition to the normal password to access the server. To verify the server just calculates the same data using the current time and the shared secret.

For the user it looks like an App on the smartphone that generates a 6 digit code. A countdown shows its validity (30 seconds are recommended in the RFC).

The best known app for that is the Google Authenticator

RFC 6238

Universal Two-Factor (U2F)

U2F uses a device with a asymmetric crypto implementation. It can export the public key and sign challenges with the private key - which is sealed inside of the device.

The public key is registered at the server. The best known device for U2F is the Yubikey which looks like a USB memory stick. But it can also offer NFC to be used with mobile phones.

FIDO U2F

Yubikey

Backup codes

As mobile phones tend to fall into a toilette or get lost somewhere else your backend will have to offer backup codes as well. Those are generated when the device is paired and can either be stored by the user or printed and locked away.

Those codes should be valid one time only and maybe you also want to offer several codes for download.

Plan a user experience to link a new device to the server using one of those codes. Also better plan a “refresh” button to invalidate the old codes and create new ones in case the printed codes get stolen.

Up next

Censorship