Application Password Management Using APIs

There is arguably not a more important topic in the technology world today than security. Security can no longer be an afterthought for organizations serious about protecting their data. It must be an integral part of all processes, procedures, infrastructure, and applications.

Compliance is another closely related topic that has certainly surfaced as critically important for today’s technology-driven operations. New compliance regulations affecting your organization can lead to serious consequences for violations. Passwords are an extremely important part of your overall security and compliance strategy.

An area that is often overlooked as part of security and compliance is application passwords. A much more secure technique for managing passwords as part of your overall security and compliance strategy is application password management using APIs. What is this? How is it effective?

Why hard-coded passwords are dangerous

Passwords are arguably one of the weakest links when it comes to the overall security posture of your organization. Weak passwords on the side of end users can provide an easy door for an attacker who may easily be able to “crack” an end user password to compromise credentials.

However, another area of risk that often creeps into application development is the use of hard coded application passwords. Most business applications require some type of authentication to backend resources such as databases. These are typically secured with a set of user credentials.

Many organizations may create a service account that has a hard-coded password which is set to Password never expires.

When an account is set to Password never expires the password aging policies that may be in place in your organization no longer apply to the said service account. Why are service accounts typically configured this way?

This traditional approach to setting up a service account with a non-expiring password prevents the application from breaking due to a password aging. The challenge with changing a service account password is that you not only have to change the password at the source, i.e. Active Directory or other directory service, you also have to change the service account password in every system, application, configuration file, etc, that references the service account.

If the service account password update is missed on a single system referencing the old password, this can lead to an account lockout. An account lockout is triggered when there are too many failed login attempts for a specific account. This leads to “domino effect”. All systems and applications referencing the service account will fail due to the account lockout.

As you can imagine, the typical workaround of setting passwords not to expire on service accounts can create a major security vulnerability. This increases the likelihood of the password becoming compromised at some point in the future.

What makes traditional service account methodologies worse is developers may hard code the service account and password in plain text inside of configuration files. An example is found in the snippet of a web.config below:

<appSettings>
<add key="ApiURL" value="https://myserver.mydomain.com/api/APIasset" />
<add key="serviceaccount" value="dbuser" />
<add key="password" value="P@$$word" />

An attacker who gains access to your environment and is able to find low-level configuration files such as the above, now has access to a potentially powerful and high-level account that may be used to access a database or other resources. They may now have the credentials they need to insert, delete, modify, or otherwise access your data in a way that is destructive or poses a data leak risk.

There is literally untold damage that can be inflicted if an attacker is able to compromise service accounts that have access to business-critical resources. What about compliance?

Hard coded passwords are a compliance nightmare

Most compliance frameworks including PCI-DSS place certain requirements around passwords and password changes. These include the following:

• At least seven characters long
• Contains both numeric and alphabetic characters
• Expires every 90 days
• Different from previous passwords
• No vendor-supplied defaults are allowed for passwords

Note, the above requirement of enforcing password changes at least every 90 days. If a system is in scope, this password change requirement includes service accounts that may have a hard-coded password used inside an application or configuration file.

When looking at most compliance regulations, most mandate that passwords are not hard-coded inside an application or configuration files. This will certainly lead to an audit finding in your environment by both internal and formal audits by a third-party.

Maintaining security and compliance can be complex when traditional means of invoking service accounts and hard coding passwords are used. Is there a better way to manage passwords in your environment that keeps applications secure as well as allows easily changing passwords for your applications?

Application Password Management Using APIs

Today’s modern programming methodologies need to use more secure ways of invoking service accounts for applications that need to access resources such as databases and others. Application passwords can be effectively secured using an API-driven approach. How so?

An API endpoint is typically a web resource that is exposed to applications which allow performing various actions or querying data. By using application password management using APIs, developers can store credentials in a secure password vault or management solution instead of embedding the credentials inside applications or configuration files.

When an application needs to securely access a resource such as a database using a set of credentials such as a service account, instead of hard-coding, it can instead query the API for the passwords to a specific user account. This is known as application-to-application communication.

This helps to align your organization with application development security best practices of separating the credentials and password from the code or application. In this way, even if an attacker gets their hands on the code or configuration files, they do not have the all-important credentials used for accessing secure resources.

Effectively managing application-to-application passwords requires that you have a secure solution for housing the secure credentials and providing a way to serve those out in a secure manner to your applications.

Securden Password Vault

Securden’s Password Vault for Enterprises enables a secure way to store, organize, and provide secure credentials to your applications requesting them. It does this by providing secure APIs for application passwords. This allows developers to query the Securden database to retrieve credentials.

Instead of hard-coding the credentials into scripts, applications, and configuration files, the credentials can be accessed from the Securden database in a dynamic way. How is access granted via Securden to the database that houses the credentials?

Securden uses a token-basedauthentication mechanism. Applications accessing the Securden APIs need the API URL and an auth token. Securden Password Vault allows for additional security measures to be put in places such as the following:

• Token validity – the token can be put in place without an expiration date, or it can be configured so that it is valid only for a specific period of time.
• Token applicability – A specific account can be specified for which the access token is valid

Below is an example of how the Securden Password Vault API would be queried to access a secure credential with an access token.

Input data (arguments): account_id (Required)

curl -k -H "authtoken: a8deffe7-5301-4034-ade8-1ba73f72e262" -X GET "https://pvault:5454/api/get_password?account_id=1000000027810,"

If you note above, the application is querying the Password Vault API with an auth token. Additionally, the account ID is needed to specify the account the token is referencing. Securden will then make sure the auth token is good for the account being requested.

Securden assigns a User ID that is only valid within the Securden platform. The key here is that at no point do you know which “real” account is referenced, or what the “real” password is for that account.

In addition to the anonymization of a user account and password embedded inside applications, scripts, and configuration files, the use of auth tokens and access to the Securden database is fully logged. This provides a detailed audit trail of account and authorization events.

Aside from application-to-application password management, Securden Password Vault provides many other great features for managing passwords, keys, documents, and identities in your environment. These include the following:

• Centralized management
• Sharing credentials with a team
• Providing remote connections without knowing the password
• Single sign-on
• Password policy enforcement
• Expiration alerts for accounts expiring
• Security reports
• Mobile access
• Autofill credentials with a browser extension

Download a fully-featured trial version of Securden Password Vault here.