Talk:Viewer Authentication

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 04:14, 29 September 2007

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.

Nicholaz

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)

Why not use DNS based security as an optional extra on a residents account settings? I use another website and to protect the login you can restrict it to the reversed looked-up domain name. So if you always login through an ip address/range that the reverse dns says xxx.myisp.com then you can lock the account to only be possible to login from that ISP. This helps a lot against phishing attacks because the phisher is unlikely to be using the same ISP. To bypass the dns name restriction incase you are logging in from another location, you have to go through the password recovery options via email. This would seem a better solution to protect against phishing. Jonash Vanalten 07:00, 7 December 2007 (PST)

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)

I see someone added that inline. Could you verify that this is LL's position and goals? -- Argent Stonecutter 14:07, 29 September 2007 (PDT)

Bad Idea

I'm sorry, but this is another very bad idea, Rob. It causes far more problems than it solves...if it solves any except letting you tie into Open ID.

Please do NOT implement access to SL through the SL website! Lindal Kidd 14:09, 1 October 2007 (PDT)

But this is an *installed* programme, not a website!

"it is possible to create a clone of the Second Life viewer" is, quite clearly, totally true. However SL is something you install on your local machine; it isn't run in Java (or whatever) inside a web browser window. As such you are *fully aware* that you are downloading and installing the official client. This new mechanism would appear to be sensible for non-official clients, but for the official one it makes no sense at all as it is clearly superfluous. --AlisonW 13:07, 2 October 2007 (PDT)

Please don't!

I absolutely hate this browser-centric world view. I do not wish to run a browser in connection with the Second Life client, which, refreshingly, was a program without too much web-tie-in until now. I am not afraid of using an open source client, I compile my own! It is already hard enough to compile, don't make it harder! Also, I keep my concierge account logged in on the web site, but use alts to work inworld. This would break that mode of working.

Melanie Milland 16:21, 2 October 2007 (PDT)

Grids other than agni

It appears the Release Candidate viewer that uses this scheme is unable to log in to any grid other than agni.lindenlab.com. Is the login page hard-coded to https://secure-web14.secondlife.com/app/login/?show_login_form=True or is there a way to direct it to another grid's login page? Day Oh 17:55, 5 December 2007 (PST)

Alternative grids are usable with the RC Client

Alternative grids are usable now with the RC client. The one nuance is you must specify -loginpage and -loginuri on the commandline and bring up the client before loading a SLURL

Another thing to note, an alternative client should be able to avoid the whole login without the mozilla lib issue by responding to a SLURL generated by The Go In World Page

Teravus Ousley 22:42, 9 January 2008 (PST)