I am looking to create an application that aggregates data from people's online accounts.

The application (Frontend made with HTML/CSS/PHP and Backend made with Python) will log into people's accounts on various websites and grab data then send them push notifications on their device.

For websites that have an API, I will be using that, so no problem. However, a lot of these websites do not have an API.

So therefore I am going to need to store their login information somewhere, so that the script can go and login and grab the data.

This obviously, raises red flags for me. I don't want to risk people's data. What if I get hacked? I can't risk storing this information in plain text in a database somewhere.

I'm struggling to understand the best way to tackle this problem. I've looked at a few other answers to similar questions on here but I'm not sure they apply to my situation (or i'm just being stupid).

The best way I can think of doing this so far, which is not 100% foolproof but better than nothing, is to encrypt all the login information using a very secure password, and require that to be entered when the backend script is run.

Is that all I can do?

  • Have you looked into HSMs?
    – Tobi Nary
    Feb 12, 2019 at 8:09
  • 2
    I think the reason for why you can't come up with any good solutions is that there are none. Limit yourself to sites with an API. Ignore the rest. There is no safe way to solve the problem. There probably is no legal way to solve it either - your users will probably be violating the terms of the services you aggregate data for and risk having their accounts closed.
    – Anders
    Feb 12, 2019 at 8:34
  • HSM can't solve this issue
    – Lie Ryan
    Feb 12, 2019 at 12:11

1 Answer 1


IMHO, there are two different problems here.

The former one is technical and resumes to how can I securely store secret information. If it must be used by an application, the best you can do is to encrypt the information. But whatever you do, the application will have to access the plain text information, so if its is hacked, the attacker will have it. At least the information is protected at rest. If the application has to run in unattended mode, things are even worse because the decryption key has to be available on the machine itself. The safer way would be to use a HSM to protect the master key, but anyway the HSM must be accessible from the machine, so if an attacker manages to control it, they will be able to use the HSM to get the master key. At least you will be able to say that you followed a best effort strategy.

The latter is more fundamental: if a user gives you their credentials on a third party site, you (and any staff member with admin priviledge on the machine hosting the application!) will be able to impersonate that user, without the third party site beeing able to differentiate the accesses. IAMNAL, but I suspect that this could lead to interesting legal problems if the account is used for weird operations... Be sure to get a lawyer's advice on the contract you will have with your users.

  • The liability issues are a concern, but there are tons of services that hook into other accounts for various reasons (posting or alerting on events in your social media accounts, etc.) So I think there is an easy model to employ for that part.
    – schroeder
    Feb 12, 2019 at 10:45
  • @schroeder: You are probably right. But I still think important for such a service not to miss that point. Feb 12, 2019 at 10:55
  • Oh, of course, but your phrasing makes it sound more dire than I think it is.
    – schroeder
    Feb 12, 2019 at 10:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .