[Security] Windows: encryption key written to plaintext file with no access controls

[vlad-bitc]

Description

On Windows, the .encryption_key fallback path in credential_store.rs writes the AES-256-GCM encryption key as a plaintext file with no access controls applied.

On Unix, the key file is explicitly created with mode 0o600 (user-read/write only):

#[cfg(unix)]
{
    use std::os::unix::fs::OpenOptionsExt;
    let mut options = std::fs::OpenOptions::new();
    options.write(true).create(true).truncate(true).mode(0o600);
    ...
}
#[cfg(not(unix))]
{
    let _ = std::fs::write(&key_file, &b64_key);  // no permission hardening
}

On Windows, std::fs::write is used with no equivalent ACL restrictions, meaning the key file inherits default directory permissions and is readable by other users or processes on the same machine.

This key is used to decrypt credentials.<b64-email>.enc, which contains the OAuth refresh token for Google Workspace. An attacker with local read access can decrypt the token file and obtain long-lived Google account access.

Environment

• gws version: 0.4.4
• OS: Windows

Expected Behavior

The .encryption_key file on Windows should have restrictive ACLs equivalent to Unix 0o600 — readable only by the owning user. This can be implemented using the windows-acl or winapi crates, or via std::os::windows::fs extensions.

Workaround

On Windows, use Windows Credential Manager directly (the primary keyring path) and avoid scenarios where it falls back to the key file. There is currently no way to force this from the CLI.