One of the things that you can see from my initial state diagram is that I’ve included a timer. A timer passing a certain threshold value can be used as a way for the firmware to interpret the user essentially saying “this is what I think the code is”. I wanted to take this approach until my lab technician asked me, “well, what if the user is old and has a hard time remembering things?”.
This is the essence of real-world engineering. There are no perfect solutions. Only trade-offs that can be managed. The reason why I wanted to use a timer was that it would hide the length of the passcode from the user. But this would mean a slightly unpleasant experience for someone who has a hard time remembering and having to start all over again when the timer runs out. But on the other hand, with the approach that I ended up taking, it means that when a fraudulent user enters a code at random and the buzzer goes off suggesting a failed attempt, the user can gather as much the length of the sequence. This is information that’s revealed about the passcode which is a potential security hazard.
Balancing these trade-offs and playing the roles of both a white and black hat hacker were the biggest takeaways from this project.