# Bingo: A Semi-Centralized Password Storage System
## 5 System Architecture
### Bingo Proxy
If the API call returns a success status, Bingo stores a new profile for the user with the Domain's ID alongside the user's ID Key hashed with M. While the tuple identifier allows Bingo to verify that a user is registered with a domain, an attacker that manages to steal this information is not aided in verifying that the user is registered with the Domain, nor in the cracking of the user's password. Note that by only storing a profile for the user within Bingo if the API call is successful, the online service associated with the Domain is still given full authority to validate all remaining attributes of the request body, such as the email address or name. A similar workflow takes place during a login, except that naturally a different API route is used. Furthermore, the order of which secret sharing and retrieval takes place in regard to making API requests is dependent on the workflow. During registration, a secret is shared with the network after a successful API call to make sure that the secret should be shared at all. During login, the opposite ordering takes place, with the secret first being retrieved from the network in order to validate the user's identity before sending a login API request. Note that Bingo does not take any responsibility for managing third-party API tokens for a user. It is the responsibility of an online service to assign credentials at login time such that any subsequent requests which are not handled by Bingo can be traced back to the user. 3. Secret Sharing: Bingo Proxy's main functionality set is to distribute and retrieve shares of passwords. Bingo uses the tried and tested Shamir Secret Sharing algorithm, dubbed SSS, which divides a given password into a series of N shares such that the original password can be reconstructed given a set threshold T of these shares. For example, if N = 5 and T = 3, then a share is distributed one per set of five peers, while only three peers must return their shares to be able to reconstruct the password. A threshold allows one to control the desire for availability versus security. If a threshold is set too low, an attacker must only retrieve a small number of shares to crack the password, lowering security. If the threshold is too high, we require a larger amount of active peers to be present in the network for registration and login procedures, lowering availability. Figure 3 displays Shamir Secret Sharing for the given values of N and T.  
To harden the security of Bingo's secret sharing, we aim to prevent the original password from ever being observable. As such, rather than apply SSS on the original plain text password, Bingo Proxy first generates a hashed version of the password with B. With the password hash, Bingo then applies SSS and collects N shares. Note that each registered Domain may set custom values for N and T, allowing a preservice trade off between availability and security, and upholding our desired principle of configurability. While using SSS aids in securely distributing a user's password across the network, we still require a mechanism to fulfill our desired design principle of verifiability, meaning that shares retrieved from peers should be able to be validated for their legitimacy by Bingo proxy. As such, Bingo Proxy employs Verifiable Secret Sharing through the usage of Public Key Infrastructure (i.e., PKI). Public-private key pairs are commonly used in client-server architectures to validate the identity of each party. Since the Bingo Proxy only needs to verify the shares it generates, a nonce is generated for each share, consisting of the Domain ID and User ID tuple. The nonce is then signed with Bingo Proxy's public key and appended to the share. When a share is retrieved and returned to Bingo proxy during a login workflow, an attempt is made to decrypt the nonce with Bingo Proxy's private Key. If the nonce has been tampered with, Bingo Proxy rejects the share, thus providing integrity protection for all exchanged shares and satisfying our requirement for verifiability.