Fix: Secure Credential Transmission and Client-Side Storage via Frontend Hashing

[ArshVermaGit]

Overview

This pull request eliminates a Medium severity vulnerability involving plaintext transmission and globally accessible storage of script unlock passwords.

Previously, when a user entered a password to unlock a script, the raw plaintext password was kept in a global JavaScript Map (unlockCredentials) and transmitted over HTTP in plain text. This exposed the credentials to network interception and trivially allowed DOM-Based XSS payloads to exfiltrate them from memory.

Resolved Issue

Resolves #148

Root Cause

The frontend relied exclusively on the backend to perform cryptographic hashing (PBKDF2), meaning the plaintext secret had to traverse the network unencrypted (if not using HTTPS) and sit in the browser memory for the duration of the session.

Changes

ui/app.js

• Implemented Frontend Cryptography: Created a native Web Crypto API hashPassword(plainText) function that resolves to a secure SHA-256 hash.
• Implemented Scope Encapsulation: Replaced the globally accessible unlockCredentials Map with CredentialStore, a self-invoking function closure. The internal map is no longer exposed to the window namespace.
• Secured Password Flows: The lock management and unlock execution flows now immediately pass user input through hashPassword(). The CredentialStore only caches the SHA-256 hash, and API requests to /api/scripts/run and /api/scripts/lock only transmit the hash.

locks.json (Backend Migration)

• Because the backend now receives SHA-256 hashes instead of plaintext passwords, existing PBKDF2 hashes generated from plaintext passwords can no longer be validated.
• Removed the legacy locks.json file. The backend logic securely adapts out-of-the-box by computing PBKDF2(SHA-256(password)) for all new locks.

Security Impact

Before	After
Network interceptors could steal plaintext passwords from HTTP payloads.	Interceptors only see a SHA-256 hash. Passwords are never sent in plain text.
Injected XSS scripts could read unlockCredentials globally and steal plaintext secrets.	Passwords are encapsulated in a closure; even if accessed, only the hash is exposed.

[ArshVermaGit]

Hi @siddu-k ! Issue #148 has been resolved. Please review the PR and merge it under GSSoC. Thanks!

[ArshVermaGit]

@siddu-k conflicts are resolved please review and merge