Return to Answer

Typically you would store the token in a configuration file in your program or web application. It's also good practice to encrypt the portion of the config file which contains sensitive information.

Note that you cannot hash the credentials because you need to be able to decrypt them back to plain text so you can pass them on.

As a side note, if your application is a website, the configuration file should not be publicly accessible (apache/IIS/etc will prevent that based on the file type), so in theory, if your web server is secure, many people feel they don't have to encrypt the sensitive portions of the config file. That being said, I almost always recommend it. It's pretty common for config files to be stored in source control which may have different levels of security access.

As for storing the token in the database, that is similar to the config file, in that your "file" is in a database. The same rules should apply. You could encrypt the key in the DB if you wish, but more importantly make sure that access to the DB is locked down as tight as possible, similar to how you would for locking down a config file on the web server.

Since you will be generating an API key for each user, you could do exactly like you suggest- which is essentially treating each token like you would a password. You could store the id, the salt, and the hash of the token in your database. Hashing is great as long as you never need to get the original key back.

Note that since this is something your system is generating, it isn't as important to hash it in the first place (unlike for a user generated password). But this depends on your threat model. If someone hacks your server, would you care if they had a list of everyone's API key? If yes, then hashing them is the way to go.

Typically you would store the token in a configuration file in your program or web application. It's also good practice to encrypt the portion of the config file which contains sensitive information.

Note that you cannot hash the credentials because you need to be able to decrypt them back to plain text so you can pass them on.

As a side note, if your application is a website, the configuration file should not be publicly accessible (apache/IIS/etc will prevent that based on the file type), so in theory, if your web server is secure, many people feel they don't have to encrypt the sensitive portions of the config file. That being said, I almost always recommend it. It's pretty common for config files to be stored in source control which may have different levels of security access.

Typically you would store the token in a configuration file in your program or web application. It's also good practice to encrypt the portion of the config file which contains sensitive information.

Note that you cannot hash the credentials because you need to be able to decrypt them back to plain text so you can pass them on.

As a side note, if your application is a website, the configuration file should not be publicly accessible (apache/IIS/etc will prevent that based on the file type), so in theory, if your web server is secure, many people feel they don't have to encrypt the sensitive portions of the config file. That being said, I almost always recommend it. It's pretty common for config files to be stored in source control which may have different levels of security access.

As for storing the token in the database, that is similar to the config file, in that your "file" is in a database. The same rules should apply. You could encrypt the key in the DB if you wish, but more importantly make sure that access to the DB is locked down as tight as possible, similar to how you would for locking down a config file on the web server.

Typically you would store the token in a configuration file in your program or web application. It's also good practice to encrypt the portion of the file which contains sensitive information.

Note that you cannot hash the credentials because you need to be able to decrypt them back to plain text so you can pass them on.

Typically you would store the token in a configuration file in your program or web application. It's also good practice to encrypt the portion of the config file which contains sensitive information.

Note that you cannot hash the credentials because you need to be able to decrypt them back to plain text so you can pass them on.

As a side note, if your application is a website, the configuration file should not be publicly accessible (apache/IIS/etc will prevent that based on the file type), so in theory, if your web server is secure, many people feel they don't have to encrypt the sensitive portions of the config file. That being said, I almost always recommend it. It's pretty common for config files to be stored in source control which may have different levels of security access.