Check for username availability before generating keys

[Lohikar]

When you attempt to connect to a room using a username that is already taken, the client will generate keys before it checks if the username is available, wasting CPU cycles and time for no good reason.

[GlasFrost]

either that or stick to your already generated key. the user changes the nick name and logs in with the key that we have already generated in the first try. is there a security concern in the way?

[Lohikar]

The primary concern about adding key-caching is security, yes.

I might add it as a 'hidden' feature for now, requiring a console command to enable.

[GlasFrost]

well, my thought is, you'll cache the key anyways for the chatroom encryption to work, or am i getting it wrong? maybe the key should decay after 2 minutes if caching an unused key is that much of an issue. just thinking

[Lohikar]

The issue is caching the key for long periods of time (local storage), as the local storage is not secured, any program on the system can read it fairly easily. Keeping keys in memory is less of an issue as the timespan they’re in memory is much less.

[GlasFrost]

that makes sense. but why putting them in local storage at all? i guess you can keep the key in memory in case of username-already-taken or is that impossible? of course a reload destroys the key then but that would be fine for me

[Lohikar]

Currently, keys are only kept as JavaScript variables, which are cleared on tab-close or tab-reload, so they'll persist through multiple sessions as long as the tab stays alive.

I don't think key-persistence is the way to go for this.