How to mitigate Credential Management Vulnerabilities

Introduction

In the previous articles about credential management, we discussed how credentials can be used in applications and what can go wrong when dealing with credentials in applications. We have also discussed real world breaches detailing how those breaches have uncovered poor credential management by several companies.

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 best practices developers can follow to avoid credential management vulnerabilities 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

Avoid hardcoded clear text credentials

Hardcoded credentials is a common problem in applications. As a best practice, developers must avoid hardcoding sensitive data such as database connection strings. This is a hard to avoid problem and some frameworks such as ASP.NET provide some easy solutions, using which developers can encrypt connection strings.

Connection string typically contains sensitive information such as database credentials. When the server is compromised or Web.config file is exposed through a misconfiguration, an attacker can gain access to the database by grabbing the connection string available in Web.config file.

The following excerpt shows one of the common ways to write connection strings in ASP.NET web applications. 

<add name="dbconnection" connectionString="Data Source=localhost\SQLEXPRESS;Initial Catalog=users;Integrated Security=False;User Id=sa;Password=p@ssw0rD;MultipleActiveResultSets=True" />

As mentioned earlier, it is not safe to have connection strings in clear text. We can use an inbuilt application aspnet_regiis.exe on the server to encrypt connection strings.

Running the following command by specifying the site name and tag to be encrypted from the web.config file will encrypt the content specified within the tag.

Once the encryption is successful, the connection string will be encrypted as shown in the following excerpt.

    <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#">

      <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />

      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

        <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">

          <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />

          <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

            <KeyName>Rsa Key</KeyName>

          </KeyInfo>

          <CipherData>

            <CipherValue>H9IQe+dVa2cEPCpA/h4wVbgwxz/iIkkvRXUBRWBt7FD02TwcmCux5xpob6uzNpuTk5vqhdBkV/3exF0NXSDJ2Y2ATNi6qcrOna/i74Nr75JhCMJ7rvMzrsfipq7Skp6xuhoQejPDHezonUBj/Xo1UkLVz/YWNKH+ZfXLlKYfbg+xQ8Ik1Q40kNr7C+PpiR8ThlXeA1VltVzJGqhpuR8dMui/CwzeAKVUcjodCr1g1JKYCS8rtkCTwsXx+8j1QmfCXj90CPEURv7d7nB12/SkdmfsCLZogTw+bYSSYtc70b15jDV1adreUqC1apARpS18zHiojQzm9kBvXyncQ+SvKA==</CipherValue>

          </CipherData>

        </EncryptedKey>

      </KeyInfo>

      <CipherData>

        <CipherValue>8YOcL1VhHMzzeKUTOlVIdGjXJu566qORL6YKImwHFDGuzknpmzMKYIKLiEMKalpc/wPY+WHqXyb2D109g7WuLNjZ3GRJjxfK7kVB8drihXjmxe1JTl67opRBNN6nzdaPKBUT5nEm9fKpNGUQP945+vSsGOO1qy5Vs4H6mudwoiYkT06K10mS3iRgYPeQQ5HqyEWDLawC07/EkcwA1L/hFTJl9AxDY94JN/R/DUbQXk8+6EWiDIvR//O4n4w1mHL0EdmzoWpWPrty18sLolxmrkJbL3uc7uJzsdvzQuzWMzft+0OxkJaKdhwXnDqSFx4aSY9iNcG3QPg36TZ7V+PC3Ttd+M404WF8kj3SszexPnAJvCZtKwZLIuXTYjN0ATdJpWnze78qSCqRe4f65CTeWYoNvcyTB6vWvo2GV3kBBQDUBjnuF2Peu6i8qPrLbS9zzeSNNsR3gOaXesIPVwlIFxdUhfi0N06B7zChtOckP6IopbJD4tahHT4NvM8bX3kXs79YutM/SvqcNZbwnLW51Yw3w8qxZA0H3zW7LvVrpj0w9zE5zQN1XKM6sCZzr09kYzO8uHLPzw+uhTOKEho9dA==</CipherValue>

      </CipherData>

    </EncryptedData>

All the sensitive data is now encrypted, and the application still works fine. The steps shown here add additional security to the connection string. However, it should be noted that a malicious user with administrative rights on the server can easily decrypt it by running the following command.

Using a secret vault

A better approach would be to use a secret vault for retrieving credentials using an access token, which can be rotated and revoked when required. The credentials stored in the vault should be encrypted at rest and should be retrieved over an encrypted connection. 

Secure data storage

When user credentials are exposed through a vulnerability like SQL Injection, the entire database can be compromised. Storing passwords in hashed format can at least reduce further damage. It is always recommended to use hashing with salts to add extra security. This typically prevents an attacker from performing dictionary attacks on exposed hashes. Though we have multiple hashing algorithms such as MD5 and SHA1, it is not recommended to use them even with salt because they may protect the sensitive data such as passwords from dictionary attacks, but it is still possible to crack passwords using brute force attacks. How do we withstand brute force attacks? A secure way to store a password is to use an algorithm with salt and delay factor such as the BCrypt algorithm.  This one-way function can prevent brute-force attacks because it is computationally slow, and it needs a lot of time to generate all the values to crack hashes using brute forcing.

Enforce strong password requirements on users

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.

Use of safe error handling

Improper error handling often aid in attackers performing password brute forcing by revealing their usernames. It is recommended to use generic error messages to avoid leaking usernames via error messages.

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

We discussed several practical examples and case studies to understand how dangerous poor credential management is and why it can cause great damage to an organization. Inorder to minimize the damage during data breaches, organizations must ensure that appropriate care has been taken while handling sensitive data in applications. Developers must avoid hardcoding sensitive data, users must be forced to use strong passwords and it is recommended to store sensitive data such as passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt or PBKDF2. 

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