Skip to main content

Success Guide

This document will focus on different things to consider when developing your CTF and discuss the generally recommended processes in CTF development.

How long should my CTF be?

The length of your CTF is generally dependent on what the goals are for your event. Here are some examples of what is generally done for different types of events.

Competitive Events

Competitive events generally tend to last approximately two to three days. 48 to 76 hours. Most of the time over a weekend from Friday to Sunday. This is when the most people have available time to play.

Introductory Events

Generally events intended for new or younger CTF players last longer than public competitive events. Introductory events typically last a minimum of two weeks but can often go for months. This gives teachers and classes time to allocate time to teach concepts and to treat the event as a class exercise.

Company Workshops

Internal company workshops generally last approximately two days to a week unless there's some other scheduled plan or simultanous conference. In addition, workshops typically leave their event infrastructure open after the official end.

By having the workshop run for a week, participants don't need to feel torn between participating and their normal work obligations. By having the event be longer and also be available after the end, teams can share their solutions and let others see what they had missed or how they could've solved the challenge.

Should we offer prizes?

Prizes are good motivators for participation however keep in mind that prizes can also be a motivator for cheating or unsportsmanlike behavior. Some examples of unsportsmanlike behavior include:

  • Creating throwaway accounts to unlock hints or test out flags
  • Crashing servers so that other teams cannot solve challenges
  • DDoS'ing servers so that other teams cannot solve challenges
  • Putting fake flags into challenges to waste other teams & organizer's time

Flag Formats

Flags (a.k.a. solutions) to challenges should generally follow a format. For example flag{this_is_a_flag} has a format where flags are in between the curly brace and have the flag prefix associated. This allows players to know with confidence when they've found a flag.

It's bad practice to have a flag that's difficult to identify as a flag. For example randomly finding 401e48c9a96dc219c32ab5e75204b655 (md5(this_is_a_flag)) in a file doesn't indicate to the user that it might be a flag.

Is guessing okay?

Guessing is a tricky concept in Capture The Flag competitions because sometimes guessing is a good game mechanic. For example, if a user knows that there are only up to 256 possible solutions to a problem, it may be worth it for the user to simply try all 256 combinations.

The problem with guessing is ambiguity. If you have a problem where users need to guess with an unconstrained solution set, it leads to a poor experience because users then have to try lots of possible solutions without gaining any kind of knowledge.

One possible scenrio where guessing is good is when you have a problem where the objective is to reduce the possible solution space. For example if you have a problem where the challenge asks you to bruteforce a password, however you can slowly leak out parts of the password making it easier to bruteforce.

In general though, it's rarely a good idea to have guessing in the flag itself. A user should know confidently when they've found or obtained a flag.