1

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:

  1. Something snooping on the requests between my home PC and my Azure site.
  2. Something snooping on the requests between my Azure site and the destination site.
  3. Someone noticing the source code on GitHub.
  4. Someone gaining access to the Azure system.

And I think my solutions/responses to these things are:

  1. This is solved by implementing standard TLS for my site, as documented on OWASP.
  2. 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".
  3. 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.
  4. 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?

Improve this question

1 Answer 1

Reset to default
1

The biggest concern seems to stem from the use of a password you know being transmitted to a remote site for gathering information. The biggest staple in password based authentication protection for your use case is HTTPS which will prevent most MitM attacks and obscure your information from packet sniffers.

As far as being concerned about someone hijacking your Azure system, it sounds like you don't have much to lose. All your code is available on line, the only thing I would worry about is your database and the data you store there. If your credential for accessing the database can be found anywhere on your application server, then your data could be exposed. Unfortunately, you can't do much to stop an attacker on your machine other than to decommission and rebuild and prevent them from entering in again.

Now, the challenge behind password based authentication is continuing beleaguer the security community. Passwords are terribly difficult to manage and aren't great for security. While some protocols have been built to try and mitigate these risks (NTML, Kerberos, etc), we're finding that more secure authentication schemes are required. Depending on your relationship with the vendor, may be worth looking to see if they can or will support FIDO, OATH, or other modern authentication solutions in the near future.

Improve this answer

You must log in to answer this question.

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