What’s the issue?
SQL Server logins (those using SQL authentication rather than Windows authentication) are protected by a password stored as a hash in the master database.This finding flags SQL logins whose passwords have been verified as trivially weak, including passwords that are blank, the same as the login name, or the literal word “password”. These are among the first values an attacker tries during a brute force or credential stuffing attack.
The condition is most often found on logins created during initial setup, on logins associated with vendor applications that ship with default credentials, or on developer and test logins that were created with placeholder passwords and never updated.
Why is this a problem?
Weak passwords on SQL logins are one of the most direct paths to a SQL Server compromise. Any attacker who can reach the instance over the network and knows or guesses the login name can authenticate immediately, with no exploit required. Tools that perform automated brute force attacks against SQL Server start with exactly the kinds of values flagged here, so an instance with even one weak login is effectively unauthenticated for that account.Once authenticated, the attacker has whatever permissions the login holds. If the weak login is a member of sysadmin, has CONTROL SERVER, or has been granted broad permissions for application convenience, the result is full instance compromise, including the ability to read and exfiltrate data, modify or destroy databases, and pivot to other systems through linked servers and the operating system.
Even when the weak login has limited permissions, it provides a foothold for further attack. SQL Server has many documented privilege escalation paths, particularly when combined with other configuration weaknesses such as weak service account permissions or older patch levels, so any authenticated access can become a stepping stone to broader compromise.
Weak passwords are also a serious compliance issue. Most regulatory frameworks (PCI DSS, HIPAA, SOX, ISO 27001) require enforced password complexity, minimum lengths, and regular rotation, and a weak SQL login violates these requirements directly.
What should you do about this?
For each affected login, change the password immediately to a strong value using ALTER LOGIN [LoginName] WITH PASSWORD = [strong password]. Coordinate the change with any application owners or scheduled jobs that use the login so connections are updated at the same time, since the password change will break any process still using the old value.Where possible, retire SQL logins entirely in favor of Windows authentication. Windows and Active Directory authentication centralizes password policy, supports multi factor authentication, integrates with identity governance tools, and eliminates the password storage and rotation concerns that come with SQL logins. Configure the instance for Windows Authentication mode rather than Mixed Mode if no SQL logins are required.
For SQL logins that must remain (typically vendor applications that do not support Windows authentication), document each one with its owner, purpose, and the rationale for using SQL authentication. Use long, randomly generated passwords stored in a secrets management system rather than passwords chosen by a person, and rotate them on a defined schedule.