To "automate" a transaction of this type you need to have static storage of tokens. in THEORY any cipher is breakable given enough time an power. Given that most encryption standards in use today are not really very strong and most keys are easily accessible to a smart person (with direct access to the machine) the banks are right. Add to this the fact that "save my password" and other setting can make a public systems a prime scrape target (think internet cafe). Let's not even start discussing packet capture and and other advanced techniques. Now consider that most "advanced" security technics consist of not letting you store your password and requiring manual entry† and no, they are not the same.
Now the reality is that ANY internet communication is inherently insecure. Even with all the available realtime encryption a determined attack WILL defeat the encryption. This means that even given the "it may not be safe to give you automated access" argument the "improved access" argument is bunk. Yes the banks are right. Their practice is wrong. If they really had your security in mind they would do the following: 1. No net access at all. 2. Require to go to a branch for all communication (your kids have access to your mailbox? what about the neighbors?) 3. Refuse to accept checks, debit transaction (largest areas of fraud). 4. Have no investments in "risky" ventures like low credit mortgages, stock, etc. Banks don't like hearing it, but a rational evaluation of their practices shows that none of them actually have "security" in mind. In reality most customers don't really care either. They just want to know that the crook has to try a little harder to compromise them. Sorry for the rant. Jaysen † Look up javascript "onkeyup()" and "AJAX". It is possible to detect a manual password submitted in a field using server side session management and timing approximations (look in your banks login page source). On Dec 22, 12:56 pm, Jason Frisvold <xenopha...@gmail.com> wrote: > Jaysen wrote: > > BUT, their excuse is legit. The OFX download is inherently insecure > > from a theoretical perspective. In the real world it holds up fine. > > Too bad most of the folks who make these decisions "internet security" > > are so detached from the real world that they are unable to see the > > stupidity of this position. If we used the same logic to determine is > > heart transplant were "secure" then we the medical community would > > never have would have tried it. > > Why would you say it's insecure? The downloaded file is accessed in the > same manner you would access the account, so the same security features > should be in place, no? > > > For the record I am one of those "internet security" types. More on > > the implementation and verification then decision making, but close > > enough to see both side of the story. > > I dabble.. > > > Jaysen > > -- > --------------------------- > Jason Frisvold > xenopha...@gmail.com > --------------------------- > "I love deadlines. I like the whooshing sound they make as they fly by." > - Douglas Adams --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "No Thirst Software User Forum" group. To post to this group, send email to no-thirst-software@googlegroups.com To unsubscribe from this group, send email to no-thirst-software+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/no-thirst-software?hl=en -~----------~----~----~----~------~----~------~--~---
