1
prodigy214
130d

So i wanna try explain the concept of JWT to a 5(+55) year old, and also to myself who is noob at web stuff. please tell me if this is a correct analogy, because i am myself confuse regarding how its secure?

So A wants B, a blind jeweller, to keep his super valuable notebook page with bank passwords safe. B says "give me your sheet and 5 nickels". (Assume that every nickel is always 1gm, made up of pure iron . Assume these statements to be true and world-known )

B takes A's nickels, melts them, adds 20gm more iron, adds 25gm copper, adds 25gm aluminum and then adds 25gm carbon dioxide and makes a mixture that is impossible to revert , but will automatically disintegrate after 24 hours due to CO2 (again, pure true statement, but this formula is only known to B) .

He makes 2 exact copies of keys from the 100 gm mixture, gives one to A and says
("Anyone can either give me 5 nickels of same name, markings, and year and i will give them back this secret sheet. or they give me the same key fo next 24 hours,and i will still give them back the sheets. after 24 hours, this key will also not work. I will even keep this on public display that i make keys using the materials I just showed, and then also no one would be able to create he exact same replica because they don't know how much percentage of each material went into the mixture"

So is this true? I have heard my friend boldly claim that they don't store user passwords as plaintext or even encoded text but rather doing this :
user password + company's private key --->[public domain encryption algorithm] = irreversible public key which is saved against user profile as "password"

public key + other info + time bound expiring logic ---->[public domain JWT encrypted token maker algorithm] = reversible JWTToken which is sent back to user

if user sends back token, then
token --> [JWT decoder] = public key + other info

if public key matches the stored public key , then user is a real user and should be given data

if user sends back the original password, then
user password + company's private key --->[public domain encryption algorithm] = irreversible public key .
again if public key matches the stored public key, then user will again receive access?

So this means all the time we are transmitting a lightly jumbled up version of public key, which is itself a hard, almost irreversible jumbled up version of our passwords that can only be unjumbled via a private key (or jewellers mixture ratios) that companies hold dearly ?

Comments
  • 0
    So what does "JWT" stand for?
  • 2
    You mixed a lot of terminologies here, especially Nickels. Let me explain what JWT is for

    JWT is just an auth token with some user info encoded into it. If the info is to be protected, you can encrypt it using a symmetric algorithm where the sender and receiver both have access to the key

    PKI is for a different purpose. It is an asymmetric encryption mechanism where the sender encrypts using public key and the (intended) receiver can only decrypt using the private key. On the other hand, if sender encrypts data using the private key and the receiver could decrypt using the public key, it only ensures the sender is authentic and is assumed to be digitally "signed". It is not meant to protect sensitive data from being eavesdropped
  • 2
    JWT is literally just a Json Web Token.

    Usually when you log-in to a service, you receive a token that confirms that you are who you say you are and the server trusts you. This is then sent back in the Authorization header of all your requests.

    One common way is that the server generates a random token for you, stores it in the database and then gives it back to you. Then every time you make a request it gets your token, looks for it in the database, if it's valid it looks what user it belongs to and then processes your request as that user

    Now with JWT there's no database storage, because the token already carries all the data in the JSON format. You log-in, you get the token and then every time you send it back the server can just read it and know who you are.

    Now if that was all, then anyone could just make a b64 encoded json token and pretend to be anyone else, so there's one more crucial step which is signing the token as well (read on what digital signature is)
  • 2
    I got lost 2 lines into your analogy....

    JWT - is like your plane ticket. It has your name, last name in it, it claims the class and seat to seat you in. It might contain more info useful for a flight attendant, giving you more or less privileges.

    Just like plane tickets have mechanisms preventing them from forgery, jwt tokens have them too [signature].
  • 0
    Your analogy feels more complicated than the real deal.

    JWT consists of Header, Payload and a Signature. The signature is created by Priv/Pub Encryption via Certificate or a shared Password.

    The Certificate Version is secure and has the ability that the client can verify the signature via public Key, but noone without the private key can create the signature.

    If you want you can also do any shinanigans to the payload e.g. encrypt it whatever.
Add Comment