Release Notes — v1.0.4

Security Hardening Release

This release addresses multiple security vulnerabilities across the API server and test client.

Thread-safety: Replaced non-thread-safe List<string> and Dictionary<string, string> in GlobalVariables with ConcurrentDictionary to eliminate race conditions and potential server crashes under concurrent SignalR connections.
Memory exhaustion protection: Added session limits (max 10 connections per session, max 1000 active sessions) to prevent unbounded memory growth from malicious or leaked connections.
Buffer size reduction: Reduced SignalR MaximumReceiveMessageSize from 100 MB to 5 MB and transport/application buffers from 100 MB to 10 MB, mitigating denial-of-service via oversized messages.

Modern AES API: Replaced obsolete RijndaelManaged with Aes.Create().
Stronger key derivation: Increased PBKDF2 iterations from 300 to 600,000 and switched hash algorithm from SHA-1 to SHA-256.
Random salt: Each encryption now generates a unique 16-byte random salt (previously hardcoded).
Full password usage: Removed Substring(2, 10) truncation — the entire password is now used for key derivation.
MAC-then-decrypt: Decrypt() now verifies the HMAC using constant-time comparison before decryption, preventing padding oracle attacks.
Modern RNG: Replaced obsolete RNGCryptoServiceProvider with RandomNumberGenerator in key generation.

Removed unused package: Removed Microsoft.AspNet.SignalR.Core 2.4.3 (legacy .NET Framework package incompatible with .NET 8).
Framework update: Updated TestAPI target framework from net6.0-windows (end-of-life) to net8.0-windows.
Error logging: Replaced silent catch { // ignored } blocks in the SignalR hub with structured ILogger error logging.
Input validation: Added length limits on sessionId, code, and position parameters in the hub to reject malformed input.

Encryption format: The updated AESEncryption class produces a new payload format (includes salt field). Data encrypted with v1.0.3 cannot be decrypted by v1.0.4 and vice versa. Since encryption is used for live-share transit only, no data migration is needed — both peers must use the same version.
Message size limit: Clients sending messages larger than 5 MB will now be rejected. Adjust MaximumReceiveMessageSize in Program.cs if larger payloads are required.

The following were identified but not addressed in this release as they require architectural decisions:

Authentication/Authorization — No [Authorize] or auth middleware is configured. Consider adding API key or token-based authentication.
Rate limiting — No request throttling is in place. Consider ASP.NET Core's built-in rate limiting middleware.
CORS policy — No explicit CORS configuration. Add a policy appropriate for your deployment.