Storing Passwords for External APIs - Best Practice

Storing Passwords for External APIs - Best Practice

If you're comforatable with the potential liability when a hacker gets into your database / filesystem, then go for it. And in all fairness, you should also disclose to your users that their passwords will be stored on your system, and let them decide if they want to give your program that level of trust.

But why do this in the first place? Facebook Connect and Twitter & Google using OAuth there's no need for you to store user passwords at all. At some point a user's cookies will expire (or they'll try to access your site from another computer) and they'll have to re-authenticate. You can't prevent re-authentication - instead, you should make it as easy for the end user to handle as possible.

Best Practice for Storing and Updating External API Passwords

With regard to the password history I would go down one of two routes:

1. As per your current plan, store passwords in file/db/config - suggest you use a hashing algorithm (as opposed to encryption) to compare the new password with stored password hashes for "equality".

2. Don't bother storing password history at all - let the first attempt to the password change web service just fail if it chooses too, then resend with an alternative password. This way, you are not duplicating the business rules of the password change web service (for example, lets say they change it to allow you to re-use a password after 6 months time).

With regard to storing the current password: assuming you must send the password as plaintext, then yes, you should store it in encrypted form. There are many articles out there on how to do this. Or you could even encrypt a specific section of your config file such as seen here.

Best practice for storing external API secrets in server using AWS?

For secrets you'd want to be looking at Secrets Manager. The contents are natively encrypted via KMS so rest assured they'll be encrypted.

Any interaction is done via API, so it would be authenticated via IAM

Secure Way of storing Passwords to APIs without OpenID?

There isn't a secure way to do this. You can employ workarounds, but that's about it.

1. Storing passwords in YAML or XML in cleartext is definitely out
2. In fact, even encrypting and storing passwords is wrong. Your application would need a way to decrypt the passwords, so the attacker can also decrypt the passwords.
3. The recommended way to store passwords is Salt + Hash, but because it becomes unrecoverable, it is useless in your case.
4. Because of 2 & 3, no matter where you store the users credentials, you are vulnerable.
5. Storing the cookies instead of the passwords is a better idea. But again, this involves the password going through your website, which isn't good.

Given your situation, storing the cookie is a better approach. Use HTTPS throughout, even on your website. Its less than ideal though, and you and your users should be aware of it.

What is the best practice for securely storing passwords in Java

You can use a local keystore where you could put passwords instead of secret keys.

Answer to edit:

Keystores are a perfect fit for your need. If you want extra protection, you could ask the user for one password to access all passwords when the user starts the application. Then, you could protect stored database password with a simple salt-and-stretch method (to generate an encryption key) using the one password that was used when starting the application.

Best practice for storing passwords for automation

There are different options, both using encryption for password using a key, and protecting the key storage using HSM module.

option (1): Using Database with HSM module

You can store passwords encrypted in database and benefit from a feature in SQL 2016 "Always Encrypted (Database Engine)".
Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the Database Engine (SQL Database or SQL Server).

You can use Hardware Security Modules (HSM) with Always Encrypted.

The hardware security module (HSM) is a physical device that safeguards digital keys and performs cryptographic operations. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or to the network.

When you get an HSM, you also get a software libraries implementing common APIs, such as Microsoft Crypto API and Cryptography API. These API are called Cryptographic Service Provider (CSP) and Cryptography API: Next Generation CNG providers.

Your applications can communicate with an HSM using those APIs.

For more securing the HSM module, you can:
- Tie the HSM to your Database Server.
- Tie the HSM to your admin login to Operating System Server.

for more details:

Always Encrypted (Database Engine)
Using Hardware Security Modules with Always Encrypted

Also, Oracle database and other engine can provide encryption with HSM

Securing Stored Data Using Transparent Data Encryption

Option (2): Store password in files in Protected storage using HSM module:

• Encrypting files that contain passwords. This may be done by the operating system, an application, or a specialized utility such as password management software that is specifically designed to protect the confidentiality of passwords.

• Using OS access control features to restrict access to files that contain passwords. For example, a host could be configured to permit only administrators and certain processes running with administrator-level privileges to access a password file, thus preventing users and user-level processes from accessing passwords.

• As you are not using hashing, I exclude this option, but it's a mechanism for storing one-way cryptographic hashes for passwords instead of storing the passwords themselves.

---

Related Topics