This module by default uses AES 256 bit CTR mode for encryption/decryption.

On a quick note,if one wants to use some other cryptographic methods, one can extend Cryptor class and implement the methods their, and give the instances of that class to all cryptographic class method arguments. For more information check API documentation.

After a google search one can find many question-answers ralted to how incorrect use of AES CTR mode can lead to faulty encryptions and possibilities of breaking the encryption.

One of main possible ways that incorrect use can occur is to use same key-init value pair used in CTR mode encryption again and again

If we consider step-by-step use of this module, we can see the following key-init value combinations :

First user send un-encrypted request to Authentication Service to get Ticket Granting Ticket. The response that is sent is encrypted using user-specific key, but same init-value for all requests. The TGT send with the response in encrypted with a key and init value specific to the Ticket Granting Service, but this can be sent inside the encrypted response, which can then use different keys for different users.

The requests done to TGS are encrypted by a random key sent inside the response by AS, but with same init value for all,defined in constants.js as TGT_INIT_VAL.

The Tickets that are generated by TGS are encrypted with a server specific key and init value that is randomly generated when setting up server structure, but all tickets are encrypted by the same pair, which can introduce vulnerabilities in the whole chain. One way to overcome this is to periodically change the server keys and init values , and deny all tickets given before that access.

Then all the request that are made to servers are encrypted using random keys and init values that are sent along with ticket, as well as stored inside the ticket. For a particular user that obtains the ticket, the same key-init value pair is used until the ticket expires, but one can make the user take a new ticket for every use, so that every request can be encrypted by a different key-init value pair.

Note that this also suffers from time between access granting and actual use difference. If a user logs in before getting removed from authorized users, then, if the TGT has a longer lifetime, the user will still be able to access the servers, until the TGT expires and user is forced to again get a TGT, when, as user is removed from authorized user, the request will be denied.

This module may also suffer from other vulnerabilities and stability issues. A thorough testing of security and other aspects is strongly advised before use.

Note that developer neither gives any guarantee nor takes any responsibility for the security of this module.