Clever Badges makes it easy for K-2 students to log into applications. As with any new feature, we wanted to understand and address any potential security risks before we launched Clever Badges to our users. If we built Clever Badges without thinking deeply about security, it would have been easy to introduce a vulnerability and weaken the security of our service.
Before we wrote a line of code for Clever Badges, we conducted a security design review, called a threat model, to understand the people who would use Clever Badges and the security risks they face when logging into online learning applications. We continued the security review process throughout the development of Clever Badges, reviewing our code and penetration testing our service for holes. On launch day and today, we feel confident that Clever Badges is the right step forward for student data security.
This blog post discusses two areas of our security analysis in order to clarify our thinking about Clever Badges security. In the first section, Threat Model, we discuss how the design of Clever Badges addresses security risks that exist in K-2 classrooms. In the Technical Implementation section, we talk about the coding decisions we made while building Clever Badges to ensure its resilience against security threats.
Threat Model
What is threat modeling?
Threat modeling is a structured process for identifying security risks in a system. Our threat modeling exercise during the Clever Badges design process provided real-world context for the rest of our security review by clarifying what Clever Badges does, who uses it, and what might go wrong.
How do Clever Badges work?
The first part of the threat modeling exercise is identifying the different user types, use cases, and data flows of the system. Diagram A is an example of a user-centric data flow showing how Clever Badges get from our service to students:
Diagram A: Flow of Badges from District Portal to Student Portal
We also examined the technical system architecture, and thought about how sensitive data flowed through the various components. Diagram B shows how data flows through our systems:
Diagram B: Flow of Badges from QR Code Generator to Login Service
The next step of the threat model was a discussion of how internal and external attackers could subvert the proposed design in order to compromise the assets in question, like student data.
How do K-2 students sign-in today?
One thing that became clear early-on is that account security and passwords in a classroom environment with young students operate very differently than in a traditional authentication context.
For most online services, users use an existing trusted channel like an email or phone number to create a password, and that password must conform to some complexity requirements. K-2 students don’t have these trusted channels. They often struggle to enter even a short username, and a complex password would lead to frustration and cut into instruction time.
In K-2 classrooms, teachers are in charge of getting passwords to their students. These passwords are usually distributed in a printed format, like on a student’s folder, or on popsicle sticks that are handed out and then re-collected during each class.
They may be taped to desks or written on the wall. These passwords are often trivially guessable. Some can be simple words like (‘apple’ or ‘banana’), they can be publicly displayed, and they are often taken from other contexts (‘your lunch ID number’). In many cases, the passwords are the same for every student.
From a strict security point of view, these practices can be somewhat shocking. But it’s also easy to see them as direct result of the burdens that come with distributing and using passwords in this unique environment, and the desire for teachers to maximize student learning.
How do Clever Badges change the K-2 sign-in process?
User testing showed us that Clever Badges are easier to use than even the most easily guessable passwords for K-2 students to use. But how do they affect the security threats?
For Clever Badges, the sole authentication factor is physical access to the printed badge. If an attacker steals or takes a picture of a badge, they can impersonate the owner. That’s why Clever Badges alone wouldn’t be suitable for many authentication scenarios.
To understand why Badges is a security improvement for the typical K-2 classrooms, consider the following:
- For K-2 students, memorizing and typing complex passwords is infeasible
- Hence, the norm is simple passwords which are printed out and given to students
- Badges are like printed out passwords except they are easier for kids to enter and impossible for attackers to guess
The threat of someone physically stealing a K-2 student’s credentials is limited to people in that student’s classroom, like other students, teachers, and visitors. While this can be a nuisance, it’s something that teachers and students deal with every day with existing password systems, and is limited to a small group of supervised would-be attackers.
On the other hand, the threat of someone guessing or brute-forcing a simple password is only limited to everyone on the internet. When you have to choose a short password that is easy for a kid to type and a long password that is hard for an attacker to guess, most schools opt for ease of use. And when you take a weak version of ‘something you know’ and print it on on ‘something you have,’ you end up with the weaknesses of both types of authentication.
Badges may be even easier than passwords for teachers to manage in the classroom. When a student steals another student’s password, it may be difficult for a teacher to notice if the password doesn’t need to be visible to log in, and hard for the teacher to undo if the student remembers the password. Meanwhile, if one student steals another’s badge, it’s very visible in the moment, and easy to undo (“Johnny, give Sarah her badge back!”).
| Threat | Simple Passwords, Written Down | Clever Badges |
|---|---|---|
| An attacker with physical access to classroom attempts to steal credentials | Mitigated by teacher supervision | Mitigated by teacher supervision, may be easier to supervise |
| An attacker on the internet attempts to guess credentials | Mitigated by rate limiting, which may lock out legitimate users. Rate limiting does not mitigate attacks where the password is very easily guessed or reused on other vulnerable services. |
Mitigated by cryptographically-secure random value, which is infeasible to guess. |
Simply put, Clever Badges have a ‘physical access’ attack surface that is similar to that of passwords printed and distributed by teachers, but they are more resistant to brute forcing or password guessing (a topic covered more deeply in the Technical Implementation section below). This means that in addition to improving usability, Clever Badges reduce the impact of one threat (‘brute forcing’) while not significantly affecting another (‘physical access’).
What are other security considerations for Clever Badges?
There are security problems that Clever Badges don’t solve. It doesn’t fix phishing and it doesn’t solve the end-to-end credential distribution problem. There is a high degree of ‘user error’ that can lead to the subversion of any password distribution scheme that involves handing out physical credentials.
Today, a small number of schools are using Clever Badges via Clever’s pilot program. We will be observing usage data like login rates to improve the security and usability of Clever Badges. We’re also listening closely to the feedback we receive from our users and application partners. They know classrooms best and their experiences are essential to optimizing user security practices for Clever Badges.
Our primary goal with Clever Badges has been to make it easier for young learners to log in. We believe that Clever Badges make a better security and usability tradeoff in K-2 classrooms than existing password systems do today. We know from experience that not all users make the same risk decisions. So while Clever Badges can make transformative improvements at some schools, it may not be right for others.
Technical Implementation
Clever Badges are QR codes that encode four pieces of data:
- a unique identifier that maps to the student
- a version number for the badge
- a sequence number that increments each time a new badge is created
- a token consisting of 12 bytes of entropy
Diagram C: QR Code Data Breakdown as Byte Array
As an analogy, the unique identifier can be thought of as a ‘username’ and the token as a ‘password.’ Together, they log the user in. The token is the security mechanism that prevents an attacker from guessing the QR code.
How difficult is it to forge a Clever Badge?
If the token were four digits (like a bank PIN or phone unlock code) then there would be 10^4 or 10,000 possible combinations. To guess a random four digit token, it would take about 10^4/2, or 5,000, guesses (dividing by two since you’d find it after guessing half of the combinations on average). Without anti-automation built-in, this would be pretty easy to break with a simple script.
12 bytes of entropy means that, on average, you’d need 2^(12*8)/2 attempts to guess the token in a Clever Badge – approximately 40 octillion attempts. Even if someone made one million guesses per second (which we would detect in our logs and actively block) it would take over a quadrillion years to guess. It’s approximately equivalent to a random 15-character alphanumeric password with symbols.
How are Clever Badges data stored?
The token is generated using a cryptographically secure random number generation algorithm. It is stored on our servers as a SHA256 hash. We considered using a hash stretching function like bcrypt, but found it to be unnecessary given that the token values are random with high entropy. Even a computer that could perform a billion hashes per second with access to a million token hashes would take an average of one million years to get a valid token. Using SHA256 also helps mitigate timing attacks, since the comparison time does not relate the similarity of the guessed and stored tokens.
How are Clever Badges data transferred?
The Clever Badges login page uses client-side Javascript to parse the values from the image of the QR code from the web camera and pass them to the server-side over a TLS encrypted connection, where they are validated. No video data is sent to our servers. On the server, the validation process first validates the data is well-formatted, looks up the record associated with the student unique identifier and sequence number, and verifies the token matches using SHA256. If all elements are confirmed, Clever sets a cookie on the user’s browser which allows it to use OAuth 2.0 to sign in to other applications. This is the same functionality used with standard Clever passwords.
What other security considerations went into Clever Badges?
Teachers and administrators can revoke Clever Badges using the Clever dashboard. When a badge is revoked, the record is regenerated in the database with a new token and the old badge can no longer be used to log in. We use the sequence number in the badge to track Clever Badges from generation to usage, to help clarify situations where Clever Badges have been improperly used.
We run a bug bounty program, and any researchers who report a security vulnerability in Clever Badges will receive a cash payout. We also perform our own code reviews and audits for all security-sensitive feature changes.
Security is an important aspect of Clever’s promise to schools, and we know that security guarantees without evidence are implausible at best. We welcome feedback about the security of our products and features, and we strive to provide all the transparency necessary to assure you that the data we steward is safe.
For more information on Clever’s commitment to student data privacy and security, visit https://www.clever.com/security or read our Clever Security white paper.