# Bingo: A Semi-Centralized Password Storage System
## 5 System Architecture
### Bingo Proxy  
The core logic for Bingo resides in its proxy server, named accordingly as \"Bingo Proxy\". Bingo Proxy acts as the single source of truth for validation of a user's identity. Unlike a 2 FA providers' authentication servers, Bingo Proxy requires zero out of band interaction by the user, thus simplifying the authentication workflow back down to its bare bones. This allows Bingo to provide a seamless user experience while maintaining strong security guarantees. The following is an explanation of the various components that make up Bingo Proxy. 1. Communication: Bingo Proxy maintains all communications with peers through a dedicated Secure WebSocket Server (i.e., SWSS). Secure WebSockets communicate over TLS much like an HTTPS connection between clients and a given web browser. Secure communication over TLS guarantees that a man-in-the-middle a tempting to eavesdrop on the authentication workflow is unable to read more than encrypted traffic. When a peer becomes live in the network, Bingo adds said peer to a collection of \"active\" peers which may be tasked to store and retrieve password shares. Likewise, when a peer disconnects from the network, its state is set to inactive and is promptly removed from the collection of peers. Peers are never associated with a specific user at the server-side. As such, if an attacker is able to attain a list of active peers in the network, this list does not allow any backtracking to a specific device belonging to a given user, ensuring the desired principle of anonymity. Bingo Proxy requires that all peers listen to two main events, \"distribute\" and \"retrieve\". Peers should acknowledge these events and include retrieved data as required. Furthermore, peers can inform Bingo Proxy of new registration or login workflows with the \"action\" event, to which Bingo Proxy responds with an \"action-update\" event once the workflow has been completed (i.e., a callback). Further details regarding action workflows and responses will be provided in upcoming sections. A full listing of the API events sent by Bingo Proxy can be seen in Table 1. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Bingo Proxy Event** & **Description** & **Bingo Peer Response** \\ \hline ID & Assign a unique identifier to a connected Peer & None \\ \hline \multirow{3}{*}{retrieve} & Retrieve any password & \multirow{3}{*}{retrieve} \\  & shares stored for a tuple & \\  & of a Domain ID and User ID & \\ \hline \multirow{3}{*}{distribute} & Store a share associated & \multirow{3}{*}{distributed} \\  & with a tuple of a Domain ID & \\  & and User ID & \\ \hline \multirow{3}{*}{action-update} & A callback function indicating & \multirow{3}{*}{None} \\  & an action (login or register) has & \\ \cline{1-1}  & succeeded or failed & \\ \hline \hline \end{tabular}
\end{table} 
Table 1: BINGO API EVENTS. API Handler: Registered Domains are required to expose specific API methods to Bingo in order to facilitate registrations and logins. Domain objects should include a base API URL, a login route, and a registration route. For example, a Domain might provide a base API URL of [[https://my-service.com/api](https://my-service.com/api)]([https://my-service.com/api](https://my-service.com/api)) (accessed on 23 February 2022), a login route of user/login and a registration route of user/register. Furthermore, Domains must list which attribute in a user profile identifies the user, an ID Key, as well as which attribute serves as the password, a Secret Key. When registering a new user, Bingo makes an API call to a Domain's registration route alongside the original request body from the user with the value of the Secret Key redacted.