For Organizing Contests

This guide encompasses various things to consider while organizing a competitive contest using our platform, and describes the generally recommended processes and configurations for doing so.

Valuing Challenges

It is recommended to use Dynamic Points System for challenge flags as it is more fair to the participants. In this system, the points dynamically reduce as more submissions are made for a particular flag, for everyone who has submitted the flag. Hence, a challenge with more solves will have fewer points since it is likely to be easier, and a challenge with fewer solves, indicating relative difficulty will have more points.

Static points system is also available, but it is not recommended as the points determined by the authors can be biased and doesn't take into account the general perceived difficulty of the challenge as a dynamic system does.

Giving Prizes

Prizes can be good motivators for participation in contests. However, they can also encourage some people to cheat or engage in unsportsmanlike behavior. If you are running a contest that gives out prizes, please consider the following:

• Participants may create throwaway (dummy) accounts to unlock hints or to test out flags. Therefore, you can -
  • Decide to close registrations early.
  • Decide to manually add/review participants in the contest.
• Participants may try to trade flags with each other. Therefore, you can -
  • Use the Unique Flag feature, so that every participant gets a different flag.
  • Use the Automatic Submission feature, so that participants do not get to see the flags, and instead submissions are made automatically when they solve.
• Crashing challenge instances so that other participants cannot solve challenge after they have solved it. Hence, you should not use shared instances but use On-Demand Deployment feature of the platform, so that each participant gets their own instance with an unguessable URL.
• DDOSing the platform to prevent other participants from solving challenges. This is not possible as the platform is designed to be resilient to such attacks. However, if challenges are hosted on a shared server, or managed by the organizers themselves, then they should be aware of this possibility.
• Putting incorrect flags into challenges to waste other teams and organizer's time. Authors of challenges should be aware of the possibility that users may be able to modify the state of the challenge instance either through the interface (such as UI forms) or by gaining RCE (Remote Code Execution) on the instance.

Preventing Cheating

Here are some features that can help you prevent cheating:

• Use Unique Flag feature, so that every participant gets a different flag.

• Use Automatic Submission feature, so that participants do not get to see the flags, and instead submissions are made automatically when they solve.

Asking extra information from participants

The platform supports adding custom fields to the registration form or user profile. This is useful if you want to collect information like Roll No, Employee ID, Phone Number, Shirt Size etc. from participants, or Twitter Handle, Company Name etc. from teams etc.

Both Custom Registration Fields and Custom Profile Fields perform the same functionality if used for individual participants, but they are different if used for teams. Custom Profile Fields are used to collect information about individual participants, while Custom Profile Fields are used to collect information about teams.

If you need to ask for an information to all users (i.e. including individual members of a team), then you should be using a Custom Profile Field. However, if all members of the team have some common information, and you need to collect it - such as school, country etc.

• then you should be using a Custom Registration Field, which will only be asked to the captain and not repeatedly to every member. Profile fields are useful for individual information such as shirt size or food preference etc.

Also, there are some special fields that can be activated - Affiliation, and Country. These fields are asked per participant (i.e. once per team), and support to be used to filter scoreboards/submissions, generate various analytics etc. unlike other custom fields.

Limiting Team Size

If you are organizing a team CTF, you can optionally set a maximum team size limit, so that arbitrary large teams do not get an unfair advantage over smaller teams. However, this is only a soft limit and doesn't prevent teams from sharing accounts or users using the same computer.

To address account sharing, you can turn on Enforce Single Session setting from Settings > Security & Privacy > Security Settings, so that users can only login from one device at a time.

tip

Restricting Parallel Solving

You may also optionally set Maximum Simultaneous Instances to a lower value (i.e <= team size), so that teams cannot simultaneously start instances and try and solve several challenges. This is an efficient means to ensure that larger teams do not get to try and solve several challenges at once, and hence get an unfair advantage over smaller teams. However, this is only effective if you are using On-Demand Deployment and for web-based challenges.

Similarly, you can schedule and release challenges gradually, so that larger teams cannot set out to solve all challenges at once.

Allowing Users to Continue Solving Challenges After Contest Ends

If you want to allow users to continue solving challenges after the contest ends, you can turn on the Allow Access after CTF Ends setting from Settings > Challenge > Deployment Settings.

Turning on this will allow participants to view and try challenges after the CTF ends. They will also be able to access the challenge attachments, start challenge deployments, and submit flags, but any flag submissions they make will not be counted.