# Bingo: A Semi-Centralized Password Storage System
## 7 Result and Discussion
### Peer Ultime Simulator  
We now transition to our evaluation strategy of Bingo, specifically targeting the desired liveness expected from any authentication system. We define \"liveness\" as the metric that quantifies a user's ability to make use of a service without failure due to a lack of available resources. Since we are not able to deploy Bingo Extensions among enough real-world devices for the sake of an accurate evaluation of Bingo's liveness abilities, we resorted to designing a \"Peer Ultime Simulator\". The simulator is tasked with generating unique schedules for peers to activate and deactivate which mimic the way real people use their browsers. Most people tend to use their browsers primarily towards the middle of the day, when at work or school. Likewise, a minority of people tend to be active primarily throughout the night. We dub these people as \"night owls\". Since the average amount of time spent on browsers daily by most people is between 4 and 7 h, our schedule generator chooses a random number of total hours of active time within this range. Furthermore, each user has a 25% chance of being designated a night owl. Schedules are designed to concentrate most of their user's activity (i.e., being live) towards the middle of the day or night, depending on if the user is a night owl. For example, assuming the user is not a night owl, their activity will tend to be concentrated between 12 PM and 4 PM, much like a person working a day job. Our concentration of live activity tends to follow a bell curve with random outliers in activity to prevent all users from being active at the exact same time intervals. Lastly, in order to save time in evaluating Bingo, our simulator is able to translate each second of real-world time to T minutes in simulated time. For the purpose of our evaluations, we used T = 1, meaning each real-world second corresponded to one simulated minute. Figure 9 shows the workflow of generating schedules and assigning them to peers which are generated. Using our simulator, we generated 300 peers which are each assigned a schedule. Bingo Proxy uses the same metrics of N = 5 and T = 3 for secret sharing, and no relay servers a replication factor of one are used to prevent a heightened illusion of availability. Furthermore, we use a pre-registered user of Social Home in order to which attempts to log in every second (i.e., one simulated minute) for 1440 s (i.e., 24 simulated hours). The peers which store our user's password shares are randomly chosen for each iteration of our evaluation, and so we can conclude that about 30% of peers chosen to store these shares are night owls. Our user is using Google Chrome with Bingo Chrome installed on the same web page for Social Home as in our base evaluation, which used Bingo React. The Selenium browser control software is used to automate the process of logging in. Each time our user attempts to log in, the success or failure of this login is stored by a \"Stats Profiler\" which generates data reports in a manner fit for graphing. Our entire test-bed is displayed in Figure 10. Peers generated by the Static Peers Generator are colored blue or yellow if there are inactive or active, respectively. We ran our complete simulation for a total of 20 iterations, culminating in a total of 28,800 login attempts. We display our results in Figure 11, which shows the percentage of liveness (i.e., successful logins over total logins in a time window) for each simulated hour, averaged over our 20 iterations. As indicated by Figure 11, Bingo's liveness averages between 80% and 95%. While this indicates that at certain points in a 24 h window that users may experience downtime, we still show that despite a low number of shares being distributed and no relay servers being used. As such, we conclude that our preliminary implementation of Bingo shows strong liveness and displays the necessary characteristics to be used as a real-world authentication system. Figure 9: Peer Uptime Simulator generating schedules for peer.