Human Aspect of Security#

In today’s text we’re going to be discussing a central element of security – the people who actually interact with the systems we’re trying to secure. As we mentioned in at the start of the course, the most secure system is one nobody can access, but such a system is also entirely useless.

Authentication and Authorization#

We’ll start with the two related processes of authentication – confirming the identity of a user and authorization – determining whether the user is allowed to perform an action.

Passwords#

The most common way to authenticate users has been the same since the dawn of computing – passwords. At first glance, they’re perfect for the job. Let the user select a secret string of characters only they know, store it somewhere and only let in someone if they present themselves with this string of characters. It’s very easy to perform this check in a variety of settings, most humans can remember a few characters of a password, you need no specialized hardware – what’s there not to like?

Leaks and hashing#

First of all, what happens, when the database of passwords leaks somehow, either by the hand of a rogue employee or a skilled attacker? Suddenly, the bad actor can sign into any account and do basically anything. What’s worse, since people often reuse their passwords, the bad actor can now sign into entirely unrelated services of many users.

That’s why it is important not to store passwords in databases in plain text. But how can you check the password, when you don’t know it? The answer is going to be one of the tools we’ve introduced in the Cryptography lesson, hashing. When the user creates their account, we do not store the provided password, but just a hash of it. Then, when the user tries to sign in, we hash that password as well and only then compare it with something we have in our database.

This is good, but still has some clear drawbacks. Firstly, you can directly determine which accounts use the same password, as their hashes will also be identical. Also, as an attacker, you can precalculate the hashes of common passwords¹ or passwords you suspect might be stored in the database and then compare them with the ones in the leak.

To mitigate this, salting is used. Before saving the password hash into the database, we generate a unique random string which we append to the password and only then perform the hash, storing the salt alongside the hashed password. This way, the hashes of identical passwords differ, since their randomly generated salts also differ. This renders any precalculated tables useless, but also forces any attacker trying to brute force passwords to do so one password at a time, instead of looking for matches in the entire database.

One final precaution one might want to implement is arbitrarily increasing the computational complexity of calculating the hash, so that trying one password after another becomes unfeasible even on a powerful machine. This of course comes at the cost of increasing the complexity for legitimate logins as well, so the parameters have to be set to a good compromise of not overloading your own systems when many users are trying to log in and still making it reasonably challenging for the bad guys to crack. This of course comes at the cost of increasing the complexity for legitimate logins as well, so the parameters have to be set to a good compromise of not overloading your own systems when many users are trying to log in and still making it reasonably challenging for the bad guys to crack the password hashes in case they leak.

As with most things in cryptography, you probably should not try to reinvent the wheel here, as there are many pitfalls to encounter when trying to implement this.

The most commonly used password hashing functions are bcrypt or the newer and improved Argon2. The advantage of both of these schemes is that they specify the hash itself, the salt and even the parameters of the used algorithm all in a single standardized string which can be safely stored in a database. This allows administrators to gradually increase the hash complexity as their hardware improves, storing newly created passwords with the bigger complexity right away and re-hashing existing ones once a user tries to sign in (and thus provides a password which can be re-hashed). There are still ways to mess this up, for instance when you use up bcrypt’s character limit by also hashing the username.

Password predictability, reuse and bad advice#

Websites leaking passwords is far from the only way passwords end up in the hands of bad actors. Another one is predictability. Humans are incredibly bad at producing random information and even worse at remembering it. Most people’s password still probably looks something like this:

• a single word – probably some name, your nickname, name of your pet, street name…
• some number – 2 to 4 digits, your date of birth, street number, /xxxx part of your birth number, 1234…
• a special character – ! or @, only added when the website asks for it

We’re not going to ask you to raise your hand if you use one password for all services and it looks like this, but MANY people still do. Notice that most of the information used is more or less easily searchable on the internet and collecting all such information and generating all possible permutations won’t take that much time, especially since you can try billions of passwords per second with modern GPUs.

If a database with your password leaks (it will²) and the admins didn’t use one of the strong hashing algorithms (they don’t) a determined attacker will be able to crack such password in minutes.

This is also why reusing passwords is very bad. Since databases leak all the time, many people collect them, crack them with a cluster of GPUs and publish or sell the result. Even if you decide to reuse a randomly generated incredibly strong password, it will inevitably get stored in a database with weak or absent hashing, leak, and bad people will try to login to your other accounts. The same goes for deterministic modifications of your strong password. If d!13p$*W1Z2RnxUcAdobe leaks from Adobe’s servers, it doesn’t take that much thinking to figure out what your GitHub password is…

It is also very good to know when a service you use suffers a data breach. Some services will notify you, others will do it months later, other will not at all. There are services like Have I been pwned, which collect data from such breaches and allow you to look up your email address and even setup notifications as new breaches are added.

Your first thought may be to start enforcing complexity requirements for your user’s passwords to prevent simple ones and require users to change their passwords regularly in case they leak. At first glance, these might sound like a good idea, but practice shows they often lead to quite the opposite effect. Enforcing password expiry often causes people to perform simple modifications on their existing password and almost any complexity requirement can be bypassed by adding “aA1!” at the end. Furthermore, since humans are so bad at creating passwords, we want to force them to do it very rarely, so it’s something they take seriously and do not get complacent about.

Phishing and social engineering#

The part of security, where humans are the target is usually called social engineering, phishing is usually used in context context where computers are involved and the attackers impersonate some legitimate party with the intent to exfiltrate sensitive information from people, but the lines are blurry.

There are many ways in which phishing may be attempted. A basic example might be an email with extremely broken English and formatting, informing you of some inheritance from your distant uncle from a country you’ve never heard of, and the only thing separating you from your riches is $200 in Steam gift cards sent back to the “lawyer in charge of the inheritance process”. Right. None of you will probably fall for something like this, and I doubt even the most tech-illiterate of your relatives won’t eventually realize something’s wrong and not go through with the scam³.

But that’s not what all phishing scams look like. You are probably well aware that creating a copy of a website’s login screen is trivial, you just download the HTML, couple CSS files and modify the login form so that it sends credentials to you. And it will be pixel perfect, since you use the very same CSS the original website used. And buying a domain that’s very similar to the original one also isn’t hard.⁴

And yeah, in ideal conditions, most of you will probably know to check the domain and won’t fall for something like this, but picture this:

It’s Monday morning, you’ve had a busy night last night, your head still hurts from drinking a little too much, on top of that, you overslept so you had to run to catch a tram to school so that you don’t miss your lecture. Your phone vibrates as you receive a notification of a new open exam date, which you desperately need to get into, since you forgot to register and all the other ones are full. You quickly click the “register now” link, which presents you with a familiar CAS login screen.

Would you remember to check the domain? Even if the website opened in the “in-app browser” of your email client, which shows the URL as just a tiny truncated bit of text at the bottom of the screen?

The point is, we’re humans and humans make mistakes. Being vigilant can only help you so much and there will always be times when you let your guard down. Thinking “I study computer security, something like this can’t happen to me” is a great way for something like this to happen to you.

You can’t rely on your brain 100% of the time, so we need to find ways in which we can offload some of that decision-making on computers, which can’t be fooled so easily, for instance finding other ways of authenticating than just typing your password.

Multi-factor authentication#

Because of the many drawbacks of passwords, other ways of authenticating users have been devised over the years. They can be split into three categories, so called factors:

1. Something you know
2. Something you have
3. Something you are

Something you know#

This is the most basic factor, containing all knowledge-based authentication, like passwords, passphrases, PINs and co.

Something you have#

This factor authenticates users by somehow checking they currently possess some physical object, usually via a shared secret that is never fully revealed. A non-tech example might be using two copies of the same book. One side asks “read the 34th word on page 51”, the other complies, certifying they have access to the book. This has the added advantage of preventing any eavesdropping party to misuse that information, as the next question probably won’t be about the same word on the same page.

The first method actually in use are one-time passwords. As with the books, both the authentication server and the token have a shared secret they will never reveal. Then, each minute, they generate a short string of numbers calculated from the secret and the current time. When logging in, the server will only accept the correct string of numbers for the current minute and the device will only generate the string for the current minute, so you need to be in possession of the device to log in. In practice, this can be implemented with a physical device containing the secret, an accurate clock and a small display to display the secret, even though these bespoke devices have been mostly phased out in favour of apps for your smartphone. The main advantage here is there are no requirements on the device the user wants to sign in on other than the ability to type numbers.

Another method are connected tokens. These are small devices, usually connected to the target device via USB, NFC or other means, which also hold a secret shared with the authentication server, but instead of relying on the current time, challenge-response authentication is performed. The server generates a random number and sends it directly to the device, which combines it securely with the secret and returns the result. For added security, these devices often contain a physical button and require a press of the button before answering each such request. The FIDO standard by the FIDO Alliance standardizes this process. In addition to that, the token is informed of the hostname of the website the user is trying to sign into, and may refuse operation if it doesn’t match the hostname which was used to setup the relevant secret.

More examples of this factor include SSH or PGP keys, smartcards including payment cards or SMS-based authentication.

Something you are#

The last factor concerns some inherent property of you, which the device can verify. This is, as you might imagine, usually used for authenticating locally into devices you can hold in your hand. This mostly includes biometrics, like your fingerprint, iris scan or face scan, but can also include things like voice recognition when you’re calling your bank on the phone, your signature or a “biometric” variant of it⁵, or even the timings of your keystrokes.

Location is also part of this factor, even though it is sometimes considered a fourth factor of its own. This can be anything from your bank blocking the use of your card if someone suddenly tries to use it on the other side of the world, Google reporting a suspicious login from a new IP address or an internal company website not requiring authentication when viewed from a computer in the office.

Putting the factors together#

The reason for splitting authentication methods into these three factors is that requiring multiple methods within the same factor usually doesn’t increase security, while adding a new factor is much better. Asking for two passwords isn’t much better than asking for one (in fact, if they’re saved separately, two short passwords are much worse than one long one since each can be cracked separately), just as someone being able to access your phone will probably be also able to access a token on your keys. But needing to steal or crack your password AND get access to your phone is much harder than either of those alone.

Password managers#

The problem with multi-factor authentication is that it requires extensive support from your hardware and all the websites you visit. A great way to secure your accounts with little support from the website themselves is to use a password manager.

A password manager, on the surface, is just a place to store all your passwords securely. But other features of password managers are also important for your security. Firstly, they can generate secure passwords for you as you create your accounts, without you needing to think about it. Another important feature of most password managers is that they can check the website, now commonly even application, into which you’re inputting your password. This is actually an extremely important security feature, as it can protect you from phishing. Once you get used to the fact that login happens automatically or after hitting a well known keyboard shortcut, if you accidentally click a link to a phishing website and try to login, the password manager (unlike your brain) will not get fooled by the design of the website and won’t autofill the credentials for you, which should give you enough suspicion to force you to figure out why the autofill isn’t working and if the domain is correct.

By securing your password manager well, you can essentially add multi-factor authentication to any service you use with little overhead.

You should get a password manager if you don’t already have one. If you don’t know which one to pick, Bitwarden is a good compromise between openness and comfort, for maximum openness and security, you’ll want to pick KeePassXC.

Single Sign-On#

If you’re an administrator maintaining multiple services into which your users need to all login, rolling out a well designed single sign-on (SSO) workflow can greatly improve your security. Both by decreasing the burden placed on your users with managing their credentials and by making it much easier to grant or revoke access to individual users.

Passkeys#

Last but not least, we should mention passkeys. They are an extension of the FIDO tokens mentioned above, but are designed to live directly on your device, as carrying around a hardware token and plugging it into a PC is too cumbersome for many people. Many password managers also support them and the underlying tech is very promising.

Some tips for generating a strong password#

Since you still can’t go without remembering a few passwords, here’s a way you can generate them so that they are still secure, but reasonably easy to remember. This is also super opinion-based and is the method that I (Jan) use.

It’s similar to the correct horse battery staple method, but there are a few considerations to make. First, you should generate the words actually randomly, as mentioned, humans are predictable and if you try to generate random words, you’ll end up using a very limited set of words, which will greatly reduce the entropy⁶ of your password. A good source for words might be a spellchecking dictionary of your favourite editor, or one of the wordlists from this diceware website.

You can take a few attempts to generate a set of words you think would be easy to remember, or generate more words and pick only some of them, as this can make remembering easier and shouldn’t decrease your security too much.

A password generated this way might have the disadvantage that the words are very easy to read over your shoulder if you accidentally type it outside of a password box. To mitigate this a bit and to add a bit of additional entropy, it might be useful to swap few letters with symbols.

Further info#

If you want to know more about this topic, there are some incredible guidelines published by the British National Cyber Security Center both for System administrators, including this handy infographic, and for the general public⁷.

UX injection vulnerabilities⁸#

While phishing usually encompasses a class of attacks which can be avoided by a vigilant user, sometimes a badly designed application can allow attackers to coerce its user interface to look like something else and force its users to do unintended actions. Such bugs are often treated as vulnerabilities, even though there is no technical breach of access.

One example we’ve found in the wild some time ago was in a system which as part of its functionality sent SMS notifications to people. The SMS contained your full name, which you could set to an arbitrary string and manipulate your own instructions into an official-looking SMS.

Clickjacking#

Clickjacking is a type of attack, where the attacker can overlay their user interface over the user interface of a target application, in a way that still passes the user’s clicks down to the target, while the user only sees the attacker’s app.

One place where such an attack is relevant is the web, specifically using iframes. You can create a website with your own clickable elements and then overlay a opacity: 0 iframe leading to the target site. When the user tries to click on your button, they actually click on a button in the invisible iframe.⁹

A similarly nasty vulnerability was discovered this year in Android and was patched only this month.

TLDR#

Authentication & Authorization:

• Passwords are the most common authentication method, but have many weaknesses – predictability, reuse, and leaks. Humans are not designed to stored random unpredictable strings in their head.
• Never store passwords in plain text – use salted hashes with algorithms like bcrypt or Argon2.
• Password complexity requirements and forced rotation often backfire – users just add aA1! or make trivial modifications.

Phishing & Social Engineering:

• Phishing attacks exploit human psychology, not technical vulnerabilities – even security-aware people can fall victim to a well designed phishing attack.
• Pixel-perfect fake login pages are trivial to create; checking the domain is your only defense, and humans aren’t reliable at it.

Multi-Factor Authentication (MFA):

• Three factors: something you know (password), something you have (token/phone), something you are (biometrics).
• Combining factors from different categories greatly increases security; multiple factors from the same category does not.
• FIDO tokens and TOTP apps provide strong second-factor authentication.

Password Managers:

• Use one! They generate strong unique passwords and protect against phishing by checking domains before autofilling.
• For example: Bitwarden or KeePassXC.

Passkeys:

• Modern evolution of FIDO tokens that live on your device – more convenient than hardware tokens with similar security benefits.

UX Injection Vulnerabilities:

• Clickjacking overlays invisible UI elements to trick users into clicking unintended targets.
• Poorly designed applications can allow attackers to manipulate what users see and do.