I want to automate some of my home admin.
I'm writing a small-ish website, to do that. Written in C#/.NET, hosted on Azure, backed by an Azure SQL DB, codebase available publicly on GitHub.
One of the things that I'm going to want my site to do is log into a couple of other websites in Selenium and scrape some information.
I don't want to have to worry about whether I've done password storage correctly, so I'm expecting to have the user (me! :D) enter the relevant password(s) into my site's UI each time it wants to do this scraping.
So I'll enter the relevant p/w into my site, in plaintext, which will be transmitted to the server in Azure, my code will briefly hold it in memory before plugging it into the Selenium UI of the destination site (again, in plain text).
I want to make sure that I've not made myself less secure by doing this.
What are my security considerations & solutions for this system?
I think that there are 4 attack vectors that I should be consider:
- Something snooping on the requests between my home PC and my Azure site.
- Something snooping on the requests between my Azure site and the destination site.
- Someone noticing the source code on GitHub.
- Someone gaining access to the Azure system.
And I think my solutions/responses to these things are:
- This is solved by implementing standard TLS for my site, as documented on OWASP.
- I assume that the destination site is inherrently securely set up (otherwise logging into it from my home PC is ALSO insecure, in which case my new system is no worse.). So all I need to do is to make sure that Selenium is respecting all the normal security of "a browser talking to a website".
- I have control over write-access to the codebase. Read-only access to the code-base should never be a security risk, as you already assume that the attacker has full knowledge of the structure of your system. The codebase doesn't know anything about the password, so I'm not exposing anything there.
- Would depend on what it is that they can do in there... If they can see the Database, that's not a problem since the password never gets put there. If they can monitor traffic, that's no different from #1 and #2. If they can replace my executables they I'm irrevocably screwed because any protection I make can be un-done by changing the executable.
Based on the above:
- I think that the first 2 have known solutions.
- I think the 3rd isn't a problem.
- I think the last one isn't solvable (but is also very unlikely to be a risk)
I can't do anything that resembles sending a hash of the password (rather than the password itself), because I fundamentally need my server code to have the plaintext password so that it can give it to the destination site UI.
I could try to do some encryption of the password, in my browser (or in my head) and have my site decrypt it. But either I use proper, safe encryption where knowing the mechanisms and encryption keys doesn't help ... in which case I think I'm just re-implementing TLS, and will probably do a bad job. Or I'm adding simplistic security-by-obscurity enciphering, which doesn't achieve anything because the code-base is public (and hence so is the full de-ciphering mechanism & key).
Is my analysis and understanding correct?