Authentication and Authorization – what is it?

This article has also been published on Emmas blog.


Doing talks in Germany was really fun! I had a blast and learned a lot. My talks can be found here and here.

The most inspiring talk was about Fairytale Protocols (in German) – describing different authentication schemes with help from Arabian Nights and the Grimm brothers. Security pedagogics is a field that still has a lot of room for improvement, and I think this was a great way of bettering the mental picture of different authentication schemes.

Inspired by this, I will attempt to explain some important concepts in security testing: identification, authentication and authorization. Even security applications have a hard time differentiating between these concepts, and if you don’t fully understand them it’s very hard to test whether they work as intended.

Access Control Systems at the Border

Going home from GPN18 by train, I crossed two borders: Germany/Denmark and Denmark/Sweden. Both these borders are between Schengen countries, but they have an Access Control System nonetheless.

The happy path of a border check is supposed to go down as follows:

  • I identify myself with a document
  • The police authenticates me
  • I am authorized to enter the country.
  • Profit

If I have no document, or the picture on the document doesn’t plausibly match me, I am denied (Identification failure). If I can present a document, but the document is not issued in a way that the border police accepts, I am denied (Authentication failure). If I can successfully authenticate, but am on a criminal watchlist, I can be denied entry (Authorization failure).

Downgrade Attacks

As I have travelled between Germany and Sweden by land many times, I know that they don’t always enforce the Access Control Protocol to the letter. There are other ways than just documents or tokens to be authorized. We authenticate and authorize people all the time without thinking of it – you only tell your darkest secrets to your closest friends, and you do different small talk with your colleagues that with the cashier in the supermarket.

Sometimes the fact that I speak Swedish without an accent is enough to let me through a border check. In that case I haven’t identified myself at all, but I have passed a challenge that only a citizen of the Nordic Passport Union is likely to pass. This only works if the police officer I speak to has heard a sufficient amount of Swedish or Swedish German accents before to be able to identify it as such. This type of authentication is based on behavior, and as a single factor it is a weaker form of authentication.

A passport cover is sometimes enough to be allowed entrance to a country

Last time I passed the German/Danish border I only had to show the cover of my passport. The combination of my Nordic features (something that I am) and my laidback behavior (also something that I am), and the fact that I have something that looks like the cover of a Swedish passport (something that I have), is enough to plausibly authenticate me as a Swedish citizen without having to know my full identity.

Another time I presented the German police with my driver’s license and was harshly yelled at. A Nordic driver’s license is accepted at the Danish border, but not at the German. That time I was travelling by long distance bus, and in my experience the authentication scheme is much more harshly enforced on cheap buses than on expensive trains.

In hacker lingo all of the above methods can be labeled downgrade attacks. I negotiate with the authenticating server (police officer) to use a protocol of lesser security. This is usually successful because the threat model the police is working with is that they don’t want to let in asylum seekers. It also works because of the notion, or prejudice, that women are unlikely to be in an Interpol database.


Access Control Systems add a lot of overhead and cause annoyance and delays. This is a general critique against all type of security – there’s a notion that security cannot be done in a seamless way. Indeed this time it did – border checks added about half an hour to my travel time! In contrast, flying to Germany the security check took about seven minutes, and I didn’t have to show my passport once.

How to test

From a tester’s perspective, I think these are the most important questions to work with when dealing with Access Control:

1. How does the system treat identification, authentication and authorization?

2. How well does the chosen authentication scheme match the threat model?

3. How can the User Experience of the Access Control Management be improved?


Happy testing!


The User Experience of a Watermelon — What secure design is all about

, ,

This article has also been published on Emmas blog.


Mmm… watermelons! Tasty, but yet so hard to get.

Reading the UX of a Banana — What UX design is all about, I realized that user security has the user experience of a watermelon.

I have a strong preference for watermelons, but due to their UX, the typical fruit I eat is a banana. (OT: botanically speaking, the watermelon is a berry, but so is the banana.)

Likewise, as a security geek I have a strong preference for security solutions, but it wasn’t until the end of last year that I got around to getting myself a password manager. I still don’t use a VPN when travelling, due to the WTF-level of usability of the ovpn client.

Getting my hands on a watermelon is hard:

  • I live in Sweden, where watermelons don’t grow
  • Watermelons are almost never in season, meaning that most of the time they are both costly and tasteless
  • I go shopping using my bike that doesn’t have a basket
  • If I walk to the grocery store, I bring a backpack, and watermelons have the wrong form factor
  • A watermelon may weigh 5 kilos, and the price per kilo of a halved watermelon is often more than double that of a whole. This means that the weight of my groceries double should I choose to buy one.

The worst part: you don’t know if it’s a good specimen until you’ve gone through the tedious process above. The price tag is the best indicator — cheaper meaning in season and thus higher chance of deliciousness — but it may also mean that the watermelon is just about to ferment.

Eating a watermelon

  • Watermelons require additional tooling in the form of a sharp knife and sometimes a spoon or a fork.
  • It requires some training and technique to eat without ending up with dried out fruit sugar all over your lower face and décolleté.
  • Some varieties have seeds that sometimes surprises you and will slow this sugary indulgence down.
  • They produce massive amounts of waste and can’t be thrown on the garden compost.

If it wasn’t for the fantastic taste, I frankly wouldn’t bother at all.

The false dichotomy of usability vs security

It’s long been said that there is always a trade-off between security and usability. The reasoning goes that adding the extra steps of passwords, certificates, slow encryption algorithms etc. will always happen on the expense of the user’s time and joy.

I, and many others, claim that this is a false dichotomy. Yet we still struggle with the perception that security is clumsy and hard — and often it is.

I would argue that the reality of clumsy security is created by the false dichotomy — system architects and system owners accept this as true and never look for solutions that shift the responsibility from the user to the sysadmins and developers.

You know https?

There is no difference in end user experience between unencrypted and encrypted web.

Https is an excellent example of when good security is transparent to the user. Likewise, when Whatsapp rolled out end to end encryption to 1 billion users, their security was enhanced in the blink of the eye, without touching the UX. Whatsapp is not a perfect system, but everyone with an interest can see for themselves where the easiest attack vectors are. It’s no longer in the transmission of the data.

Shifting responsibility from the user to the experts

So how can the UX of a watermelon be enhanced? Hmm… What’s the primary setting when I get to indulge in watermelon? Hotel breakfast! Fruits are already cut into portion size for me, and I pay the same whether I choose to empty the tray or if I only go for bread, eggs and waffles. The chefs have tasted them for me and gotten rid of the bad melons.

The acquiring, sorting and cutting has been shifted to the people with expertise, and the margin cost for the end user is non-existent.

Likewise, the User Experience of security should be as transparent as possible. Security should simply be there. The information about cipher suites used and vulnerability disclosure policy should be easily available for the interested, but it shouldn’t be a requirement for using the system.


Penetration Testing – But Why?

This article has also been published on Emmas blog.


I am a penetration tester – a legal, ethical hacker. But I am more comfortable with calling myself a security tester or a security analyst, or a SecDevOps professional.

The most common distinction between vulnerability assessment and penetration testing is that the former is automated and the latter manual. However, that’s an over-simplification. Reading this excellent research paper (“Does penetration testing need standardisation?”, Knowles, Baron, McGarr, 2015), the delivery of penetration testing services are of varying type and quality. Specifically communicating and fixing the findings often fall short. And truly  – isn’t fixing the issues the whole point?

I once again tried my sketchnoting skills. In blue are findings from the paper, red are my own remarks.

The certificate I’m studying, Offensive Security Certified Professional, teaches how to perform exploitations end to end – from reconaissance to remote shell. This is a very useful skillset, because it requires you to apply the Hacker Mindset and truly understand the OWASP TOP-10.

However, the bulk of security work in the field is not fancy pwnage and haxx0r exploit development. In most people’s minds, however, this is what security professionals do all day long, and so they think that deep knowledge in that particular skillset is essential.

According to the paper, many companies don’t want actual exploit development in their penetration test. An intrusive penetration test can cause disturbances on the system. And a reasonable management is likely to accept a vulnerability, if the pen tester can present a plausible scenario in words, also without working exploit code.

What really upsets me in this study is the poor quality of the reports:

“Often basically a Nessus output in PDF format” (Knowles, Baron, McGarr, 2015, page 14)

Translated into human readable: any student in my higher vocational studies could do that in the first semester, but without the prize tag of specialist consultants.

The customer expects and pays for a human’s skill: prioritization, attack scenarios, root cause analyses. Such a delivery is downright unethical. The “ethical” in ethical hacking is not only about having permission, but also to deliver what you’re paid for.


Penetration Test Checklist:

  • Do you know what your assets and business values are?
  • Do you already have someone in your organization that has and takes responsibility for security? (CISO, a security minded sysadmin or developer)
  • Do you have a process for prioritizing bugs in general?
  • Are you working towards CI and DevOps?
  • Do you have a nice, prestigeless team?
  • Are you updating your software?
  • Are you running vulnerability scanners?
  • Do you have a vulnerability disclosure program?

If all those boxes are ticked: Congratulations! Performing penetration tests is a cost-effective and smart thing to do. If not, you should probably start somewhere higher up in the list.


How does security testing differ from testing?

This article has also been published on Emmas blog.


You guessed it from the title, but security testing is really just another type of testing. Secure development is not rocket science, but a mindset inside of the scope of any development.

Security is essentially to know your product, both how it’s designed to work (happy path) and how it can be broken (exception paths). If you build a skyscraper, you do not only build it for sunny weather but also for hurricanes. If you’re building software that you sell, the customer expects the software to enable their business, not to block it.

Security is to find bugs and be able to perform good triage on them.

Security is also to have a prestigeless, nonblaming working environment where found bugs actually can be fixed.

I see very talented testers shrug and run away when it comes to security. So let’s be sneaky and stop calling it security testing. How about… regression testing?

Step 1: Regression testing from a security perspective

Let’s look at a possible test chart for the change password feature inside of an app.

  • The user must be logged in to their own account
  • The user must know their old password to be able to change password
  • The user must only be able to change the password on their own account
  • The old password must stop working
  • The new password must start working

Seems pretty straight forward, does it not? This is the type of tests that you do in regression testing all the time. The normal tester would not be intimidated to test the features around account management, but they wouldn’t want to call it security testing. Also, like all regression testing, it’s a first step. There is no guarantee that some guy with a hoodie and bad hygiene won’t hack you. Regression testing will not cover all your bases, but it will cover some and it will increase your confidence in your product.

Step 2: Exploratory testing from a security perspective

I’m sure you some time have been thinking at the airport security how you would go about to smuggle something. Or noticed that they didn’t find that 250 ml tube of liquid you accidentally forgot to put in the plastic bag. What security holes can you think of at an airport?

Thinking like an attacker is a lot of fun, and can expose more serious issues.

The focus of exploratory testing is more on testing as a “thinking” activity. Exploratory testing is a creative exercise!

My colleague Michal excellently wrote that ethical hackers share the same mindset as exploratory testers, and I agree. Where might the system fail? What happens if it does fail? Try to provoke the system into failing, instead of verifying that it doesn’t fail.

As a sidenote: I would even call this methodology a scientific method, or at least the embryo of one. Good science doesn’t verify hypotheses, it falsifies them. A scientist actively and constantly challenges their belief, and that’s what a good exploratory tester or ethical hackers does as well.

Step 3: Domain knowledge of security

This is what most testers mean when they say they don’t know security. They haven’t sorted their knowledge under the “security hat”. They may not even have the specific knowledge needed. Is AES sufficient password as hashing algorithm? (no, and it’s the wrong question) Is it right to send passwords via mail? (nope) What is a security header, why do you salt a password, and goddamnit security will destroy the user experience so let’s skip it all together…

This is where most people feel security fatigue: the feeling that since we can’t protect against advanced threats and targeted attacks, we might as well not put in any effort at all.

Indeed this is daunting. Even I as a security nerd sometimes feel it, so no question many testers will begin before they start. But you’re not alone at this, and by doing the steps above you have already done the most important parts! And there are many helpful people out there willing to bring you cheat sheets and automated testing tools!


Meet the consultants: Emma Lilliestam


House of Test is fuelled by people who thirst for knowledge and dare to be different. In the next 3 posts our consultant Emma Lilliestam will share some of her knowledge in one of her areas of expertise: Security and penetration testing.


Originally Emma didn’t plan to work in a technical field or IT. But her journalist bachelor led her to write about the pirate party in Berlin, and that in turn led to her discovering the Free and Open Software movement and a more philosophical angle to IT. Their work on intellectual property issues and surveillance coupled perfectly with her experiences from working in home care, where it’s important to have a sense of customer service and being non-intrusive.

And so she decided to learn everything there was to learn about security.

She  has worked as an information security consultant, IT supporter, DevOps manager and system administrator, making decisions about what needed to be done, while collaborating with developers, designers and UX experts.

What is security to you?

“Security done wrong can be very narrow. In this mindset, the customer is to blame if they don’t want, or can’t, use a system in a secure way. I see security in a more holistic view – It doesn’t have to be complicated to be good. Security at the expense of usability, comes at the expense of security. If people can’t use secure tools because they are too technical or advanced, they won’t. When working in IT support I discovered what kind of problems normal users have.

It’s so easy to focus too much on one thing and forget the rest of the system. For some people, security needs to be looked at from a cryptographic, mathematical perspective. I’m not that person. Most security things can be looked at from another angle. Reliability, robustness, how the files and databases are structured and are part of the system. You can also look at it from a business perspective, or from a UI perspective.

What do you think of the current state of security testing?

“Security testing suffers from priority issues. Everything that is security isn’t equally important. When I say “This is probably security related”, people freak out and think that’s the end of the world. But just because I see things from a security perspective, doesn’t mean that that particular bug is the most important thing ever and that we need to prioritize it right NOW. There could be other bugs or areas to fix that would benefit the system more.

I’ve found that exploratory testing is extremely similar to a hacker mindset. It’s all about understanding systems, and then exploiting them, trying out different ideas and strategies to find the weaknesses in a system. Security testing isn’t rocket science. Try to find loopholes in the way people designed the system. Most only think about the happy path. The tester and the hacker thinks about how to break the system, in order to build it up again.”

What is a good security tester?

“Ironically, a good security tester is someone you don’t notice. When I do a good job, you won’t notice it, because the customer won’t have failures. No one will call me at 3 am because of a server problem. I’m very proud of how far I got earlier projects, but no one will ever see that work. The most important thing to me when working is that my responsibility matches my freedom to act.”

Where are your greatest talents?

“There is always something new to learn in a new assignment. Everything is still so interesting. What I’m really talented at is fixing stuff and finding the right things to do with the situation and tools that are at my disposal right now. I think that instead of companies saying that they need more talented programmers or expensive systems, they should look at what they can actually do with what is already there. It’s often a lot.”

Other facts about Emma

  • Her first programming language was Python.
  • For a while she volunteered for FooCafe where she was supposed to learn and develop in Ruby. Instead she arranged a full day multi-track tech conference in 31 days. The conference, ADA_Conf, will be held for the third time in October 2018 in Malmö.
  • She builds LED wearables, like blinking glasses or gloves, using Arduino. “It doesn’t have to be fancy code and fancy micro controllers. I make the same circuit again and again, and it just looks different every time. I started doing electronics, bacuse I was finishing education and security became my job. So I needed a hobby that wasn’t about security, organizational IT or fixing stuff. Electronics is still IT, but it’s also creative and relaxing.”
  • One of her inspirations are Simone Gjertz, “the Queen of Shitty Robots”. Simone is interested in the prototype phase, not in making a functioning robot. Instead, she was interested in making a funny robot, and became an internet phenomenon doing it.
Sida 1 av 212