HI Welcom to yet another ramble on security
SO one of the main cons of tokens is the case where an end user has their tokens momentaraly stolen by a malicios site. If we wanted to detect and mitigate this one idea is to role the token upon every request. We would need to caluclate the propagation delay of a user.
But theoretical if a user maintains a singel endpoint.
Or posibly durable object seasion.
Then when the user comunicates there is a token passed with each request.
this token contains an incrementing id and is encoded using a jwt algorithm. it should contain the user id, the most basic information. and the request number. an unsigned int. Each request is authenticated by a seasion id.
When a seasion is created it has a session_id, max_time, start_time, user_id, req_num=0, And there is anencoded jwt saved in a cookie with this information. A new id is made as wellas the expiry time in ms.
et = encryptin time dt = decryption time nt = network time
We must perform the decryption each request anyway.
We can cache this for improved performance but so can a user.
By modifying the harder each request we can prevent an third party from using the seasion. as they will fuck it up and cause a 404 and loging
by maintaining one active connection per season we help mitigate season theaft as and stolen cookie when used will be out of sequence and return a 404 at auth the normal response should suggest you log in and view you project tree for all availible resorces
However, if a user maintains a single endpoint or possibly a durable object session, then a token can be passed with each request. The token should contain an incrementing ID, encoded using a JWT algorithm, along with the user ID, and the request number as an unsigned integer. Each request is authenticated by a session ID.
When a session is created, it has a session ID, max time, start time, user ID, req_num=0. An encoded JWT is saved in a cookie with this information, and a new ID is made, along with the expiry time in milliseconds.
We must perform decryption for each request anyway, which can be cached for improved performance, but so can a user. By modifying the header for each request, we can prevent a third party from using the session. If they do, they will get a 404 and be logged. By maintaining one active connection per session, we help mitigate session theft. If a stolen cookie is used, it will be out of sequence and return a 404 at authentication. The normal response should suggest logging in to view the project tree for all available resources.```
Realy normaly we need to Recieve validate decrypt increment encrypt send.
By not rotating the number we could throreticaly save the secon encryption time If our backend seasion is stable we could also save the decrypted data and bring the token size down to a hash of the id and request number. this has to be cryptograpicaly random to not leak the request number. THis number is only incremented for get requests. THis allows a site to request multiple backend apis in unison with the same token. This should minimixe the requeitments on the decryp and encryp times
Since the hash does not need to be decoded, it can be compared to the session value. Then, the number is taken from the durable object. Some key takeaways are:
- The cost is greater than an ideal JWT by one DB transaction.
- The DB transaction would be required for invalidation of tokens anyway.
- If that's all we want, then we can have ideal speed by performing no encryption.
- The encryption can happen in unison with the DB validation theoretically.
- Receive JWT (ID, req), decrypt, increment, encrypt while in parallel checking ID in the DB is not expired or invalid.
- Then return the new token.
- The cost analysis of this may vary depending on how fine the billing system is.
- If async waiting time is not counted, then there is increased cost.
- Otherwise, if it's based on request time, there is no downside.```
theoreticaly i can think of 2 systems
1: recieve -> db lookup token -> if not exist fail else if exist -> return data row and increment. encrypt -> send to client, and send to db non bloking. buisnes logic response.
2: recieve response. decrypt -> validate and update from db -> encrypt -> response/ buisenes logic
Approach 1:
The client sends a request with a token.
The server performs a database lookup for the token.
If the token does not exist, the server returns a failure response.
If the token exists, the server retrieves the session data (including the current request number), increments the request number, and updates the session data in the database (using a non-blocking operation).
The server encrypts the new session data (including the updated request number) and sends it to the client.
The server performs any necessary business logic and returns a response.
This approach involves two database operations - a lookup and an update - and may take longer than approach 2. However, it may be preferred if minimizing database writes is a priority.
Approach 2:
The client sends a request with a token.
The server decrypts the token and retrieves the session data from the database.
The server performs any necessary business logic.
The server updates the session data in the database (including the incremented request number).
The server encrypts the new session data and sends it to the client.
The server returns a response.
v2 is one less db request but posibaly a few ms logger for client.
Using a completely random number as a token without any data encoded in it can be a valid approach for certain use cases.
The advantage of using a completely random number is that it is harder for an attacker to guess or generate valid tokens, as the tokens are not related to any user information. This can make the system more secure against token-based attacks.
However, the disadvantage is that it can be harder to track or revoke specific tokens if needed, as the tokens do not contain any identifying information. Additionally, if tokens are used for session management, it may be harder to correlate a token with a specific user if there is no identifying information in the token.
Overall, using a completely random number as a token can be a good approach for certain use cases, but it depends on the specific requirements and security needs of the system.
HS256 is currently considered secure and is widely used in practice. It provides 128 bits of security which is sufficient for most applications.
HS512 provides a higher level of security with 256 bits of security but also has a higher computational cost compared to HS256. Whether HS512 is warranted in the next 10 years depends on the expected level of security required in the future and the rate at which computing power advances.