Cryptography

Poor Credential Management

Introduction

As discussed in the previous article, use of credentials is one of the most common approaches used in applications and this is the de facto method that users identify themselves on an application or system. When users attempt to login, applications verify the credentials by comparing them to credentials that are already stored in a database. When designing such applications with the user of user credentials, security mistakes do happen if proper care is not taken. 

While users must ensure that they use strong passwords, it is also important for application architects and developers to use safe approaches when dealing with user credentials. This article outlines some of the poor credential management mistakes that are commonly seen in applications.

Learn Applied Cryptography

Build your applied cryptography and cryptanalysis skills with 13 courses covering hashing, PKI, SSL/TLS, full disk encryption and more.

Start Learning

Hardcoded credentials

Hardcoded credentials is a common problem in applications. Applications often require communication with other systems such as databases. These systems often require credentials to be presented. When applications are developed with hard coded credentials, any party with access to source code will be able to view the credentials thus posing a serious security risk. 

The following excerpt shows an example, where a Java based application uses database credentials within the source code in clear text.

public boolean openConnection() {

boolean flag = false;

try {

//Load MySQL Driver

Class.forName("com.mysql.jdbc.Driver");

connection = DriverManager.getConnection

("jdbc:mysql://localhost:3306/users?serverTimezone=UTC","root","toor");

flag = true;

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

} catch (SQLException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

return flag;

}

 

While this is insecure, it is unfortunately a common practice followed in many applications. When someone gains access to the source code the complete database can be compromised.

Clear text storage on disk

Another danger with credentials is the way they are stored on disk, for example in a database. There have been several cases, where sensitive data such as user credentials and credit card details were stored in clear text. When sensitive data is stored in clear text, it leads to severe damage to organizations especially when data breaches happen. This is a very well discussed problem and fortunately most organizations these days are using better approaches such as storing passwords using strong hashing algorithms. 

Use of weak cryptography

Developers, who lack security education often misunderstand the common crypto concepts such as  encoding, encryption and hashing. There have been several real world examples, where application passwords were stored using base64 encoding assuming that these passwords cannot be viewed in clear text. It should be remembered that encoding is a way to manipulate the data into a different format often without requiring any keys thus the encoded data can be easily decoded. 

Another commonly seen scenario is storing credentials using weak hashing algorithms such as MD5 and SHA1. Attackers can perform password cracking attacks to retrieve clear text passwords when credentials are hashed weak hashing algorithms. It is recommended to use a strong hashing algorithm with the use of salts to make password cracking harder. The following figure shows a database table storing user credentials using the MD5 hashing algorithm.

Poor password requirements

Even when credentials are stored using secure hashing algorithms, a weak password can still be a culprit and an attacker may be able to crack these passwords using a variety of password cracking techniques such as dictionaries and rainbow tables. Users must create strong passwords when creating accounts and applications must enforce usage of strong passwords when users create passwords.

Improper error handling

Improper error handling often aid in attackers performing password brute forcing by revealing their usernames. Some developers tend to return detailed error messages to the users on login pages. For example, the following error may be shown when a user attempts to login with a username that does not exist in the database.

Username doesn't exist

This clearly gives an attacker hint that the username doesn't exist. Similarly, if a user enters a valid username but an incorrect password, the following error message is shown.

Password is incorrect

These types of detailed error messages are a perfect recipe for username enumeration attacks.

These  types of errors are also commonly seen in features such as Forgot Password. Such features often let the users enter their email id to send a password reset link with a message as shown below. 

A password has been sent to your registered email id

However, when an email id that does not exist in the system is entered, it may show the following error message.

Account not found

Once again, such a detailed error message often gives an attacker the opportunity to enumerate email ids. Ideally, a generic error message should be shown when there is a failed attempt on login or password reset pages.

Learn Applied Cryptography

Build your applied cryptography and cryptanalysis skills with 13 courses covering hashing, PKI, SSL/TLS, full disk encryption and more.

Start Learning

Conclusion

Poor credential management is commonly seen in applications. Poor credential management can lead to massive reputation loss during data breaches and many organizations are spending their efforts on educating both users as well as developers on the use of strong credential management. In the next few articles, we will discuss how attackers can leverage poor credential management using some examples followed by some of the security best practices that can be followed to avoid such issues.

 

Sources

1. https://cwe.mitre.org/data/definitions/312.html
2. https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password
3. https://owasp.org/www-community/vulnerabilities/Password_Management_Hardcoded_Password