2

I have a server set up to run a PowerShell script every 15 minutes. This script needs to make API requests with keys and passwords. The script runs even when no user is logged in, so encryption based on the user profile wouldn't make sense, right?

I only have one server to work with, so any solution involving owning another server is out. The server is also a cloud server, so I do not have physical access to the machine or its internal network.

I also have no budget to work with, so paid solutions are out.

What is best practice to offer me the maximum amount of security given these parameters, and how secure is that solution, whatever that solution may be?

Bonus: this server is extremely slow due to resource limitations (as in, it takes a full 2 minutes to open the start menu after clicking it from RDP, freshly installed). It would be great if the solution did not require a significant amount of installation or processing power.

Improve this question
12
  • 1
    What do you want to be secure from?
    – schroeder ♦
    Commented Dec 5 at 15:31
  • @schroeder I've been informed that storing plaintext passwords/keys in a script is considered bad practice and a general no-no. Based on what I've been told, I would think that the idea is that if someone compromises the machine, they still shouldn't be able to view passwords/keys in plaintext. I could be mistaken; I'm sorry, I normally wouldn't go about any of this in this way, but my limitations are what they are. All of the solutions I've found while searching seem don't seem to apply to my situation.
    – user258111
    Commented Dec 5 at 15:41
  • Ok, so you want to protect against someone logging in and getting access to the API password in the script, but what would happen if that password leaked? Additionally, if the password was not exposed, could someone simply edit the script and use it to do what they want without knowing the password.
    – schroeder ♦
    Commented Dec 5 at 16:17
  • @schroeder Password leak would be pretty bad, the API's that are accessed are business critical. I suppose you are correct that someone could edit the script if they had that level of access. There is only one user account on the machine, so I don't know if file permissions even matter; if they have access to the machine it's through the admin, right? And the file should already be admin only by default, right? I'll double check permissions. I know I need to lock down the server to prevent access to it. But, if all of this is the case, does it even matter if the secrets are plaintext?
    – user258111
    Commented Dec 5 at 16:24
  • 2
    @majneeds2chill: I think a lot of the confusion comes from the fact that you do everything (even make web requests) from the admin account. This is a very bad idea and indeed makes a lot of best practices useless. But this isn't the fault of the practices, it's an issue with how you use the system.
    – Ja1024
    Commented Dec 5 at 17:30

1 Answer 1

Reset to default
3

Since the script needs the API key as plaintext, you cannot completely hide the key. At least the account which the script is running under will always have access to the key, so if that account is compromised, any protection falls apart.

What you can do, however, is create a service account just for the script, ensure that only this account has access to the key, and that the key is encrypted at rest. I'm no Windows expert, but you should be able to access the Windows Credential Manager from the PowerShell. Create an extra service account for the script and store the API key as a credential for that account. To my understanding, this will prevent access from any other account (including the main account you normally use) and also provide encryption at rest.

Improve this answer
15
  • What about creating a service account makes the account harder to compromise than my own account? If I'm understanding correctly, both the script and the credentials would be tied to the service account, right? So what's the advantage? Sorry if my understanding is wrong.
    – user258111
    Commented Dec 5 at 16:41
  • 1
    @majneeds2chill: The advantage is that an account which does nothing but run a single script has a much smaller attack surface than a general-purpose account which you use for manual tasks, starting different programs etc. To compromise the API key or script, an attacker would either have to compromise the system account (root in Unix terms), or there would have to be a major vulnerability in the script itself – if one of this happens, you’re screwed anyway. But in all other cases (e.g., if an attacker manages to compromise an account but not gain system privileges), the API key is protected.
    – Ja1024
    Commented Dec 5 at 16:53
  • @majneeds2chill: You cannot protect the API key from the script or the system account. But you can protect it from other accounts .
    – Ja1024
    Commented Dec 5 at 16:55
  • 2
    @majneeds2chill: To be frank, making web requests from the admin account is insanely dangerous and a far bigger problem than any plaintext keys. You should definitely fix that. I'm very sure that Windows allows you to run scheduled tasks under an unprivileged account.
    – Ja1024
    Commented Dec 5 at 17:26
  • 1
    I have indeed confirmed that it is possible to run a task with non-system privileges even if no user is logged in. I had been informed multiple times, incorrectly, that this was a limitation of task scheduler. I apologize for the confusion. I will not run any script with any more privileges than it needs to run. I do understand how network vulnerabilities work.
    – user258111
    Commented Dec 6 at 15:28

You must log in to answer this question.