Is it possible to calculate an encryption key when both the plain text and ciphertext are known?



  • I have implemented an authentication system which works like this:

    1. Upon successful login, the server takes the username of client and encrypts it with AES-256.

    2. This ciphertext is stored in the client's browser and when the client wants to do something which requires login, this ciphertext is sent to the server. The server decrypts the ciphertext and obtains the username of the client who is logged in.

    An attacker cannot breach a client's account because he/she doesn't know the encryption key, so it doesn't matter if the attacker knows the username. However, I'm worried if client's browser is exposed, the attacker will access both the ciphertext and plain text (username). Does this allow the attacker to "calculate" the encryption key given that both the ciphertext and plaintext are known? Because that key is used for all clients, so if it's exposed the entire system is ruined.


  • QA Engineer

    In answer to your main question, AES256 is secure as far as we know into the foreseeable future. However your authentication scheme has several drawbacks.

    First, if any request where the token is sent is compromised, or if a the user installs a malicious addon that can grab the encrypted user name from their browser, that account is forever unusable. You are essentially creating a token to use for authentication that cannot ever be changed and that is a 1:1 relationship with the user name. The only way to deny access if it is compromised is to shut down the account and force the user to create a new account with a different username.

    A much better way would be to generate a random token when the user authenticates and store that in the database, or generate a random value and encrypt that as the token. Then if the account is compromised or if the user wishes to 'log out', you can remove that token and generate a new one.

    If your encryption key is ever compromised or if it is ever cracked somehow, the attacker can do anything as any user in your system. With a random token based approach, they would have to know the random part used to generate the token for each user. The attacker would have to have access to your database and your encryption key.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2