To catch anyone up... as part of my final project at Flatiron School I built a password manager. In my quest to find a better way to handle user data before encrypting it and decrypting it I discovered the need to store a key or something to encrypt the data before it was sent to the database and when it was pulled out of the database. This means that I either need to store a key in my program on the front end or figure out a way to keep it secure... ???
Ok... so not so much "questions" but more so much "how". I know my first step was using JWT to hold onto the authorized login to the application when a user logs in or creates a new account. This is done by the users initial login credentials being hashed and signed on the back end, verified on login on the front end, and then held in the browser session with a JWT in the sessionStorage.
Sooooo now I want to look into specific ways to validate a user... What do the big companies use that encrypt the data before it is stored on the backend without 2FA? Cookies? Digital Signatures? certifications? JWT? Some kind of combination?
What is a JWT
"JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA." (1)
In my project I created a JWT once a users authenticity was validated and stored it in sessionStorage. Once the user logged out, navigated away from the page, or refreshed the page... the token was lost and the user would need to re-authenticate who they were.
What does JWT look like?
They usually come in 3 parts... Header, Payload, and a Signature and typically look something like "xxxxx.yyyyy.zzzzz". The output of the token is 3 Base64-URL strings separated by dots that can be passed in HTML and HTTP environments. (3)
Digital Signatures?
JWT uses digital signatures to verify the data is trusted and has not been altered in transit. It does this with a 1-way hash of the message that is sent and verified via the public and private key pair. "The process creates a 'signature' that only the server's public key can decrypt. The client, using the server's public key, can then validate the sender as well as the integrity of message contents."(7)
What is the HMAC algorithm?
The Hash based Message Authentication Code (HMAC) is a 1-way MAC derived cryptographic hash function that is "resistant towards cryptanalysis attacks as it uses the Hashing concept twice." (8) "The first pass of the algorithm produces an internal hash derived from the message and the inner key. The second pass produces the final HMAC code derived from the inner hash result and the outer key." (9)
What is RSA and ECDSA?
RSA (Rivest–Shamir–Adleman) is one of the first public-key cryptosystems and is widely used for secure data transmission. The interesting thing about this cryptosystem is that the encryption key is public and different from the decryption key, which is secret.
ECDSA (Elliptic Curve Digital Signature Algorithm) is a cryptographic algorithm, used by Bitcoin to ensure that funds can only be spent by their rightful owners. The bit size of the public key needed for ECDSA is believed to be about twice the size of the security level, in bits. For example, at a security level of 80 bits (meaning an attacker requires a maximum of about {\displaystyle 2^{80}} 2^{80} operations to find the private key) the size of an ECDSA public key would be 160 bits. (2)
There is more than 1 type of token?
YUP! there is signed and encrypted tokens. "Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties." (1)
JWT allows for two types of signature algorithms, RS256 and HS256.
- RS256 (RSA Signature with SHA-256) is an asymmetric algorithm that uses a public/private key pair where the identity provider has the private key used to generate the signature, and the consumer of the JWT gets a public key to validate the signature.
- HS256 (HMAC with SHA-256) is a symmetric algorithm, with only one private key that is shared between the both parties. Since the same key is used both to generate the signature and to validate it, care must be taken to ensure that the key is not compromised.
Since the public key, as opposed to the private key, doesn’t need to be kept secured, most identity providers make it easily available for consumers to obtain and use (usually through a metadata URL).
If you will be developing the application consuming the JWTs, you can safely use HS256, because you will have control on who uses the secret keys. If, on the other hand, you don’t have control over the client, or you have no way of securing a secret key, RS256 will be a better fit, since the consumer only needs to know the public (shared) key. (6)
What About the Cookies??
Don't be fooled by the construction and use of a JWT. Cookies and tokens are not the same thing and JWT is not a Cookie, but it can be stored in Cookies.
References
- https://jwt.io/introduction/
- https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm
- https://searchsecurity.techtarget.com/definition/X509-certificate
- https://blog.codinghorror.com/protecting-your-cookies-httponly/
- https://web.dev/samesite-cookies-explained
- https://community.auth0.com/t/jwt-signing-algorithms-rs256-vs-hs256/7720
- https://www.instantssl.com/digital-signature
- https://www.geeksforgeeks.org/hmac-algorithm-in-computer-network/
- https://en.wikipedia.org/wiki/HMAC
Top comments (0)