What makes nextAuth so different?
nextAuth provides end-to-end authentication and uses strong public key cryptography to do so. The private keys are stored at the nextAuth mobile SDK (embedded in a mobile app). The corresponding public keys are stored at the nextAuth server. After exchanging public keys, mobile and server run the SIGMA-I protocol to ensure mutual authentication. We selected this protocol by Krawczyk because it is mathematically proven and widely accepted within the academic cryptographic community.
The nextAuth mobile component is designed to deliver maximal user experience without compromising on security. This means not only ensuring the minimal number of user interactions, but also providing the right amount of context such that the user can make an informed decision.
We took into account the principle of psychological acceptability by Saltzer and Schroeder; the ten usability recommendations by Molich and Nielsen; and user interaction design for secure systems by Yee.
The nextAuth server component is implemented as a RESTful API to ensure easy integration with the application backend server. The nextAuth server is meant to be run on premise, as close as possible to the application backend. Running an authentication service on premise as opposed to as a service in the cloud has the following advantages:
It is clear that passwords on their own will not be sufficient in the future. Users often do not adhere to password policies (do not reuse, do not write down), choose easy to guess passwords and are susceptible to (spear-)phishing attacks. Next, adversaries could also infect the user’s devices or attack the TLS connection over which the password is sent in clear to the server. Furthermore, password breaches of widely used services occur on a regular basis. Even if the password table is protected (e.g., with a salted hash), an adversary with access to the database can bruteforce the majority of the passwords. This is because a typical password only has an entropy of about 24-30 bit, which can be bruteforced on a standard computer in minutes. Most of these issues disappear if one switches to public key authentication instead of passwords. The secret (private key) needed to succeed in the authentication never leaves the user’s device, i.e. it is not stored at the server nor sent over. This means that even if the server’s authentication database leaks, it does not help the adversary to authenticate as one of the users. The nextAuth mobile handles the generation of public/private keys, for which it registers the public key at the nextAuth server and stores the private key. Note that we do not deploy a PKI and corresponding certificates; the nextAuth server keeps a list of registered public keys.
Next to the private keys (first factor – possession), the user needs to provide a second factor. This second factor is a single secret, which can be a PIN for the user to remember, a biometric like for instance a fingerprint, or coming from another device the user carries like for instance a smartwatch. To avoid bruteforce attacks on the nextAuth mobile, the secret is verified online and the nextAuth server implements a lock-out mechanism based on the number of consecutive failed verifications. The verification is done in zero-knowledge, i.e., the nextAuth server never learns the secret. We thus achieve true two factor authentication: an adversary needs to compromise at least two out of three: the secret, the nextAuth mobile, the nextAuth server. This allows us to use the same secret for all possible nextAuth servers.
Because we create an extra channel between the nextAuth server and mobile, we are not restricted to traditional TLS connections. We can easily deploy another protocol without interfering with the existing application frontend-backend connection. We deliberately chose not to base our main security protocol on TLS but instead adopted the SIGMA-I protocol for the nextAuth application. This is mainly based on the poor security track record and issues around (public key) client authentication of the TLS protocols. Keeping TLS secure requires frequent updates of both the server, and the app. In case your app makes use of the TLS system libraries, you are dependent on users updating their systems, when and if their smartphones receive these updates. Furthermore, we believe that TLS is overly complex and does not reflect recent advances in protocol design. This can clearly be seen from the algorithm agility perspective: TLS relies on negotiation of the algorithm suite, allowing for a myriad of algorithms, several of which are sub-optimal security-wise. Even though parameter negotiation is great for backwards compatibility, this comes with the risk of an adversary negotiating both parties in the weakest protocol parameters. One needs to establish a secure link between the frontend-backend session and the nextAuth session. The frontend will set up a connection with the backend, and receives a message containing both the server and session identifier. This message will be transferred by the frontend to the nextAuth mobile over an authenticated channel. Based on the server identifier, the nextAuth mobile knows which nextauth server it needs to authenticate to.
The authentication protocol is based upon the SIGMA-I protocol by Krawczyk. The original proofs by Canetti and Krawczyk still hold for our construction. SIGMA-I is a very efficient mutual authentication protocol with key agreement with the added benefit that the mobile can delay sending its identity until it is convinced of the server’s identity. The shared key K is derived using a key derivation function (KDF) from an unauthenticated Diffie-Hellman key agreement (here instantiated with the elliptic curve variant). By having each party sign (SIG and VER) the exchanged Diffie-Hellman values, the origin of the messages is established. As already suggested by Krawczyk, we use an authenticated encryption (AE and AD) mode to optimize the protocol. We use the same protocol for different purposes: login and enrol. Therefore the purpose is explicitly encoded in the type, which is part of the signed message. Since the mobile already knows the identity of the server, this value can be omitted from the protocol. For the identity of the mobile, we use its public key. Before accepting the mobile, the server will also verify that the provided credentials are registered in its database. The provided session identifier allows the server to link its nextAuth session to the frontend-backend session.
We establish a secure channel for exchanging subsequent messages between mobile and server, based on the shared key from the authentication protocol. Using this secure channel, mobile and server engage in continuous authentication. Both the server and mobile can terminate the continuous authentication process, resulting in the user being logged out.
nextAuth uses an efficient cryptographic library providing constant time implementations. This is important for side channel resistance. Otherwise, an adversary can learn information on the secret key just by observing side channel information (precise timings for a given cryptographic operation). The mobile’s core functionality is implemented using an obfuscated compiled library, making it harder for adversaries to reverse engineer. The used elliptic curve, Curve25519, has several security advantages compared to the NIST curves. Therefore, nextAuth uses this curve for both Diffie-Hellman and the signature scheme. Concretely we use the Ed25519 signature scheme, which in comparison with the widely-used ECDSA signature scheme is less vulnerable to leakage of the secret key in the case of bad randomness.
