0

I'm new to everything related to authentication and have no knowledge about encryption algorithms. I was reading about JWT, but from what I gathered, it'd make more sense for my project to authenticate users using either one of these 2 strategies:

  1. Sign with the server's private key a publicly readable JSON, such as:
const token = {
  "user": "johndoe",
  "iat": 4342342352,
  "exp": 4352234322
}
  1. Or encrypt that JSON content and only allow the server to decrypt it
E.g.: 
// server sets token
encryptionLibrary.encrypt(token, "AES-256", "server's super password")
// then decrypts it when the token is sent with a HTTP request
encryptionLibrary.decrypt(token, "AES-256", "server's super password")

Question: Would checking the signature only be faster than decrypting the whole string or is it absolutely dependable on the implementation? (i.e., using a fast/slow library).

Related question: if I already know the content of an encrypted string (let's say I know it's the token variable above) and the encryption algorithm, will this make it possible to break my password? (thus, rendering option #2 unsafe)

Why not simply use JWT instead? Looks like too much bloat for my project, I just need a way of storing on the client's end a JSON with user, iat and exp information and letting the server prove it's legit. Signing or encrypting the whole payload should stop attackers from creating false tokens, I think

flen
  • 1,905
  • 1
  • 21
  • 44
  • If you want to encrypt the token how do you plan to hide the encryption key? If you plan to use something like Diffie-Hellman key exchange with asymetric encryption you better be careful to avoid the pitfalls of buggy implementation exposing information about the key. – slebetman May 05 '22 at 03:19
  • @slebetman I hope I'm not proposing something too silly, but the key would be stored in the server. The client would only have the encrypted text (in solution #2, that encrypts the payload instead of only signing it and leaving it unencrypted) – flen May 05 '22 at 03:36
  • @flen `client would only have the encrypted text`: what about a simple random string (no signature or encryption). Do you absolutely need data in that token? – Spomky-Labs May 12 '22 at 05:26
  • @Spomky-Labs my idea with the token was to avoid hitting the database, the user would be authenticated already with the token info. But you're right, I gave up on this idea and just set a random string instead (which is checked in the database to know to which user it belongs). The reason I gave up was the difficulty in revoking access without looking at the database anyway. About setting random strings, I got great feedback in this question: https://security.stackexchange.com/questions/261770/create-a-cryptographically-secure-random-string-for-auth-cookie-in-javascript/261773 – flen May 14 '22 at 05:28

0 Answers0