To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

PVS-Studio clashes with hardcoded passw…

PVS-Studio clashes with hardcoded passwords!

Mar 02 2021

PVS-Studio is a static analyzer that allows to find many problems hidden in the source code. Among them there are also errors related to application security. For example, the analyzer has recently learned to identify the presence of confidential data such as passwords in the code. The OWASP Top Ten list includes this potential vulnerability. It is much more dangerous than it may seem at first glance. What makes it so dangerous? How can a static analyzer save us from it? That's what you'll know about (and more) in this article!


We are continuously developing PVS-Studio as a SAST solution. We plan to improve the analyzer skills in finding even more security-related errors in C, C++, C#, and Java code. You can read up on these plans in detail (and find more information) in PVS-Studio Roadmap 2021.

Sensitive data stored in your code

One of the options for SAST developing support is the addition of some new diagnostic rules. They implement code compliance checks for various standards. A check for sensitive data in source code is among the latest innovations in the C# analyzer. The storage of such data in code is contrary to #2.10.4 of the OWASP Application Security Verification Standard (ASVS):

Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.

The OWASP Top Ten list includes risks related to insecure storage of sensitive data in code. The Common Weakness Enumeration (CWE) also contains 2 items related to this question: CWE-798 and CWE-259. Even so, one might wonder – why is it dangerous?

For open source projects, the answer is obvious. Everyone can view and use a password or some other data in code. That's an easy task for an attacker. They just delve into the repository to get some data.

The situation is slightly better if the application is available only in a compiled form. This can even create the illusion of security. After all, the source code is seemingly unavailable, which means that the data in it is also unavailable. Alas, that's not necessarily the case.

In practice, it's not uncommon for a system to contain hardcoded data that can be used to obtain various rights. As a rule, users can't even change this data. Attackers may use different methods to obtain them. In some cases, the system interface can generally contain logins, passwords, etc. In other cases, you'll need to examine various files, code decompilation, brute force, and so on. Anyway, malicious hackers are good at finding ways to uncover hardcoded secrets.

Quite often, the following problem comes up: an attacker, having received logins and/or passwords stored in the system sources, will be able to use them to connect to other systems of this type. For example, they can install the system locally. After scanning and obtaining users' logins and passwords for this local version, the attacker will be able to connect to other versions using the same data.

In addition, the fact that all programmers have access to the source code data poses a danger. At the same time, a user who has installed a particular system for their own needs won't be happy to know that a software company can get full control over the used system at any time. Therefore, the company will get various secret data of the users themselves, etc. The vulnerabilities found in the Common Vulnerabilities and Exposures (CVE) list show that such errors are found sooner or later. And at the same time, they are surely put on display.

As mentioned earlier, vulnerabilities related to hardcoded confidential data are pretty common. There are many examples among CVEs. CVE-2012-5862 is one of them. This record describes the system, containing the login.php file. There is the following code in this file:

$password = mysql_escape_string($_POST['password']);

if (crypt($password,salt)=='satIZufhIrUfk'){
  $sql_pthr_ = "SELECT user,password FROM account WHERE livello = 0";

if ($password=='astridservice' and $stilecustumization=='astrid'){ // <=

if (crypt($password,salt)=='saF8bay.tvfOk'){
  $sql_insert="INSERT INTO account(user,password,livello,nome) VALUES  
               ('sinapsi','sinapsi','0','Amministratore Sinapsi')";

In this code, there's a place where the variable containing the password, passed by the user, is directly compared with a string literal. Obviously, an attacker will have no trouble using this information. It will help the intruder to perform various operations unavailable to an ordinary user.

The PVS-Studio C# analyzer finds the storage of sensitive data using the V5601 diagnostic rule. Take a look at the C# code sample that resembles the example above:

string password = request.GetPostValue("password");
if (password == "astridservice" && stilecustomization == "astrid") 

After reviewing this code, PVS-Studio will emit the following warning:

V5601 Suspicious string literal could be a password: 'astridservice'. Storing credentials inside source code can lead to security issues.

Thus, the static analyzer will help you to find a similar error in the code at a moment's notice. Then, you just need to resolve the error. Therefore, the security level of your project will increase.

Note. It is worth mentioning that V5601 belongs to the OWASP diagnostics group. This group will appear in PVS-Studio with the release of 7.12 version. By default, OWASP rules will be disabled. However, you can easily change this, for example, with the help of the Visual Studio plugin or Rider. You can also directly edit the settings file.

This example is just one of many. Hardcoded data can lead to all sorts of problems. During my research, I found many other CVE records, related to highly protected confidential data. Here are the links to some of them:

  • CVE-2004-1920 – router with a "super" username and password;
  • CVE-2004-2556 – access point with a "super" username (again) and not a super password "5777364";
  • CVE-2004-2557 – which is the result of the CVE-2004-2556 "fix"(at least the login is no longer "super");
  • CVE-2012-1288 – hardcoded credentials for an administrative account;
  • CVE-2012-2949 – a hardcoded password for an Android app
  • and so on.

One more reason to run the analysis regularly


The conventional wisdom is that a static analyzer may be used once every few months, just before the release (or even once a year). That's a rather strange choice. Fixing errors that have been accumulated over a lot of time is much more difficult than fixing the code that you just wrote before committing. All the more, thanks to incremental analysis, the check will run much faster.

In many cases, the analysis of commits and pull requests would be a convenient option. This will increase the reliability of an application under development even more. After all, the code containing errors will not get into the main branch of the repository. This will help the developer who suddenly forgot to run the analysis. To find out more about the configuration of the pull requests check, read the documentation (see section Deploying the analyzer in cloud Continuous Integration services).

A new opportunity to search for sensitive data in code again confirms regular analysis usage. It's handy both on programmers' computers and within CI. Even if a programmer puts some passwords in the source code, the analyzer will warn them about it. If necessary, a developer can read the V5601 diagnostic documentation to see where the danger lies.

If you rarely run the analysis, hardcoded data turns out to be stored in the source code for a long time. It's pretty bad for an open-source project. By the time the analyzer finds a problem, data will no longer be confidential. However, other projects are not secured too. What if a user gets, let's say, a beta version of the app? You may receive such version between releases. If you don't check source codes regularly, a static analyzer won't check code in such a version. All the data hidden in the source code happens to be publicly available.


PVS-Studio is constantly evolving. We add new diagnostic rules, refine some existing mechanisms along with some new development opportunities. It's worth noting that, in a large part, an ongoing dialogue with users makes the analyzer better. The V5601 diagnostic rule is just one of the elements which help the analyzer to improve code security.

How about you try PVS-Studio in your projects? You can get it for free. Just follow the link and fill out a simple form. Well, that is that. Thank you for your attention. See you soon :).

Popular related articles
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →