Thick-client tax software caches credentials on clerk workstations, and the backend database grants a single service account rights far beyond its job. What is the best remediation focus?
Select an answer to reveal the explanation.
Short Explanation
Cached passwords on the desktop plus a god-mode DB account is two open windows on the same house. Fix the client stash, harden the server, and shrink that database login to what the job actually needs.
Full Explanation
Thick-client tax software that caches credentials on clerk workstations, paired with a backend database service account holding far more rights than its job requires, creates a dual weakness: stolen endpoints yield reusable secrets, and a compromised app tier inherits excessive database power. The best remediation focus eliminates local credential caching on clients (prompt each session, use OS credential guards/SSO tokens with short life, avoid embedded passwords), hardens servers hosting the tax app, and constrains database accounts to least privilege for the specific procedures the application needs. Ignoring the thick client because “only web apps have credential risks” misunderstands endpoint secret storage as a universal threat. Widening the database account to sysadmin enlarges blast radius under the false flag of outage convenience. Moving the database to an anonymous guest login removes authentication entirely. Exam caveat: least privilege and secure credential handling apply equally to fat clients and service accounts; privilege creep for “break-glass everyday” is a recurring distractor. Operational check: scan clerk disks and configs for cached tax-app secrets, disable caching features, rotate exposed credentials, rewrite the DB login to minimal grants, remove sysadmin from app accounts, and penetration-test a stolen-laptop scenario to confirm cached creds no longer unlock production data.