You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
IB Secure Device
- Thread starter IB Salvatore
- Start date
Quote from local_crusher:
While thinking about it today, I came to the conclusion that the IB security token offers no security at all.
Here are my thoughts:
- A trojan can modify TWS XML settings files, thus allowing local API access without the user gaining knowledge.
Next, the trojan will connect to TWS via localhost API or DDE connection.
VERY EASY TO IMPLEMENT.
All modern trojans are modular and an appropriate module would be loaded to the infiltrated victims host if someone wants to steal an IB account.
- WM_KEYDOWN / WM_KEYUP events.
As IB TWS is a Java program, there is no possibility to prevent it being remotely controlled with hostile WM_KEY** events.
For example, software firewalls & virus scanners will typically recognize if they are fed with key events from another software. They load their own drivers (*.sys) and operate in kernel mode.
This is only possible with access to low-level system functions!
By design, IB's JAVA TWS cannot be protected from such attacks as Java does not offer access to low-level system functions or driver access.
An attack with Windows key events would not take longer than 1-2 seconds and the TWS windows could even be minimized during this.
The user would have no chance to intercept this manually.
Do you see any vulnerability if one only uses the webtrader? Maybe until IB comes up with a totally bullet proof solution, I will have to use the demo account to get data feed and charts, and use webtrader to enter orders.
Your thoughts are appreciated.
Quote from local_crusher:
TO IB REPRESENTATIVES:
I think you have a false assumption of a too strong security the device would give.
A hacker can without problems remote-control a logged-in TWS and send orders for executing a pump-and-dump scheme.
Modern Trojans contain not only functions to record mouse & keyboard events, but take full control if neccessary.
In this scenario, the device would be absolutely no help.
Please consider these thoughts.
The security device is going to preclude anyone from signing on to TWS without the use of your device. And even with your device, they would need to know your personal pin code to use your device. I suggest you review the details of the working of the security device.
Now, whether anyone can get into your TWS while you're logged in is a separate question. But I'm not seeing how anyone is going to defeat my routers, firewalls, anti-viral programs, along with the security device.
OldTrader
Quote from siki13:
Are you saying that pump and dump can
be perform on any liquid trading instrument,S&P emini for example?
there is at least a published incident where the hacker used thin options on a thick stock.
preventing hacker's access to the trading system should be the key issue here.
Quote from local_crusher:
While thinking about it today, I came to the conclusion that the IB security token offers no security at all.
Here are my thoughts:
- A trojan can modify TWS XML settings files, thus allowing local API access without the user gaining knowledge.
Next, the trojan will connect to TWS via localhost API or DDE connection.
VERY EASY TO IMPLEMENT.
All modern trojans are modular and an appropriate module would be loaded to the infiltrated victims host if someone wants to steal an IB account.
- WM_KEYDOWN / WM_KEYUP events.
As IB TWS is a Java program, there is no possibility to prevent it being remotely controlled with hostile WM_KEY** events.
For example, software firewalls & virus scanners will typically recognize if they are fed with key events from another software. They load their own drivers (*.sys) and operate in kernel mode.
This is only possible with access to low-level system functions!
By design, IB's JAVA TWS cannot be protected from such attacks as Java does not offer access to low-level system functions or driver access.
An attack with Windows key events would not take longer than 1-2 seconds and the TWS windows could even be minimized during this.
The user would have no chance to intercept this manually.
Thank you for a detailed explanation...
Though your conclusions are obvious to any software engineer...
And, most certainly, to IB's engineers.
But everyone misses the point.
IB makes money by offloading endless services onto the Customer...
Who then bear the cost instead of IB.
That's how the managers at IB think...
What other costs can we transfer to the Customer?
The "security device" simply transfers most of the ** risk of online fraud ** to the Customer...
Because IB can easily make the False Claim that the "security device" is foolproof...
And the Customer MUST be at fault... MUST be negligence or inside job.
Try explaining the content of your post to a 70 year old Connecticut judge.
IB's approach also fails the laugh test.
People do not put 5 locks on their door...
They put one good lock... plus get insurance...
Because all security devices have major limitations.
Unlike E*Trade that simply says "Dont worry... you are insured"...
IB rejects insurance...
And then tries to force you to put "5 locks on your door".
The whole IB security situation is scary as hell.
SIPC only protects against a broker-dealer going bankrupt...Quote from gkishot:
Can you pls explain what you mean by 'IB rejects insurance'. IB is insured by SIPC, isn't it?
It does not cover online fraud within a specific broker-dealer.
And BD bankrupcies are very rare... less than 10/year out of 5,000 American BDs.
If IB's accounts are insured for online fraud...
Can a representative from IB please post a link to an IB web page explaining the insurance in detail?
If not... shame.
- The only secure method I see (with the Secure Device) is to sign any order submission with it.
But clearly, that is not practically viable, at least with a device that gives you a secret key each time.
It would be different with a little USB token. But this would be platform dependent !
- In my scenario, WebTrader is just as vulnerable, as it is just another Front-End. I am assuming IB will require Device-based logins for both WebTrader & TWS
But clearly, that is not practically viable, at least with a device that gives you a secret key each time.
It would be different with a little USB token. But this would be platform dependent !
- In my scenario, WebTrader is just as vulnerable, as it is just another Front-End. I am assuming IB will require Device-based logins for both WebTrader & TWS
Regarding what I call an "advanced pump&dump":
Sorry I really do not want to make any further statements as it would only harm all of us. These Hackers might be reading a thread mentioning a security device.
But the Mini S&P is one of the few instruments it would NOT work with.
Sorry I really do not want to make any further statements as it would only harm all of us. These Hackers might be reading a thread mentioning a security device.
But the Mini S&P is one of the few instruments it would NOT work with.