Difference between revisions of "Talk:Viewer Authentication"
m |
|||
| Line 8: | Line 8: | ||
This is like snogging SARS patients to improve your health. | This is like snogging SARS patients to improve your health. | ||
Web based UIs are the #1 tool for phishing. The most commonly used web browser in the world is not just insecure, it has security holes that can not even in theory be fixed. It has been a running gag for 10 years now. | Web based UIs are the #1 tool for phishing. The most commonly used web browser in the world is not just insecure, it has security holes that can not even in theory be fixed. It has been a running gag for 10 years now. And if you're worried about people using open source software for phishing, the popular open source browsers are actually MORE secure than the native ones on BOTH Windows and OS X. | ||
On Linux, ALL the browsers are open-source. | On Linux, ALL the browsers are open-source. | ||
| Line 15: | Line 15: | ||
PS: you also need to fix the proxy support in SL before you even THINK of making it use that splash screen for logging in, because that bad boy never even shows up if you're behind a proxy. -- [[User:Argent Stonecutter|Argent Stonecutter]] 22:18, 28 September 2007 (PDT) | PS: you also need to fix the proxy support in SL before you even THINK of making it use that splash screen for logging in, because that bad boy never even shows up if you're behind a proxy. -- [[User:Argent Stonecutter|Argent Stonecutter]] 22:18, 28 September 2007 (PDT) | ||
---- | |||
This should go long intense beta (release candidate) before switching. Things like proxies, network, and a thousand other variants will break this and make it impossible for people to log in. | |||
For example for some debugging scenarios I'm compiling the viewer without llmozlib. If anything, the web communication in the first iteration should happen through libcurl. | |||
[[User:Nicholaz Beresford|Nicholaz]] | |||
---- | |||
The weakest point in the approach however is that a malicious viewer can do anything it needs, once logged in. And when started it can simply install a keystroke logger. | |||
Even a web based application (promising to do whatever would appeal to people) could redirect to the SecondLife page for login, either spoofing the SL page or just grabbing the legit login token and then do something else with it. | |||
The only way I see in order to increase security in relation to transactions and valuable assets is to protect these transactions with disposable passwords or one time transaction numbers (TANs), which is an established procedure in the bank industry. But even then a viewer could simply catch the TAN and execute a different transaction instead. | |||
Another approach would be to issue secondary passwords with limited power, so that a viewer logged in with that, will never be able to execute power transactions. | |||
[[User:Nicholaz Beresford|Nicholaz]] | |||
---- | |||
Revision as of 06:14, 29 September 2007
I am sorry but the incidences of account hijacking from persistant logins is going to be FAR greater than incidences from phishing.
How you can actually write something like "So long as you are logged into the website on someone's else computer, they will be able to gain access to your account" and then continue on with the idea /at all/ is astonishing.
Log into web site and launch SL? That's fine by itself. "There" worked that way and it was ok, not as good from a pure usability standpoint but ok..., but it it /cannot/ be persistant. We are talking about real money theft here. This is a lowering of security not an increase in it. And I know that other people do it and there is a "remember password" checkbox on the viewer but that doesn't excuse this. If increasing security is actually the goal, persistant logins anywhere are an about face to it.
This is like snogging SARS patients to improve your health.
Web based UIs are the #1 tool for phishing. The most commonly used web browser in the world is not just insecure, it has security holes that can not even in theory be fixed. It has been a running gag for 10 years now. And if you're worried about people using open source software for phishing, the popular open source browsers are actually MORE secure than the native ones on BOTH Windows and OS X.
On Linux, ALL the browsers are open-source.
This change will reduce reliability, reduce security, and reduce people's confidence in SL. If anything, you should be centralizing logins in the client and have it handle authenticating the browser, not the other way around. -- Argent Stonecutter 22:09, 28 September 2007 (PDT)
PS: you also need to fix the proxy support in SL before you even THINK of making it use that splash screen for logging in, because that bad boy never even shows up if you're behind a proxy. -- Argent Stonecutter 22:18, 28 September 2007 (PDT)
This should go long intense beta (release candidate) before switching. Things like proxies, network, and a thousand other variants will break this and make it impossible for people to log in.
For example for some debugging scenarios I'm compiling the viewer without llmozlib. If anything, the web communication in the first iteration should happen through libcurl.
The weakest point in the approach however is that a malicious viewer can do anything it needs, once logged in. And when started it can simply install a keystroke logger.
Even a web based application (promising to do whatever would appeal to people) could redirect to the SecondLife page for login, either spoofing the SL page or just grabbing the legit login token and then do something else with it.
The only way I see in order to increase security in relation to transactions and valuable assets is to protect these transactions with disposable passwords or one time transaction numbers (TANs), which is an established procedure in the bank industry. But even then a viewer could simply catch the TAN and execute a different transaction instead.
Another approach would be to issue secondary passwords with limited power, so that a viewer logged in with that, will never be able to execute power transactions. Nicholaz