I'm writing a slack bot that interfaces end users with an API. That API only method of identification is the raw "login:password" encoded to base64 (it doesn't answer back a token) ...

Currently in test mode, I'm just asking users to send their credentials to the bot and then the server can make requests to the API with their credentials.

I can't change the http request to the API, but what can I do on my side to store the credentials so the user doesn't have to re-enter their password for every request ?

Is a reversible encryption any good ?

update: my last idea is to store the password for only a short period of time

  • 2
    Do the credentials belong to a 3rd party service? If yes, do you expect users sharing their credentials with you? – Laiv Mar 14 '18 at 7:29
  • Is this an API that you have any control over at all? Is there something that does what the API does in a more secure manner? Even proxying passwords to an API has a security incident waiting to happen. – Berin Loritsch Mar 14 '18 at 16:26

Yes, if you have to be able to present the user's password to an external service (as opposed to just verifying that they know it), then you have to store their password in a recoverable way.

It's certainly best practice to encrypt the value when you store it, it just doesn't add much security - the password is exposed every time it's sent over the internet, where anybody and their brother might be listening in, and any attacker who obtains your database probably also obtains your program code, which tells them how to decrypt the database. In this scenario, encryption basically only protects against casual onlookers or against low-skill adversaries (that is, attackers who don't know how to decompile your code).

  • Best practice is to architect in a way that the password is unnecessary, and a token is used in its place. – Berin Loritsch Mar 14 '18 at 13:58
  • that's what I thought. My last idea is not to store the password permanently but for only a short period of time and allow the user to unstore it when they are done as well. – Eagle1 Mar 20 '18 at 2:20

This whole architecture is inherently insecure. There is a reason why most APIs use OAuth to authorize an app to behave on behalf of the user. It reduces the risk that the app can escalate privileges beyond what the user wants, and it provides a means for the user to cancel that interaction from either side. More importantly, the user's password remains only the user's password.

The problem with reversible encryption is that all a hacker needs to do is get a copy of your database and they are free to brute force crack your website. Given that many hacker tools make use of GPUs, they can brute force check keys at an alarmingly quick rate.

Once that password and the user's identity is known, the hacker can impersonate them directly.

Considering that many frameworks provide OAuth support for you, there is little reason not to use it.

  • I do not see how OAuth can help in this scenario. – Bernhard Hiller Mar 14 '18 at 14:09
  • Oauth would be a valid answer for the developers of the API I'm using. – Eagle1 Mar 20 '18 at 2:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.