i raise this question before, but no respond from IB. once again-what about in case of short disconnection? or if you or someone else log in your account in TWS from different machine and you got that famous pink grid? (i'm personally use it all the time to create disconnection while working on handler of such event)-do you have to use device again? what about multiple users for single account? each user must have his own device or one for all? Thank you!
Sal...I'd question that. I agree a short disconnection should not cause a new challenge. But someone logging into the same account from a completely different IP address...that seems like a big red flag. If both machines are behind the same router they'd both appear to be the same IP address to the IB servers (I think so anyway), so you'd probably be safe ... but if they were from two different locations on the internet I'd think you'd want to get a challenge (or at least a popup saying that's why you got a pink out and if you weren't doing this on purpose you'd know someone had somehow hacked your account). Thoughts?
Short disconnects - No authentication Pink Screens - No Authentication Competing log ins that result in a log out- New Authentication
Rather than PM'ing you as you suggest, I'd prefer to ask this question out in the open if you don't mind as a lot of people want to know the answer: Is there going to be an opt-out for individual accounts, yes or no? This was promised on another thread. I run TWS and client software using the API on a machine hosted half-way around the world from me. What is your solution?
Note that a router may have multiple IP addresses if the corporation (eg, your ISP, Cisco, IBM, etc) owns a range or ranges of IP addresses. This will be true unless NAT (Network Address Translation) is applied to lock internal addresses down to one external address.
The only way to achieve this is to not accept another login within a minute after a successful login.... I guess that's fair for "human" based clients. I stand corrected.
Well, hopefully it wouldn't be implemented this way. One way to do it securely is: After a successful login, a shared secret is established between the client app and the server. On a reconnect, that shared secret is used to authenticate.... And "short" will determine how long that shared secret is still valid once a connection goes idle. So the only way to hack is to compromise the JRE or anything at a lower level (like the OS as the OS provides for memory protection against other processes reading memory, etc.). In any case, great to hear that the reconnect issue will be addressed. That was a big worry when I saw it mentioned as needing re-STP'ing.