Nonces are used to prevent cross-site request forgery (CSRF) attack on certain operations in PKI. However, currently the nonces only works with client certificate authentication. Since PKI is now supporting authentication with username and password the nonce code need to be generalized to support all authentication methods.

CSRF attack exploits the fact that once a user authenticates into a website he will have an active session so a malicious operation on that website could be executed without additional authentication. Nonce fixes this by splitting an operation into 2 steps. For example, a certificate revocation is split into:

• Review: The user confirms the info of the certificate to be revoked.
• Execute: The user confirms the revocation.

In the first step the server generates a nonce then sends it to the client. In the second step the client sends the nonce to the server to be validated. This way the server knows that the operation is valid because a CSRF attack will not be able to forge 2 consecutive operations like above or the nonce itself.

Currently the nonce is generated as follows:

// Generate random number.
initialNonce = random.nextLong();
// Store nonce and the associated client certificate in a list.
// If the nonce collides with an exist one, generate a new one.
newNonce = nonces.addNonce(initialNonce, clientCertificate);

and validated as follows:

storedCertificate = nonces.getCertificate(clientNonce);
if (clientCertificate.equals(storedCertificate)) {
    // operation is valid
}

So the PKI server maintains a global list of valid nonces with their associated client certificates. The server also needs to avoid collision with nonces that already exist. If the user authenticates using a username and password the server will fail to retrieve the client certificate, so the entire operation will fail.

Now since the nonce is used to address the vulnerability of the session, it makes more sense to associate the nonce with the session, or more precisely with the operation being executed in that session:

nonce = random.nextLong();
session.setAttribute("cert-revoke-nonce", nonce);

The nonce can be validated as follows:

storedNonce = session.getAttribute("cert-revoke-nonce");
if (clientNonce.equals(storedNonce)) {
    // operation is valid
}

If we want to be even more precise, we can associate the nonce with the request, so a user can execute concurrent revocations in the same session, but that might not be necessary.

At least this way the nonces will work with any authentication methods, not just client certificate. Also, it's no longer necessary to do collision avoidance since the nonces are maintained separately.