Making API calls from hashed passwords

Do you really need multiple users on external site?

May be I could not frame my question very well. I require the token from this external website who's API I am using. To get the token, I will need to pass the username and password. The password however in this case is hashed and stored in my db, so sending the unhashed password to the API service is turning out to be impossible.

This token will be obtained from the backend of my web app. So the user who logs into my app, does not see or require the process of sending requests to the external site.

May be I could not frame my question very well. I require the token from this external website who's API I am using. To get the token, I will need to pass the username and password.

Can you not use one set of credentials against this external site?

The password however in this case is hashed and stored in my db, so sending the unhashed password to the API service is turning out to be impossible.

As it should

The API request and receiving of the required data from this external site is done in the backend code of my app. So I require the unhashed password of the user to do that.

Can you not use one set of credentials against this external site?

Actually, this API is called only when a specific service is demanded by the user. For all other purposes, the API call to the external site is unnecessary, and so I do not wish to login to this site until the user demands the specific service.

There is no secure way of doing that.

• You would not want to transfer the password from client
• You would not want to store the password on server using reversible encryption

Can you not use different passwords on this external site's API?

Yes, I can store this external site's login credentials in my database, but the password has to be stored unhashed in this case. That is what I am thinking, it will not be a secure way..

Properly encrypted and different to your site without any reference to its intent.
But this is not ideal

Properly encrypted and different to your site without any reference to its intent.
But this is not ideal

Could you please explain a bit more?

For JWT to be valuable here, the API would need to be aware of and support JWT.  If that's the case, it will probably be documented in the API man pages.

I am planning that the username and password for this external site will be same as the login credentials of my web app, so that I can query the user details out of my database and send them over to the API request.

Understood this to mean that he is writing both API and site - maybe he can confirm.

Actually, the external site is a service that I have purchased online, and its API provides me access to features it contains.

If you want to tell us where we can find the man pages for the API, I'll be glad to look deeper.  Otherwise, refer back to here:
https://www.experts-exchange.com/questions/28996757/Making-API-calls-from-hashed-passwords.html?anchorAnswerId=41972484#a41972484

Store an encrypted version of the API credentials.  Decrypt them and transmit them over HTTPS.  Never write the clear-text credentials to anything but the API call.  You will probably be OK with that kind of strategy.

This is the link to the API documentation of the required site: http://docs.weaved.com/docs

I have for now stored its password unhashed as it is still running on my localhost, but I'll soon upload the project to my cloud space. Security would n=be an issue then.

Does the API require different credentials per user or do you have different users accessing YOUR system with their own credentials and YOUR system makes a call to the API using a single set of credentials.

If each user has their own credentials then the only solution I can see is to store them encrypted in the database - not entirely secure as anyone with access to your code base and data will be able to decrypt but not sure I see an alternative.

Different users are given different accounts.

Julian is suggesting difference users but with same password

Julian is suggesting difference users but with same password

I was really just trying to clarify one way or the other - not suggesting shared as I don't know the use case and it may be that the API requires per user authentication to deliver the services that it does.

Shared or per user - the API is a separate entity - with no relationship to the site under development. Authorizing to the latter should give the user access to a profile in which their API credentials are stored. As mentioned in earlier post - encrypt the user credentials for the API and store it in their profile. When the API needs to be called the credentials are obtained from the profile, decrypted and integrated into the API call.

I read the docs, thanks for posting that.  The user login returns a token; you use the token in successive calls for services.  

See also: https://www.remot3.it/web/remot3-it-is-the-new-weaved.html
It looks like the API docs you showed us will still be supported.

The correct answer is here.
https://www.experts-exchange.com/questions/28996757/Making-API-calls-from-hashed-passwords.html?anchorAnswerId=41972484#a41972484

Be sure to read this article that was referenced -- It contains information you need to know about as you build your client DB.
https://www.experts-exchange.com/articles/28835/Keeping-Secrets-with-PHP.html

@Ray, can't see how hashing is the solution to the problem.

The original question was about how to use the same password for the API that is being used to logon to the askers site. Given he hashes his passwords - the password is not available to send to the API.  The docs say the token returned is for a particular session - so you can't save the token to be used across sessions.
Somewhere he has to store the credentials for the user for the API - whether the same as his logon credentials or not. Or am I missing something here.

I used the accepted solution from here, http://stackoverflow.com/questions/1289061/best-way-to-use-php-to-encrypt-and-decrypt-passwords, only I wonder how safe this is.. Anyway, thank you for your valuable time. I had been out of my place for a few days and failed to reply on time..

Just a thought for going forward... Check the dates of the code samples you choose.  That SO example dates from 2009, and was sharply criticized by Anthony Ferrara in 2012 (IRCMaxell is one of the core contributors to PHP), so it was undesirable five years ago, and probably isn't any better today.

"How safe it is" will be largely dependent on how valuable it might be to attack your application and client base.  Security measures are like fire safes - they are rated on the basis of time and temperature.  Nothing is absolute, but you may get adequate notice of an attack in time to protect the contents of the fire safe or the database.  There is an adage that says, "Don't let the great be the enemy of the good."  In most cases, any encryption at all is the "good" because so many databases are kept in clear text that attackers will just go try something else if they find obstacles in their way.

In any case, best of luck with your project, ~Ray