A zero knowledge proof (ZKP) is a cryptographic method that allows one party (the prover) to demonstrate to another party (the verifier) that a particular statement is true, without revealing any information about the statement other than that it is indeed true. Applied to authentication, the “statement” the prover is demonstrating is knowledge of a secret value, such as a password.
Using a ZKP, the prover can prove to the verifier that they know a particular authentication secret without the verifier learning the secret or any information about it. If the verifier doesn’t learn the secret, it doesn’t have to worry about protecting it, and the prover doesn’t have to trust the verifier to keep the secret safe.
You can learn more about how a ZKP works from this explanation
, and check out the math behind the ZKP NuID uses in Section 2 of our white paper.
In the traditional hash-and-store method of authentication, passwords must be provided to the server in plaintext. This means the server learns exactly what the password is, and is then responsible for safely storing that password. Unfortunately, this doesn’t always work out.
Some of the weakness of the hash-and-store model include:
When passwords are sent to a server to be hashed, they can be intercepted and compromised. Encrypted transport with SSL mitigates this risk, but threats such as compromised WiFi connections can still result in credentials being obtained from traffic between the client and server.
More importantly, hash-and-store is not always set up correctly.
Accidentally storing plaintext passwords in logs or something similar is
unfortunately alltoocommon.
Even when passwords are hashed, they can still be vulnerable. Attackers steal hashed passwords all the time because they know that some of them will be easily cracked. The strength of the hashed passwords depends on the hashing algorithm used by the service—a more computationally intensive password hashing algorithm like Scrypt is considered more secure than algorithms like MD5 or SHA1, which still see common use.
With NuID’s zero knowledge authentication protocol, passwords never leave the users’ devices. Only public zero knowledge reference parameters—similar to public keys—are sent to the server and NuID API. If an attacker gains access to your server or intercepts traffic, they won’t capture any sensitive authentication data.
No. When a user types in their password, our client libraries use the password to generate ZKP parameters (for registration) or complete a zero knowledge proof (authentication). The password is not persisted on the device, or anywhere else. User identities are not tied to a specific device, so users can login from anywhere.
We use a blockchain to store the public zero knowledge proof “reference parameters.” These ZKP parameters are similar to a public key generated from the user’s authentication secret. The parameters are non-sensitive, which means they can safely be stored in public.
An immutable and decentralized storage mechanism allows authentication credentials to be independently verified by any participant without mutual trust between participants. This means that even NuID doesn’t own and control users’ identities. Using a blockchain as a storage layer means that NuID credentials are solely user-owned.
NuID uses the Ethereum ledger as a storage layer. Ethereum was chosen due to the maturity and accessibility of its developer tooling. However, other layers in the architecture don’t depend on a specific credential storage implementation. Alternative storage layers, including both blockchain and non-blockchain options, may be supported by NuID in the future.
NuID adheres to an “open-core” model. This means our service is a
combination of key open-source libraries, such as our cryptographic proof
generation and verification librairies, and proprietary services on top of
this open-source layer. You can find our open-source libraries on GitHub.
Developers can choose to use our open-source libraries to build and
host their own implementations of trustless authentication. However, we
offer a simple and low-cost RESTful API to simplify proof verification and
interactions with the ledger. You can get access to the API for free on our Developer Portal.
Traditional AaaS providers may take the burden of building secure login off your plate, but they don’t fundamentally change the risk that burden entails. NuID’s trustless authentication model eliminates the need for centralized password storage, removing the opportunity for a mass credential breach.
Besides providing a more secure method of authentication, NuID is also
a more privacy-forward and user-centric approach to digital identity. Our
mission is to return data ownership to the individual—and we’re just
starting with passwords. To learn more about our vision for decentralized
identity, check out the NuID White Paper.
Finally, we’ve put the developer experience and efficient infrastructure at the heart of our design priorities. Our goal is for NuID to be the easiest option for adding login to your applications.
Using NuID does not require any changes to the password reset flow of your application. Resetting a user’s password reduces to the user simply registering a new credential and following any out-of-band verification (e.g. a password reset email) required by your service to reassociate their existing application data to the new authentication credential.
There are many important implications in storing pseudonymous public keys to an immutable public ledger. If analyzing such implications is enjoyable to you, or you just want to learn more about NuID's vision for an open web of trust, don't hesitate to get in touch.