Securing cleartext user-id/pwd

[cxm1601]

Richard,
Thanks for helping resolve the hanging TWS issue this morning. I am encouraged to ask another issue that has bothered me for quite some time.

Are there better ways to implement securing clear-text user-id/pwd in the IBC?

[rlktradewright]

Some suggestions (when I say 'you' in the following, I don't mean you personally, just 'the user'):

1. You can use the IBKR Mobile app for second factor authentication with IBC. This provides worthwhile backstop protection, but doesn't directly address your question.

2. On Windows Professional or Enterprise, encrypting the config.ini file means that it can only be read by the owning user. Even someone who steals your computer and runs low-level disk utilities cannot decrypt it (unless they can log on as the owning user, but we have to assume that the user is going to take normal measures to ensure their system is secure). Note that not even an administrator can read an encrypted file that they don't own, even if they take ownership.

3. On Windows Home, file encryption is not supported: in my view, this is a prime reason not to use the Home edition. The cost of upgrading to Professional is trivial in comparison with the daily Starbucks or whatever, it should be a no-brainer (and the Professional edition has other useful features, not least better control over updates). But if you must use Windows Home, at least use BitLocker to encrypt the whole disk.

4. On Linux, the encryption story is not straightforward: whole disk encryption can be done in many ways, which protects against theft, but a valid login allows the disk to be read transparently. I'm unaware of anything similar to the user-based encryption provided by Windows Pro/Enterprise. However I know some Docker users have stored their password in Kubernetes secrets: this involved some effort, its absolute security is questionable, and it's presumably not an option if not running IBC in a container.

5. On Windows or Linux, store the config.ini file on a removable drive of some sort: SD card, USB memory stick, etc. The config.ini file is only accessed when IBC starts, so the drive an be removed as soon as IBC is running.

6. On Windows (any edition), run TWS in another user. For example:
   a. install TWS and IBC under your normal user.
   b. Create a new non-privileged user, with a good strong password: for example call it trader.
   c. Log in to trader, and create its config.ini file in the usual way (encrypted if on Windows Pro/Enterprise).
   d. Log out of trader, and return to your usual user.
   e. Edit StartTWS.bat to point to trader's config.ini file at C:\Users\trader\Documents\IBC\config.ini - don't use %USERPROFILE% here because the way we're going to run it that variable won't ever be created.
   f. Create a .bat file called, for example, RunIbcAsTrader.bat containing this command:

   runas  /user:trader C:\IBC\StartTWS.bat
   

   g. Execute RunIbcAsTrader.bat from your usual user session. You'll be prompted to enter the trader password, and then IBC will start, running under the trader user, and using trader's config.ini, but visible within the normal user session (note that trader doesn't need to be logged in for this to work).

   So now we have TWS running in your normal user session, but even if you walk away and leave the computer logged in and unattended, no-one can see the config.ini file (unless they know the trader password). The only time you ever need to log into trader is to modify config.ini - in my experience, with my live account, that is a very rare occurrence. And in fact, you don't even need to log in for that: you can run a text editor under the trader user in exactly the same way as StartTWS.

   A variant of this technique is to always run TWS under the trader user by logging in to it and then running StartTWS, and then switch back to the normal user session for other work. This has the advantage that you can't accidentally mess with TWS while doing normal work, but is less convenient if you are actively using TWS (as opposed to running API programs). When you need to look at TWS, you just switch users to trader.

7. It must possible to do something similar to 6. on Linux using the su command, but I haven't tried it.

[rlktradewright]

A couple of additional points worth making:

1. There is a Linux tool called Tomb, which I was unaware of until yesterday, which looks like it could be useful here. You could create a tomb and store the config.ini file in it (files are stored encrypted). Before running IBC you'd have to open the tomb (which requires entering the password, so this can't be automated) and this would mount the tomb and make the files contained in it accessible - your IBC start scripts would refer to the config.ini file at the tomb's mount point.

   Note I don't know of any Linux-based mechanism that can avoid manual intervention of some sort: either inserting a removable drive, or entering a password or PIN somewhere.

2. What I do myself is run IBC in a virtual Windows machine. If need be I can access it via RDP. Since I want this running all day every day, I host this on a permanently-on virtualisation host running Hyper V Server, but it could just as well be a desktop machine running Windows 10 - just remember not to turn it off!.

   I run IBC under a non-privileged user, and the config.ini file is encrypted for that user.

   I would prefer to be able to run the live and paper IBCs under different (Windows) users: then I'd hardly ever have to RDP to the live session, which I usually only need to change when upgrading to a new TWS version, since I don't manually trade. Whereas I fiddle with the paper trading TWS regularly during the course of developing my trading platform. Sadly IB treats this the same as running TWS on different computers, and doesn't allow market data to be shared.

[kasper747]

Some suggestions (when I say 'you' in the following, I don't mean you personally, just 'the user'):

1. You can use the IBKR Mobile app for second factor authentication with IBC. This provides worthwhile backstop protection, but doesn't directly address your question.

2. On Windows Professional or Enterprise, encrypting the config.ini file means that it can only be read by the owning user. Even someone who steals your computer and runs low-level disk utilities cannot decrypt it (unless they can log on as the owning user, but we have to assume that the user is going to take normal measures to ensure their system is secure). Note that not even an administrator can read an encrypted file that they don't own, even if they take ownership.

3. On Windows Home, file encryption is not supported: in my view, this is a prime reason not to use the Home edition. The cost of upgrading to Professional is trivial in comparison with the daily Starbucks or whatever, it should be a no-brainer (and the Professional edition has other useful features, not least better control over updates). But if you must use Windows Home, at least use BitLocker to encrypt the whole disk.

4. On Linux, the encryption story is not straightforward: whole disk encryption can be done in many ways, which protects against theft, but a valid login allows the disk to be read transparently. I'm unaware of anything similar to the user-based encryption provided by Windows Pro/Enterprise. However I know some Docker users have stored their password in Kubernetes secrets: this involved some effort, its absolute security is questionable, and it's presumably not an option if not running IBC in a container.

5. On Windows or Linux, store the config.ini file on a removable drive of some sort: SD card, USB memory stick, etc. The config.ini file is only accessed when IBC starts, so the drive an be removed as soon as IBC is running.

6. On Windows (any edition), run TWS in another user. For example:
   a. install TWS and IBC under your normal user.
   b. Create a new non-privileged user, with a good strong password: for example call it trader.
   c. Log in to trader, and create its config.ini file in the usual way (encrypted if on Windows Pro/Enterprise).
   d. Log out of trader, and return to your usual user.
   e. Edit StartTWS.bat to point to trader's config.ini file at C:\Users\trader\Documents\IBC\config.ini - don't use %USERPROFILE% here because the way we're going to run it that variable won't ever be created.
   f. Create a .bat file called, for example, RunIbcAsTrader.bat containing this command:

   runas  /user:trader C:\IBC\StartTWS.bat
   

   g. Execute RunIbcAsTrader.bat from your usual user session. You'll be prompted to enter the trader password, and then IBC will start, running under the trader user, and using trader's config.ini, but visible within the normal user session (note that trader doesn't need to be logged in for this to work).
   So now we have TWS running in your normal user session, but even if you walk away and leave the computer logged in and unattended, no-one can see the config.ini file (unless they know the trader password). The only time you ever need to log into trader is to modify config.ini - in my experience, with my live account, that is a very rare occurrence. And in fact, you don't even need to log in for that: you can run a text editor under the trader user in exactly the same way as StartTWS.
   A variant of this technique is to always run TWS under the trader user by logging in to it and then running StartTWS, and then switch back to the normal user session for other work. This has the advantage that you can't accidentally mess with TWS while doing normal work, but is less convenient if you are actively using TWS (as opposed to running API programs). When you need to look at TWS, you just switch users to trader.

7. It must possible to do something similar to 6. on Linux using the su command, but I haven't tried it.

Very useful ideas! Thank you very much.
Interesting solution with a different users. I dont use the encryption in Windows much. Kinda sceptical of it. But this is actually very good idea to use a different user.