AliceBobAndEve

Threat Modelling should be part of your developing process

2020-08-05T00:00:00-05:00

How do you build secure software? We won’t answer that question here, but a useful approach to building more secure software is constructing an explicit threat model and updating it on a regular basis. Instead of creating a giant threat diagram start by trying to apply one of the STRIDE frameworks threats to your system. Choosing a threat modelling card of the day may help familiarize yourself with the vocabulary.

The purpose of a Threat Modelling

Building a system invites of hundreds of possible attack vectors which can even be chained together. The more complex your system gets and the more components your system has, the more vectors you get. The OWASP Top 10 give a glimpse at the top of the iceberg and how diverse these threats are. Usually by gaining experience people tend to mitigate more and more of these threats during the creation of a system. Some of the vectors might be easy to spot (e.g. lack of authentication) and some might be harder to find (chained injection attacks combined with social engineering). For all of them you have to decide if they are in scope or an accepted risk. From all these vectors we need to pick the right ones and apply mitigation techniques to our system. We have to pick because we are usually limited by time and/or budget. Threat Modelling is a tool for finding threats and documenting your mitigations. It helps you to keep focus and invest your time on the right place.

A threat model by itself is not defined standard. The form should heavily depend on the audience and can be a written list of paragraphs like Vault’s Security Model Documentation or an list of thousands of questions and answers about your system, to be presented to regulators.

A popular method is to describe your system with a data flow diagram and try to pin STRIDE oriented threats on the different components. You would then prioritize and act accordingly.

STRIDE is a mnemonic of Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege and was created as a framework at Microsoft. See the original publication “The threats to our products” in this wonderful docx file.

Little and often

The motivations behind threat modelling can vary a lot. Sometimes you find software projects which have created a giant threat model, maybe with support of a security specialist and that’s it. Giant data flow diagram, hundreds of threats, buried deep in a wiki or special tooling. Most of the time, you won’t get any more secure software with this approach. It might even annoy everyone having to create or work with it.

Like Jim Gumbley explained in “A Guide to Threat Modelling for Developers” why it is so important to start threat modelling ‘little and often’. As mentioned, systems are complex things, so we want to break down their complexity during analysis. Little at a time but focused. Systems change and threats change so this adds the need to do this on a regular basis and it’s much easier with smaller units.

Finding threats for a system can be crossing out points on a check list but may also be more like a brainstorming session. This might be easy with a “security mindset” background but the real-world knowledge of the system is usually with the people creating and maintaining it.

To allow a better access to the threats and boost your creativity a little bit, Adam Shostack created the card game “Elevation of Privilege”. It consists of 78 STRIDE cards which can be applied to your prior created data flow diagram. The game design is influenced by serious play principles and focuses on getting actionable items at the end.

The game is nicely illustrated, shared under CC-BY-3.0 and can be downloaded for free. Don’t get distracted by the Microsoft advertisement on 80% of the page.

Elevation of Privilege with its 78 cards is a nice adaptation of Tarot.

The Tarot Card Game

Tarot card decks evolved from adding additional trump cards to the playing cards arriving in Europe in the 14th century. Over decades a lot of regional card decks and playing variants emerged and some of them are still played today, for example the French-tarot played with the Tarot Nouveau card deck or Cego played with the Tarock deck.

Fortune telling using the tarot decks was popularized during the 18th century. The colorful illustrated trump cards made it easy to build up a esoteric system around them. The trump cards (or great Arcana) are illustrated around the Hero’s Journey narrative, therefore they are a perfect fit for complex story telling. Other attributions, like an ancient Egypt origin are not backed by any facts and seem more like a magic powder added on top by different mystics.

It got another popularity boost by the publication of the Waite/Smith deck by Rider (a part of Penguin Public House today) around 1910 and the Thoth deck by Crowley/Harris in the 1940s, both still in use today.

Using Tarot as entropy input

Tarot cards can not only be used for esoteric fortune telling but also as a tool for random input. My colleague @mkhl did write a perfect short summary of that:

And I think random input is underappreciated and can help break out of cycles. The value can be in receiving random input, relating it to yourself, and using that to observe something about your internal state you might not otherwise had access to. (@mkhl on twitter)

Software development usually consists of repeating cycles and ceremony, be it a simple code-and-evaluate loop or a more formalized process like scheduled development cycles with fixed retrospectives. Sometimes you may find yourself stuck inside your focused area and like going for a (virtual) walk or rubber duck debugging can free your thinking, drawing a tarot card, trying to relate it to your problem may also be of help.

For example, if this isn’t a wonderful visualization of destroying the monolith, I don’t know:

Threat Model card of the day

In Tarot there is a simple drawing technique called “Card of the day”. You draw a card before or after your day starts and follow your thoughts around it. This matches perfectly with the principle of “many small threat modelling sessions over time are better than one big threat model”.

Switch the Tarot deck with Adam Shostack’s Elevation of Privilige Card game and you get your daily threat modelling inspiration. Discuss the card, try it to apply it to your system, maybe file a bug or document it as an accepted risk.

Add it to your daily routine, weekly development cycle or simply from time to time.

Remember to have fun :)

The Threat Oracle

Since the future is today, you don’t have to visit any strange fortune tellers trailer, you can get your Tarot cards drawn by friendly and strange Twitter bots.

The same is now possible for Daily Threat Modelling card. Beware of the mighty @ThreatOracle 🐦.

It’s your daily reminder of the evil out there in the interwebs. Currently it draws a card a day from a glitched up version of the Elevation of Privilege deck. No need for manual shuffling and picking cards. Extending it to the Privacy Suite and adding the OWASP Cornucopia deck is work in progress.

Wifi cracking and pwnagotchi - An AI boosted mobile bettercap tool

2019-12-09T00:00:00-06:00

During the last few weeks I had a lot of fun with a nice little project called pwnagotchi. It’s an automation frontend for bettercap, can be run on a Pi Zero and enables automated wifi-handshake collection. An AI supports finding better scanning parameters. And it has an adorable face.

Wifi Handshake Cracking

Some of the basics: If you want to use a wifi secured by encryption, you need the password or pre-shared-key (PSK) to establish a connection to it. The client (supplicant) connects to the access point (authenticator) using the Extensible Authentication Protocol (EAP, RFC 3748). The packets are interchanged via EAPoL (Extensible Authentication Protocol over Local Area Network) frames between the two participants.

Establishing a secure wifi connection in an environment where potential attackers may have access to the communication works like most encryption protocols do: Use some random numbers from both sides, the PSK and generate a temporal key to use (Pairwise-Temporal-Key, PTK). This is necessary because we don’t want every other client who has the PSK to be able to decrypt our communication.

The parameters for the PTK are the MAC addresses of the supplicant and authenticator, a random generated number from each of them (nonce) and the PSK (in this context usually called Pairwise Master Key or PMK). All of them, except the PMK, are shared via a 4-way handshake. Since wifi handshakes are transmitted via air, an attacker could easily sniff these handshakes and try to bruteforce the PMK.

Bruteforcing Handshakes

Bruteforcing a 256-Bit key with all possibilities and zero-knowledge would take forever (about 3×10^51 years with fancy supercomputers). Luckily for the attacker most of the keys are not generated at random and most of the time are human readable. The combination of a poorly chosen passphrase, a sophisticated dictionary/cracker and enough collected handshakes can speed up the recovery of lost passphrases significantly.

John the Ripper has been around for ages and supports a vast majority of common and uncommon used hash formats. Have a look at the source code repository of the Jumbo version to get an idea of supported formats.

The self-proclaimed fastest password cracking tool is hashcat which got more and more popular after the release of its code as open source under the MIT license. At the moment it supports >220 hash formats and makes heavy use of GPUs.

If you want to bruteforce handshakes locally and the keys are not something easy guessable like 123456789 you will need solid hardware with GPU power and a nice dictionary collection. In case you don’t have access to local gaming hardware, AWS offers accelerated computing instances like their P3 instance type with NVIDIA V100 Tensor Core GPUs.

Another option is to use distributed cracking services like the Distributed WPA PSK auditor or SaaS-Services like OnlineHashCrack (which has interesting pricing).

PMKID

The downside of attacks on the handshakes is that you need to collect them in the first place. This takes a client and time to collect the handshakes, and you may need to convert the data to clean it up on any replay counter measures.

To make it easier for a client to decide if its own PSK works for a specific wifi, there is a part of the protocol which describes how to publish a list of supported PSKs. For each supported PSK the authenticator generates a Pairwise Master Key Identifier (PMKID):

HMAC-SHA1-128(PMK, "PMK Name" | MAC AccessPoint | MAC Station)

Depending on the access point’s configuration, these PMKIDs will be sent unencrypted via the 802.11RSN information element.

If we try to associate with the access point, we will get the PMK Name and the required MACs with the first part of the handshake. This makes it possible to crack the PMKIDs HMAC-SHA1-128 Hash without any other clients involved.

This kind of attack was discovered by Jens Steube, one of the hashcat authors, and posted on the hashcat forum in 2018, “New attack on WPA/WPA2 using PMKID”. For another attack example, see @evilsockets blogpost “pwning WPA/WPA2 networks with bettercap and the PMKID client-less attack”.

Bettercap

Bettercap is tooling for various MITM / Spoofing attacks on Wifi, Bluetooth or 2,4 Ghz HIDs. It does network host probing, can capture and manipulate traffic and do port scanning. It also has a nice web ui included, if you prefer that over the CLI. It is written in Go by evilsocket and provides an easy to use API for further tooling.

The Wifi Stack supports scanning and automated sniffing and saving key material from 4-way handshakes. It can create fake access points and supports the PKMID association attacks to collect the proper packets.

Since Deauthentication Management frames are not encrypted, this can be used for another attack. The attacker notifies the supplicant that he got disconnected from the network. The source of the notification is spoofed, so that the supplicant thinks it is from the authenticator. Most of the time this leads to a reconnect from the supplicant with another 4-way handshake to collect.

Read more about the other features in the corresponding modules documentation.

Pwnagotchi

Pwnagotchi is another project from evilsocket combining bettercaps API with an AI, varying scanning parameters to collect more handshakes. For extra fun: Put it on a Raspberry Pi-Zero, add an e-paper screen and if you want a battery pack.

The pwnagotchi will start scanning for wifis, collect handshakes and frames with PMKID and store them on the Pi’s sd-card. You can download the .pcap files via a network connection to your local computer. To get more handshakes it will deauthenticate clients from time to time.

A web ui shows some status information and the cute little face.

You could also run it in manual mode, which exposes the underlying bettercap web ui for manual usage.

The AI part

If you try to get many wifi handshakes there are a some parameters you can adjust in order to get better results. These include the signal strength, different timeout and retry values and periods of waiting. We know that we may have found a good configuration if we collect many handshakes. In a scenario with an access point nearby and many access points far away a rule could be to focus on the access points with the better signal strength.

A neural network can yield pretty good results if you can clearly define some kind of score for achieving what you want. In our case this is simply the count of captured handshakes. If we vary our configuration and get good results, why not keep it for a little while and tweak the parameters. A nice example is SethBling’s MarI/O Machine Learning implementation. See “Neural Network Learns to Play Snake” for another great example. According to pwnagotchi’s Intro, it uses a LSTM network with Advantage Actor Critic (A2C). Have a look at the link to the wonderful “Intro to Advantage Actor Critic” comic.

See Training the AI for a more in-depth view of which parameters get changed and how this affects the neural network.

Pwnagotchi Hardware

Since pwnagotchi is a python package installed via pip, you could just run it on your laptop and access the display via a web ui. Of course it is more fun and a lot more practical to have a dedicated device for it, like the Pi-Zero Configuration mentioned above. The documentation provides an extensive hardware guide with different configurations.

The Pi is reachable via Bluetooth Tethering or a USB connection. You can use the web ui or login directly via SSH.

Pwngrid and Plugins

pwnagotchi is written in python and can be easily extended with custom plugins. For gamification there is a running pwngrid where the units can report found access points and the location country. No private information is transmitted, and if you wanted you could inspect the source code and build the binaries for yourself.

During the first boot, your pwnagotchi creates a public/private keypair to identify itself. After that in can send and receive small text messages from other units via the grid. Every message is encrypted with the corresponding key, so nobody should be able to decrypt the content.

The pwngrid provides some stats of collected handshakes and a country map for registered units.

The best way to get an overview of available plugins is to have a look at the plugins folder in the github repository.

A nice combination are the net-pos and webgpsmap plugins. Net-pos uses the Mozilla Location Services to lookup geopositions. These positions are then shown on a map interface:

It can use the connection of your host laptop or bluetooth tethering via mobile phone to get the required internet access.

Writing your own plugin is straight forward and you can get started by modifying a provided example. The running pwnagotchi itself also exposes a http API.

Peers

For the fun factor, pwnagotchis can announce their presence to other units. If this is enabled meeting other units and making friends may influence the mood of your unit. Here is Axolotl meeting Fuxi:

Running your own

If you intend to run your own pwnagotchi, follow the install documentation. Everything should be straight forward and even without an e-ink display it’s a nice little tool running linux with an wifi chip and bettercap.

Remember: If you want to capture 5Ghz wifi traffic, you will need an additional USB dongle for your Pi.

For updates you can follow @pwnagotchi on twitter or have a look at the disqus board or /r/pwnagotchi. For more insights and details on future releases you can fund the author on patreon.

2nd Factors, an overview about Fido, OATH and One-Time-Pads

2019-11-05T00:00:00-06:00

I felt like upgrading my Yubikey to a USB-C version and use that opportunity to dive a little bit deeper into the different OTP specs and how I want to use my second factor. Still falling down the rabbit hole, but here is some kind of overview of fido2, u2f, oath-hotp, yubico-otp and others…

Two-Factors, Two-Channels and One-Time-Passwords

During authentication you usually present one type of credentials to get access to a system. This is called a factor und usually it is something you know, your password for example. To strengthen a login to a system, you could add one or multiple other factors. This could be something you carry with you (a security key), something you are (biometric data), somewhere you are (IP addresses, specific device details which are hard to spoof) or something you do (for example special gestures). After adding a second factor, you are using two or multiple factor authentication.

To prove that you own a special cryptographic key without exposing it, you would usually present some kind of proof which would be valid for a limited amount of time. This will often be a one-time usable password (OTP), like a generated 6-digit code. The cryptographic key would be stored inside a hardware token or an application of the mobile phone you carry around. It is not just a second PIN you remember. It would also be possible to use OTPs in an authentication as your primary factor, but static passwords are a common pattern so most of the time they are used as a second factor.

Two Channel (or Out-Of-Band) authentication is an additional way to strengthen authentication security. If you remember your static password and possess a cryptographic key on the same computer you are trying to authenticate, there is clearly only one channel used. If the second factor is generated on a dedicated device, we use a second channel. SMS would also be an example for Out-Of-Band authentication, but is not advised by NIST without any counter measures for specific attacks, see Section 5 “Out-of-Band Verifiers” and “Authentication using the Public Switched Telephone Network” in the Digital Identity Guidelines - Authentication and Lifecycle Management 800-63B.

While aiming for a multi-factor, out-of-band authentication might be the most secure option, it can bring additional requirements for account/device recovery with it. Creating a backup of a secret should not be possible, so you will need to store additional recovery codes, weakening the security measures. In the end, even adding a simple second factor on the same channel, will increase authentication security over a static password.

Security Tokens and the YubiKeys

Security tokens are usually a piece of hardware which can have multiple features. Since you usually need to possess them, a common usage is as a second factor.

An example are RSA SecureID Tokens (PDF) which are often used in an enterprise environment. They provide the user with an OTP which changes every minute. During a multi-factor authentication, it can be used as a second factor because cryptographic keys ensure you must be in possession of the hardware token. Of course, you have to keep your private keys private to prevent any attacks on the mechanism. In March/2011 RSA announced publicly an attack against their systems via spear phishing, losing some of the private keys. This lead to another attack two months later on Lockheed Martin and maybe other customers.

Another example of a hardware security token is the YubiKey from Yubico Ltd. The CTO and one of the founders (Jakob Ehrensvärd) is part of the team authoring some of the Fido Standards, which we will look into later (U2F and WebAuthn). YubiKeys come in various shapes and different feature sets and support different types of OTPs. With some support of the industry by giving discounts buying a YubiKey (for example 20% from Github or a key for 5$USD) it became one of the more widely used security tokens outside the enterprise environment.

There is also a credit-card-thin-fancy-e-ink-display-version from Token2 and a whole bunch of other forms and sizes from different manufacturers. In the end, choosing the right one depends on the standards you need support for.

Using mobile phones as hardware platform for OTP applications has become more and more common over the last years. The following picture shows the Google Authenticator application, supporting OATH-HOTP and OATH-TOTP.

Standards and Specification Bodies

If we have a look at the currently supported, relevant specifications we can find two main industry consortiums / projects leading the authorships: OATH and Fido.

While OATH is a little bit more mature, most of the current development and changes happen arround the FIDO project.

OATH - Initiative For Open Authentication

We can find the “mission statement” directly on the OATH consortium homepage:

[..]an industry-wide collaboration to develop an open reference architecture by leveraging existing open standards for the universal adoption of strong authentication.

The members consist of IBM, Axalto, Gemplus, VeriSign and a lot of other providers for software or hardware Identity Solutions on the market. Their main goal is to provide a free-of-cost framework using open standards by either providing them themsleves or supporting standardization (for example through the IETF). They answer a couple of questions about their goals in a FAQ document (PDF).

Apart from a certification of your OATH implementation there is a list of their technical specifications containing beside others:

OATH Reference Architecture V2 (PDF)
OATH-HOTP (RFC 4226)
OATH-TOTP (RFC 6238)

We will be looking into the two OTP specifications.

OATH-HOTP (A HMAC-Based OTP Algorithm)

A “Message Authentication Code” is used to verify the authenticity of a message. It can validate if the message really originates from the sender and that nobody tempered with it. Usually there is the requirement to share a secret key between the sender and the recipient to implement the validation. HMAC (RFC2104) is an implementation of that idea by using a hashing algorithm.

During the registration of your token with the authenticator, the secret key is made known to both parties. A hardware token might have a fixed key or can be configured to one. To generate a One-Time-Password, we need a so-called moving factor and our secret key. The moving factor is a changing value which ensures the password is for one time use only. HOTP makes use of a counter for that purpose. Since the authenticator increments this counter only after a successful login, there might be some synchronization issues, if the client generates more tokens without logging in. To solve this problem the authenticator usually uses a “look-ahead window”. This determines how many increments on the counter the authenticator tries when attempting to get back in sync with the OTP generator.

Side note: OATH-HOTP (RFC 4226) uses HMAC-SHA1 which might make you think of the SHA-1 collisions implemented by the CWI Amsterdam and Google Research in 2017: First collision for full SHA-1 (PDF). This is not a problem in this context, since theoretical attacks on SHA-1 are known since 2005 (see Bruce Schneier: SHA1-Broken), HMAC-SHA1 is not affected by this type of collisions and the HOTP RFC (also from 2005) includes a detailed security analysis on SHA1-Attacks. There are some implementations of OATH-HOTP with other algorithms, but usually HMAC-SHA1 is used.

Using a simple counter instead of using a real clock as the moving factor reduces a lot of the implementation complexity for a hardware device manufacturer. This way you don’t need to keep anything in-sync with the authenticator, only the counter.

OATH-TOTP (A Time-based One-time Password Algorithm)

Keeping a counter can be difficult and may need an extremely large sliding window, for example if the authenticator is easily triggered by the user and gets out of sync after a while.

TOTP specified in RFC 6238 is a rather small extension of HOTP to prevent this problem. It replaces the static counter value with the current time. To account for latencies during the input or in the network, time is usually down sampled to 30 second slices. To prevent brute force attacks, it is also advisable to rate limit any validation requests.

By eliminating the counter, it adds the requirement for the authenticator to be in sync with the current time. This may be a problem on hardware, for example due to a low battery voltage and clock drift, but not if a smartphone application is used. Of course, not using dedicated tamperproof hardware may introduce other attack vectors.

Yubico OTP

Yubico OTP seems to make use of the OATH-HOTP Algorithm and adds a YubiKey-ID as a prefix to the OTP for linking it to a specific pre-registered user id. Further parts are encrypted with a shared secret. To get a deeper look you can visit the documentation of the format or their PHP reference implementation yubikey-val on Github. More information about their opensource implementation can be found on the yubikey-val developer documentation. Accidently triggering OTPs and increasing the counter seems no problem by design because they simply accept the highest value (see the validator implementation). To mitigate attacks the counter is stored in the encrypted part of the OTP. It still seems advisable to add bruteforce protection in addition to their server hardening instructions if you try to run this on your own infrastructure.

One of the selling points of Yubico OTP is that you can use their YubiCloud SaaS to validate your users OTPs. All YubiKeys come pre-registred with the cloud, which can be verified on their demo page:

[..] To use this your YubiKey must be configured to validate against our YubiCloud service. YubiKeys are shipped with this configuration by default.

This may be interesting if you can make use of the available connector libraries.

The description on their website doesn’t come along with many details and the most detailed information I could find is their YubiCloud OTP Validation Service PDF. A wide range of software supporting the algorithm can be found on their Works With page (also interesting for the other algorithms).

Fido2

Fido2 is a project founded by the Fido Alliance and the W3C. Just to get over with the name dropping, fido means: Google, Amazon, Thales, Lenovo, Microsoft, Infineon, VMWare, RSA, Yubico, and a lot of others, see the fido member list for more details.

CTAP, WebAuthN and UAF

WebAuthN is “An API for accessing Public Key Credentials” and a W3C recommendation. It is a browser api accessible via Javascript which can create keypairs and authenticate a user with a previously stored key. Code examples can be found at the WebAuthN Guide, a demo and more references to implementations can be found at the WebAuthN Demo Page. During the authentication process the client signs a nonce with a key specific for the domain it tries to authenticate to. This makes phishing impossible, since an attacker will operate from another domain name and therefore get a useless signature.

The Client To Authenticator Protocol (CTAP) is a proposed standard of the fido alliance to make roaming authenticators like a usb security key or a smartphone accessible for clients, for example a web browser. It’s the counterpart for WebAuthN. All the major browsers do support or currently implement CTAP.

The current state of the CTAP and WebAuthN adoption is summarized at the fido alliance’s posting “FIDO2: Web Authentication (WebAuthn)”. It differs depending on the underlying operation system and hardware connection. Support for WebAuthN is available in major browsers.

The Universal Authentification Framework (UAF) provides a framework for registering a device as an authenticator and use this device instead of a password.

The fido alliance provides a “Specification Overview” with the proper use-cases.

U2F (Universal 2nd Factor)

U2F is the result of a collaboration between Google, Yubico and the hardware manufacturer NXP Semiconductors. The idea was to push stronger authentication by using a dedicated hardware security key to generate a strong second factor. This makes it possible to use a weak and easy to remember password for your online accounts. The standard laid the groundwork for the others and is now referenced as CTAP 1 and governed by the fido alliance.

Which OTP Standard should I use?

This will mostly depend on the supported OTP algorithms of the relying parties you are trying to authenticate with. Most of the online services which support 2FA will give you the possibility to use OATH-TOTP with an application on your mobile phone, such as the Google Authenticator or FreeOTP sponsored by RedHat. Usually the configuration parameters are transferred via a QR code.

If you are the owner of a YubiKey you will find wide support for Yubico OTP which you might prefer to plain OATH-HOTP. Most of the services offering Yubico OTP will depend on their free cloud service. For me this wasn’t an issue for several years now. Other security keys might just support Fido U2F.

Other aspects of the fido2 protocols go beyond only OTPs and may be subject of another blogpost.

Don’t use security questions!

2019-10-07T00:00:00-05:00

The railway company Deutsche Bahn just added security questions to their booking application, or at least bothers me to add some. It’s 2019 and we all should know by now, that this kind of measures weaken security. Let’s see why…

“Security Questions” are one of the more or less common mechanisms trying to improve the security of your online account. It’s an easy way to reauthenticate yourself, should you ever lose your password and get locked out of your account. Usually during account registration you not only get to choose your password, you also get to choose your own personal question and an appropriate answer to it. To prevent users from selecting some apparently dumb and easy to guess question (for example: “What color is the sky?”), they typically can choose from different options.

In case you get locked out of your account, present your personal “Open Sesame” and gain again access to reset your password. You might have to prove owning or having access to the e-mail address you registered your account with, but there are often other channels to bypass additional checks. Customer hotlines are one of the examples for this.

Examples from the Deutsche Bahn App

“Security Questions” are also called “Shared Secrets” which is a form of static knowledge-based authentication (KBA). Sharing something secret might not sound like a good idea, but it has to be something only you know to keep access to your account secure, right?

Here are the questions Deutsche Bahn lets you choose from:

What is your mother’s maiden name?
What is the number of one of your customer cards or IDs?
What is your favorite book?
What is your favorite film?
What was the name of your first teacher?
What was the name of your first best friend?

Wait… what?

Let’s have a closer look

I’m pretty sure we can skip figuring out a favorite book or film. We live in a world where you get achievements for completing your social media profile, have some ask-me-anything-via-twitter-aaS and leave a lot of traces in the world wide web.

It might be pretty easy to figure out a first teacher if you have any kind of online resume or are of course connected to one of the “Did we went to school together” platforms. Sometimes an attacker can connect independent information and link it to you. Who knows that shared secret? You, good friends, your school, your teachers, everyone of the 25 people you went to school with, their parents, maybe the pupils magazine, maybe some archived newspaper article about the great role you played in theatre class. Maybe you didn’t publish this information anywhere online but the attacker can guess your cohort, your school decides to go fully digital and publishes an alumni list without your knowledge and so on.

You may never answer this question in a conversation, but think of the possibilities of good social engineering? Who knows your mothers maiden name? What about a “lost friend” calling your husband or wife, pretending to search for someone? Will they correct a caller if he mentions a wrong name? If you look at a large user base, how likely is it that an attacker can simply guess the most common surnames? According to Wikipedia the most common German Surnames are Müller, Schmidt, Schneider, Fischer, Weber, Meyer*, Wagner, Schulz, Becker and Hoffmann. At least five of them match for people in my circle of friends. Attackers might not even target especially you, they could be just be out for fishing.

A special note about using numbers from “customer cards or IDs”: Using something like the number of your ID is a pretty bad idea. This information is sometimes used to identify you and should be handled carefully, like a credit card number for example. The difference is that credit card numbers are usually handled according to PCI DSS requirements and not stored in plaintext fields which can be revealed by yourself or the support staff member on the hotline. Besides that, remember the Marriott / Starwood Security Incident)?

Marriott believes that approximately 5.25 million unencrypted passport numbers were included in the information accessed by an unauthorized third party. The information accessed also includes approximately 18.5 million encrypted passport numbers.

And yes, in the German version, they call it “Ausweis”, which is usually your passport.

If your data was leaked through the Ashley Madison breach, “data” means also your security questions and answers.

Being a smartass about the answers

You might have thought of something super super secret you are sure nobody will ever guess as your secret answer. Maybe you even made it up, used a book which doesn’t exist or secretly renamed your mother.

Lucky you, but that’s not the point. The question is if this a good practice which increases security or if this a bad practice which decreases security. It’s not about the one single smart user, it’s about the pattern itself and its usefulness in the broad field.

Beside that, making things up or even answering with random garbage is like having a second password. Are you sure you will remember it in case you lost your password after some time? If not, you would have to store it in safe place, maybe a password manager. If you have a password manager you could also store the original password in there.

What does the NIST say? 🦊

The National Institute of Standards and Technology (NIST) is an US federal agency providing standards, guidelines and best practices around several topcis, IT security included. Besides some questionable ties to the NSA (see “What NSA’s influence on NIST standards means for feds and the debate around SP 800-90) it definitely makes sense to consider their recommendations.

NIST issues regularly “Special Publications” and around ~ 170 papers prefixed with 800- are focused on computer security.

The SP-800-63 Digital Identity Guidelines focuses among other things on the problem of claiming a virtual identity by linking your real-world identity to it. This comes in different levels and is called Identity Assurance Level. Linking your real-world identity without physical presence, which is what one would try to achieve by security questions, is called IAL2. They are a way to verify a knowledge based secret (KBV), so we can look up the recommended requirements of SP-800-63 5.3.2 Knowledge-Based Verification Requirements. Some of the mentioned requirements are:

b. The CSP SHALL require a minimum of four KBV questions with each requiring a correct answer to successfully complete the KBV step.

c. The CSP SHOULD require free-form response KBV questions.[..]

g. The CSP SHOULD NOT ask the same KBV questions in subsequent attempts.

i. The CSP SHALL NOT use KBV questions for which the answers do not change (e.g., “What was your first car?”).

So, minimum of 4 questions, free-form, not ask the same questions in subsequent attempts, no static answers. None of the questions qualify for this subset of the guideline. They are still not a good idea, but at least you should implement them by the recommendations, if you have to. Sounds like a horrible UX experience, but United Airlines roled those out in 2016 and also people over at the UX-Wonder-Factory Apple.

Since these guidelines can get quiet long and complicated NIST maintains a FAQ for some of them. The FAQ for SP-800-63 contains two question about the topic:

Short answer, no:

Knowledge-based authentication, where the claimant is prompted to answer questions that are presumably known only by the claimant, also does not constitute an acceptable secret for digital authentication.

KBA for password reset would leave the account vulnerable to takeover. Alternative authenticators for password reset include lists of look-up secrets and out-of-band device authentication.

But do they really leave your account “vulnerable to takeover”? Let’s see…

Conclusion

Stop using them, use better alternatives like mentioned by the NIST: A pre-defined list of emergency recovery codes or out-of-band communication like a SMS. If you have to implement them, do it according to the SP-800-63 requirements.

What better closing then a quote of Bruce Schneiers essay “The Curse of the Secret Question”:

Passwords have reached the end of their useful life. Today, they only work for low-security applications. The secret question is just one manifestation of that fact.