This section applies to the June 2023 version of the Platform.
The June 2023 rollout introduced User Accounts to the Platform. User Accounts allow voters to further-secure their personal information by only allowing them, and nobody else, to use it when casting votes in a referendum. As part of this, it is required that personal information is stored separately from votes, as a method to prefill the required fields of a vote record.
All User Accounts are protected with a password of the voter’s choosing, and this password is persisted using a highly secure, pseudorandom hash (more on this below ). The Platform requires that all passwords meet a minimum set of requirements to ensure strong account security. When choosing a password, users must provide at least eight (8) characters consisting of at least one (1) number, at least one (1) lowercase letter, at least one (1) uppercase letter, and at least one (1) special character (symbol). Users may not choose passwords that have been leaked as part of a data-breach on another website or system. The Platform securely and anonymously makes use of the haveibeenpwned.com/passwords service to determine if a password is not safe for use.
Personal information stored against an account is not encrypted using the same algorithm used for vote data encryption, briefed in the previous section. Due to the nature of user accounts, and how they additionally need to be looked up in order to prevent data collisions between two or more accounts, data points are individually encrypted using the XChaCha20 stream cipher, which is a symmetric encryption algorithm that is known for its simplicity, high performance, and strong resistance to various cryptographic attacks. Unlike AES-256, it operates on 512-bit state, a key, and a 192-bit nonce, producing a stream of pseudorandom data that can be used for encryption and other cryptographic purposes. Encrypted ciphertext authentication is done using BLAKE2b-MAC, which is resilient to key-substitution attacks.
This encryption is performed using a completely separate secret encryption key that, like the key used to encrypt vote data, cannot be accessed by the outside world.
Coupled with this form of encryption, the Platform makes use of blind indexes that help it satisfy the need to perform data the lookups described above. These blind indexes use multiple filter strategies to allow for quick cipher-text search with minimal data leakage (at worst). Each blind index uses its own key, distinct from both the primary encryption key and from every other index encryption key. This allows the Platform to securely encrypt and hash all personal data, while still allowing it to be searchable by the Platform without storing it in plain text.
Unlike vote data encryption, the Platform does not encrypt each data-point individually and then as a bundle, as this would prevent the Platform from functioning as described (searchability). Instead, each data-point is encrypted on its own and stored separately. Blind indexes are not stored alongside the data they index.
When a User Account has an active session (Authenticated User), it is able to decrypt data that belongs to it. For example, an Authenticated User can access their User Account information by navigating to the “My Account” page (the Page) on the Site. When serving the Page, the Platform securely decrypts the information held by the User Account and presents it to the Authenticated User. This information includes all basic User Account information, such as the Authenticated User’s name, email address, contact number, and identification number (which is initially partially masked, but can be revealed by clicking on the “eye” icon on the Page, which initiates a secure, signed request to the Platform). Additionally, event information about previous votes cast by the Authenticated User is decrypted and displayed on the Page, along with the creation timestamp of the sole audit record and the User Agent that was persisted on the same audit record (see the next section pertaining to audit records and how they work).
 When hashing User Account passwords, the Platform uses a highly secure cryptographic hash algorithm that produces a large fixed-size hash that cannot be reversed. The size of the hash is determined during the initialization step of the algorithm, which takes the user’s password as input and generates an initial state, including a pseudo-randomly generated salt and other parameters, such as the memory size, number of iterations, and parallelism degree. The hash is computed, finalised, and then persisted in a manner that prevents pre-computed tables, such as rainbow tables, from being effective in an attack (that is, if the database were ever to be compromised).