########################################################################################## LOC-23: Shorter Session IDs ########################################################################################## Issue Type: Improvement ----------------------------------------------------------------------------------------- Issue Information ==================== Priority: Major Status: Closed Resolution: Done (2018-05-19 11:44:16) Project: LocalChat (LOC) Reported By: btasker Assigned To: btasker Components: - Server Targeted for fix in version: - V0.0.2 Time Estimate: 0 minutes Time Logged: 0 minutes ----------------------------------------------------------------------------------------- Issue Description ================== Currently, when a session ID is generated it's 1024 bits/128 octets. This is then prefixed with the room name, with a hyphen as a delimiter: -- BEGIN SNIPPET -- [room name]-[session ID] -- END SNIPPET -- So, even with a one character room name, that's 130 bytes that must be sent with every request. Those 130 bytes must then be compared to the 130 bytes stored in the database for that user. The session key currently consists of uppercase ASCII chars and numbers, so the keyspace is 128^36. The length was chosen arbitarily whilst implementing, and the character set is the same as that used for generating E2E encryption passphrases (makes more sense there as it's easier to copy across). However, a user never needs to manually enter a session key, so lowercase chars (and even some special characters) could be mixed in. This would allow us to increase the keyspace despite shortening the key length (and lowering payload size as a result). If we simply add lowercase chars, the keyspace for different lengths would be - 32^62 = 2.0859248397665138e+93 - 48^62 = 1.7256658998786433e+104 - 56^62 = 2.4415053168670305e+108 - 64^62 = 9.619630419041621e+111 So despite shortening the key length by 75% (if we go with 32 chars) the potential keyspace is still increased considerably. Session keys are not used for encryption in any way, and only last for as long as a user is in a room. That does need to be balanced against the risk of an attacker trying to factor a key to steal a user's session though, so we should probably go with one of the slightly longer options. 48 octets seems like a good balance ----------------------------------------------------------------------------------------- Activity ========== ----------------------------------------------------------------------------------------- 2018-05-19 11:44:16 ----------------------------------------------------------------------------------------- btasker changed status from 'Open' to 'Resolved' ----------------------------------------------------------------------------------------- 2018-05-19 11:44:16 ----------------------------------------------------------------------------------------- btasker added 'Done' to resolution ----------------------------------------------------------------------------------------- 2018-05-19 11:44:19 ----------------------------------------------------------------------------------------- btasker changed status from 'Resolved' to 'Closed' ----------------------------------------------------------------------------------------- 2018-05-19 11:44:37 git ----------------------------------------------------------------------------------------- -- BEGIN QUOTE -- Repo: LocalChat Host:Rimmer commit 54ddfae96f25cde34e4ffffc297f5ab79cf61952 Author: B Tasker