Wire runs on Android and iOS devices, on Windows, macOS and Linux as well as on web in browsers. Registered users engage in conversations whose contents are synchronized across all devices of a user. This document provides an overview on the cryptographic protocols and security aspects implemented to protect the privacy of users.
Registration on Wire involves up to three steps, whereby only the first is strictly required in order to start using the service: 1. User registration. 2. Client registration. 3. Push token registration.
2.1 User Registration
Wire supports two basic registration flows, which can optionally be composed. All flows have in common that a profile name must be provided, which does not have to be unique. For more details on the data collected please see the Wire Privacy Whitepaper.
2.1.1 Registration by e-mail
Registration by e-mail (figure 2.1) requires a profile name and a valid e-mail address. To verify the e-mail address, the server generates a random verification code c ∈R [0, 2 192 − 1] and sends it to the given e-mail address to complete the registration. The server allows only 3 attempts to send the correct verification code before the code is automatically invalidated and a new code needs to be requested. Verification codes expire after two weeks. Upon successful registration the client receives a randomly generated user ID (UUID v4) and an authentication cookie.
2.1.2 Registration by phone
Registration by phone number (figure 2.2) requires a profile name and a valid phone number. Before the client application sends the actual registration request, it asks the server to send a verification code c ∈R [0, 106 − 1] via SMS to the phone number the user provided. The actual registration request includes c. A client only has 3 attempts to send the correct verification code before it is invalidated, in which case a new code needs to be requested. Verification codes expire after two weeks. Upon successful registration the client receives a Wire internal ID (UUID v4) and an authentication cookie.
Passwords are not stored in plain text on the servers, instead they are passed into the scrypt key derivation function  with the parameters N = 2^14, r = 8, p = 1 and a random salt s ∈R [0, 2^256 −1]. The resulting hashes are stored along with the salt and the parameters in the form log2 N||r||p||base64(s)||base64(hash). Clients only keep passwords in volatile memory.
2.1.4 Password policy
The default password complexity (as enforced by clients) is as follows: • at least 8 characters long • at least 1 lowercase letter • at least 1 uppercase letter • at least 1 number • at least 1 special character
2.1.5 Further data
The following additional data is stored by the servers: • Locale: An IETF language tag representing the user’s preferred language. • Accent Color: A numeric constant. • Picture: Metadata about a previously uploaded public profile picture, including a unique ID, dimensions and a tag. • Cookie Label: A label to associate with the user token that is returned as an HTTP cookie upon successful registration. • App settings: Preferences such as emoji setting, link preview setting, sound alert setting are stored.