>You say you need a secure auth and communication method on totally untrustworthy >clients. Now is that possible ? If they could log keypresses, they would be able >to fake them as well, and have your business app do whatever they want in >the name of the logged in user, once auth is passed. It is not problem if they will 'see' communication. Or record keys. Once I have external key, logging/watching is not problem at all. >Using an authentication method involving some hw (calculator you mentioned) on >the user's part (with all the inconvenience..) you might prevent an attacker >from stealing auth info, but compromised terminals are still a threat for already >logged in users. True, I know.... If attacker will setup tunel (or they will be connected throw proxy), hack browser to get sessionid/cookie (I know it is easy) then .... :) _but_ requires 'hacker', not script kidde. It requires someone, who 'knows' how 'things' works. Not some stupid 12 year old slink, which is running 'some script, which is c00l'. There is no *real* security... Or I am miss ? I will be happy then... >It's like connection hijacking (the attacker does not need auth info) but instead >of the network layer, it happens somewhere between the keyboard and the browser. >(Or inside the browser, or whatever the compromised terminals might come up with..) True... That's why we come up is 'user class'. It means - user can log in different auth classes. If user will work from untrust terminal, he will log on some lower class (for ex. 'read only'). If someone will hack connection, he can't do *everything* in the system. It is better than nothing. Security is only question of time. Nothing is secure. Only time required to 'hack' them is different. All I am trying is to make this period a bit longer, than pure https login. And connection hijack is my second biggest problem... Any hints how to prevent connection hijack ? Cookies can be stolen pretty simple, session ID too. IP address can be changed during requests (lame providers like AOL). Because of bugs in Internet Explorer we can't use 'keep alive' (and keep SSL layer using one sessionID/symetric keys) for longer time [if server will remember these things, then hijack will be harder to do - still possible, but harder - and it is a point]. Server can verify IP address (suck AOL and similar), cipher type/parametres, exact browser version, ... and check every request. But simple tunnel (or a bit work around) .... I didn't find any acceptable solution :-( In todays world, if someone will WANT to break into informations, he will do it. Just question of time....... Best regards, Lada 'Ray' Lostak Unreal64 Develop group http://www.unreal64.net
This archive was generated by hypermail 2b30 : Mon Apr 29 2002 - 15:00:38 PDT