########################################################################################## LOC-2: Design Authentication Mechanism ########################################################################################## Issue Type: Task ----------------------------------------------------------------------------------------- Issue Information ==================== Priority: Major Status: Closed Resolution: Done (2018-05-13 12:56:43) Project: LocalChat (LOC) Reported By: btasker Assigned To: btasker Components: - Authentication Targeted for fix in version: - V0.0.2 Time Estimate: 0 minutes Time Logged: 0 minutes ----------------------------------------------------------------------------------------- Issue Description ================== Need to start thinking more seriously about how best to handle authentication (any by extension, encryption). My original plan had been that the "room password" would never be shared with the server and instead would be used as a shared encryption key by the clients to encrypt message payloads. Despite that, for some reason, I added a passhash field to the rooms table. We also need some level of user auth when they join a room. Knowing the room password shouldn't be sufficient to let them retrieve messages (as they'd then be able to decrypt them). One option might be to merge the two into one, of the format roompass:userpass and just have the client split them and use each appropriately. In any case, needs some thoughts laid down on the best approach so that decisions are recorded. ----------------------------------------------------------------------------------------- Issue Relations ================ - blocks LOC-10: Clients can spoof sender value ----------------------------------------------------------------------------------------- Activity ========== ----------------------------------------------------------------------------------------- 2018-05-13 09:18:22 btasker ----------------------------------------------------------------------------------------- As of LOC-4 the room password is now used as a shared key for the E2E encryption. So we definitely shouldn't have that sent to the server when creating a room (otherwise it'll be sat on the information - even if hashed - needed to decrypt user's messages). So passhash should probably come out of both the rooms table and the relevant API calls. We do still need to design and build the user authentication though. Currently, if you know the room owner's username and the room password you can sign in as them. There's a related tangent here though too. LOC-5 addressed a scenario where users can pretend to be the SYSTEM user and can push what appear (to other users) to be system messages. The changes in that issue stop users from signing in as SYSTEM and pushes warnings if they try to do any of the setup steps required to achieve that. However, the sending user's name is currently stored (a second time) within the encrypted message payload - it's that value which is used by the client. So it's still possible for a malicious user to send messages that'll appear to be from SYSTEM by making a call that uses their username in the server visible field but uses SYSTEM in the encrypted version. The reason I haven't fixed that yet is because we first need to work out the best means of authenticating the sending user's requests. Ideally the message table shouldn't contain a plaintext list of usernames as it becomes too easy to identify patterns - which user sends messages most frequently, etc. Fixing that has a massive overlap with the auth mechanism. So, there are a few challenges to be overcome here: - Need to generate (preferably client side) a password for new users and store a hash for them on the server - A joinRoom call needs to authenticate their request - Assuming authentication succeeds, need to set something so that other requests can also be validated - Ideally, that _something_ can then be used to help close the remaining sending as SYSTEM hole, whilst allowing us to remove cleartext user names from the messages table ----------------------------------------------------------------------------------------- 2018-05-13 09:32:14 git ----------------------------------------------------------------------------------------- -- BEGIN QUOTE -- Repo: LocalChat Host:Rimmer commit 5211d7f7de1f279082f65f29cf935d74501e1b9d Author: B Tasker