I am using Instagram API by mgp25.
Here, you can gain access to the IG api via "logging in": the API (in php) requires a password and account id to be in plain text format when gaining the access.
Here is the setup that I have:
I have a site where there are users and the site has IG API integration. These users can input their Instagram User/Password (not the user info to log into the site) to gain access to the API.
However, these API only accepts plain text for password (since the password will then be verified within the IG server).
Problem:
The problem that I am having is the password security. Obviously I can't store the IG password as plain text, but if I hash them, it can't be used to login to the API either (as it is one-way only).
Methods:
I can only think of encrypting the password (not hashed) and decrypt them when needed. However, I can see a few issues with that approach as well.
I wanted to ask you guys what you guys think of the best way to address this issue.
(note. The official IG API has some limitation and are only allowing official business partners to have more functions which I need them. So the API by mgp25 is the only viable option at the moment).
You could require the password only once. The private API will save the cookies / session forever and you do not need to do a login again.
So this way you don't have to store passwords and, if for some reason the user is logged out, then you ask for password again. Does it make sense?
Related
I am currently programming a WebApp in which I need to use an API from a large company. I need to store my users' data for accessing the API somehow. How can I store my users' API keys in my database without them being used in case of a data leak?
I want the password to be linked to an account so that the user only has to enter the password once, even if they access the WebApp from different devices?
To be precise, I would need to store a username and password that can be associated with an account.
If i would encrypt the Password somehow i would really like to do it in PHP, so that everything is happening on my Servers.
I thought about encrypting the data for the API with the User Password of my WebApp but even with that i don't know how i would do that in PHP.
Addition 02.11.2022
The API (which is a school-timetable-app) doesn't use Keys, it uses the Login Credentials (Password and Username), with which the users even login to the application. The API is just an readout of the school-timetable-app.
I am developing an admin panel for the company I'm working at, and was wondering about something. I want to increase the experience for the employee. I want them to be able to connect to their email by entering the login credentials, and then read the emails inside the admin panel. What I need help with is this:
If I establish an imap_open connection, I need the password in plain text (as far as I know). I can't safely save the password in the database knowing that it would be a catastrophe if a hacker got their hands on the data.
Basically, I want to:
Create an imap_open connection with an ENCRYPTED password. Preferably as bcrypt.
Do any of you know how to do this? I've searched on google, and even seen some other questions on stackoverflow, but I can't seem to find an answer to the question. I would NEVER save the password as plain text. And just using a COOKIE or SESSION seems cumbersome.. for the admin to login to their email all the time, when all I want is for the email to load for the appropriate admin account when logged in.
If I'm understanding correctly, you want to:
store the user's password securely on their machine
use it to connect to the mail server
download email
Storing the user's password in plaintext is clearly a no-no. There are different ways you can handle this. The application could actually request the password from the user, which is an easy but not very convenient solution.
Usually passwords are stored using one-way hashing schemes such as SHA256 or bcrypt, but that means that you can only check whether a password matches them; you can't retrieve the password and send it elsewhere. So you have to turn to symmetric key encryption. You store the encrypted password somewhere (in a database), and when you need it you retrieve it, decrypt it, and send it over your IMAP connection. The problem with encryption is that it relies on a key, which may be compromised at some point, but hashing is not an option if you need to retrieve it.
The other thing to note is the risk in sending the password in cleartext. This is very much taken care of if your server uses SSL.
Yes, of course AUTHENTICATE PLAIN encodes a password. But servers which support admin access allow you to encode the admin's password along with the user's name so you can access the user's account.
$login_str = sprintf("%s\x00%s\x00%s", $user_name,$admin_name,$admin_pwd);
$login_str = encode_base64("$login_str", "");
When you use the encoded string in an AUTHENTICATE PLAIN login you are given access to the user's account. And you don't need the user's password.
If you do this with AUTH PLAIN...
sprintf("%s\x00%s\x00%s", $user_name,$user_name,$user_pwd);
Then you get access to the user's account. But supplying admin credentials seems to do what the OP wants to do without storing passwords.
If your IMAP server supports admin login via AUTHENTICATE PLAIN then you don't need the user's password to access his mailbox.
Many IMAP servers support this, for example Dovecot, CommuniGate, Zimbra, to name three off the top of my head.
I want to make a light webapp on top of a REST api, where the user should authenticate only once, from then on all request against the web api would hopefully be done by keeping alive the username and password in some way.
I have already made a working prototype where I store the username and password in session variables if the first request to the REST api is successfull, and from then on every request is made with auth info gotten from the session variables. So far so good.
With this approach, I realize someone with access to the server would be able to read the password. Is there some way in PHP that i could follow my approach with an appropriate amount of security?
Update with some further details:
The intended goal here is to make a visualisation of data retrieved from an API, based on querying it with different data, but not having the user enter his username and password for each attempt. So the API is totally stateless, but the web application with gui should be statefull.
In this case I have no control over the Rest API, so each request to it will always require sending the API username and password with basic auth, there are no alternative schemes such as a API key, session token or anything like that. This is why I have to retain the username and password for as long as a user session lasts, and I wanted to know if the approach with storing them in session variables could be considered secure.
As long as you're not storing session state on the REST API server, only on your client webapp, it seems fine from an architectural point of view.
If you really must use the username and password and can't get a disposable token, you may encrypt them with a server-side key, and decrypt on-the-fly when you send them to the API, so even if someone can hijack a session they can't obtain the username and password without the server-side key, but you should be a lot more careful with leaking your php session anyway.
PHP Session Security.
Follow the steps outlined in the answer for that question, except that you should use HTTPS for all interactions, between the user and the webapp, and between the webapp and the REST API.
I am trying to submit credentials inserted by users through a Facebook application, which must be validated by an external system. I'm trying to submit them by this sitehttps://studenti.unisalento.it/. I read a lot of articles about the data posting by the PHP extension libcurl, management of cookie, ecc (like thishttp://www.herikstad.net/2011/06/logging-to-https-websites-using-php.html) but I can not post credentials to a login prompt system like this https://studenti.unisalento.it/auth/Logon.do
Any ideas??? Thanks!
Edit:
I noticed that you can login entering credentials in the url with this scheme: https://username:password#studenti.unisalento.it/auth/Logon.do?p_p_id=58&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=1&saveLastPath=0&_58_struts_action= You can take advantage of this using libcurl functions?
The correct answer even though it's not the answer you are looking for is: Don't do it.
You want students to enter their university login and passwords into your Facebook application?
Have you talked to the university about this?
How do they know your app isn't storing the submitted login and password somewhere so that you can hack into the student accounts later?
The likely answer is: They don't.
This is why things like OAuth and Shibboleth were invented. They allow you to authenticate users from a third party without collecting the user's actual credentials.
unisalento.it appears to have a Shibboleth installation. If you are running a legitimately sanctioned application, look at using that or some other authentication scheme that doesn't involve you collecting the username and password.
Since you're using PHP, simpleSAMLphp may be useful.
I have made a API script for my website, so people can login from another website.
It's using PHP cuRL to POST data to my website.
I'm using a api key (md5 hash of the website) to verify the website with my MySQL database.
But when someone is using my API Client (PHP cURL), they also can save the username's and passwords of my user's.
How can i prevent this?
You might want to consider using OAuth. It's designed for exactly what you want to do.
I someone is typing their username and password onto a website other than your own, there is no way for you to prevent the owner of the website from capturing it...
What you'll want to do is have your site generate a secure set of credentials for the users account, similar to a username/password, but only to be used by the API. Also, prevent this new set of credentials from having the ability to do things like delete the user's account or change email address.
Also, give the users the ability to have their API credentials changed if they want (in case a third party gets it and the user no longer wants them to have access).