JWT Authentication server using email, password, captcha and Google Authenticator

Main Features:

• Password strengthening using scrypt RFC7914
• Password authentication using SRP-6a RFC2945 RFC5054
• One time tokens using TOTP RFC4226 RFC6238
• Human detection using reCAPTCHA
• Authorized using JWT RFC7519

yarn

Generate a keypair:

openssl ecparam -genkey -name secp521r1 -noout -out ec512.prv.pem
openssl ec -in ec512.prv.pem -pubout > ec512.pub.pem

Run tests & lint:

yarn test & yarn lint

Start server:

yarn start

You can find a client-side library here: authentication-client

The result taken in raw binary form. 256 bit random salt.

4096-bit Group parameters (RFC5054 §A.5). 256 bit random salts and nonces.

Note: Captcha prevents this from automated detecting user existence

1. User: generates random 32 byte kdfSalt
2. User: generates random 32 byte srpSalt
3. User: key = scrypt(password, kdfSalt)
4. User: verifier = SRP6A_verifier(email, key, srpSalt)
5. User calls /api/signup with:
   • email
   • kdfSalt
   • srpSalt
   • verifier
   • captcha
6. Server validates recaptcha
7. Server generates totpSecret
8. Server creates new user with submitted data
9. Server returns totpSecret

1. User calls /api/login-data with:
   • email
2. Server responds with:
   • kdfSalt
   • srpSalt
   • serverPublicKey
   • encrypted and authenticated:
     • serverPrivateKey
3. User calls /api/login with:
   • clientProof
   • clientPublicKey
   • email
   • timeBasedOneTimeToken
   • encrypted and authenticated:
     • serverPrivateKey
4. Server verifies all the data and checks:
   • the client proof
   • integrity of encrypted part
   • 2FA token
5. Server issues the JSON Web Token
6. Server returns:
   • token
   • serverProof
7. Client verifies server proof

• Because they often have low entropy (like the codes on a suitcase, you can try all options in a few days).

• Because people use the same password in many places, so even if your site is not important—the same password may access the users bank account.

CA's are unreliable, TLS is too complex/buggy.

• http://heartbleed.com/
• https://en.wikipedia.org/wiki/Cloudbleed
• https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs

Does not protect against password brute forcing. An attacker who has the salt and hash can rapidly try combinations.

It's a lot better, but an attacker that has the salt and hash can still try passwords without being detected. Just much more slowly.

SRP protects against eavesdroppers, nothing send over the wire will help an attacker.

But now the server stores something that is roughly similar to a salted hash: if an attacker obtains the user database, (s)he can quickly do an brute force.

By using both we make it impossible to attack the password when the TLS leaks and very hard when the user database is leaked.

SMS is not secure

It is in the clients interest to protect itself.