Difference between revisions of "Talk:Viewer Authentication"
Rob Linden (talk | contribs) |
|||
Line 50: | Line 50: | ||
There's a group collaborating on a formal critique at [[Viewer Authentication Critique]]. This will help Linden Lab have a more organized response and hopefully make sure we don't miss anything. -- [[User:Rob Linden|Rob Linden]] 12:09, 29 September 2007 (PDT) | There's a group collaborating on a formal critique at [[Viewer Authentication Critique]]. This will help Linden Lab have a more organized response and hopefully make sure we don't miss anything. -- [[User:Rob Linden|Rob Linden]] 12:09, 29 September 2007 (PDT) | ||
Could Linden Labs provide a similar page explaining why this is believed to be necessary and what problems they are trying to solve? -- [[User:Argent Stonecutter|Argent Stonecutter]] 13:33, 29 September 2007 (PDT) |
Revision as of 12:33, 29 September 2007
Account hijacking
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. -- —The preceding unsigned comment was added by Farallon Greyskin
Security through browsers
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)
Long beta
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.
Keylogging, XSS, TAN, Secondary Passwords
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
Usability
As I understand it from reading the wiki and a portion of the developer discussion, this would not only constrain a resident to be logged in on the same account website/inworld, but also make it impossible to be inworld with more than one account at once (from one workstation login session). Please correct me if wrong.
If the above is true, I think you will find that the marginal security improvement is far outweighed by the negative usability impact of this change. It impacts residents who bring commerce into SL the most, since estate owners and businessfolks generally use one account for website transactions, and a small set of alts to manage their inworld lives.
Builders and scripters will also find this impossibly awkward, since they often need to have two accounts logged in at once for testing.
Forum users will also be negatively impacted; I leave the forum logged in all day on one account, regardless of which alt I am using inworld. If any.
Please reconsider. (Nika Talaj)
Formal critique
There's a group collaborating on a formal critique at Viewer Authentication Critique. This will help Linden Lab have a more organized response and hopefully make sure we don't miss anything. -- Rob Linden 12:09, 29 September 2007 (PDT)
Could Linden Labs provide a similar page explaining why this is believed to be necessary and what problems they are trying to solve? -- Argent Stonecutter 13:33, 29 September 2007 (PDT)