Difference between revisions of "Viewer Authentication Critique"

From Second Life Wiki
Jump to navigation Jump to search
(Editorial pass. Added summary)
Line 2: Line 2:


For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]
For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]
== Summary ==
The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem.
There are no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response or due to allowing weak passwords.
Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method.
There seems to be no demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.
It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.


== Security ==
== Security ==
Line 21: Line 33:
** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
*** This kind of attack is not theoretical, phishing websites are a criminal industry.
*** This kind of attack is not theoretical, phishing websites are a criminal industry.
*** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer
** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns
** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns
** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
Line 29: Line 42:
** Links to secondlife:// can not pass parameters to the program
** Links to secondlife:// can not pass parameters to the program
*** In fact allowing that was a security flaw recently found and fixed in the SL client. :(
*** In fact allowing that was a security flaw recently found and fixed in the SL client. :(
** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.
<br>
<br>
* Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
* Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
** The issues raised in the next section would mean that people would have an incentive to use this kind of client.
** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.


=== Alternatives ===
=== Alternatives ===
Line 38: Line 52:
* separate passwords for website account and being inworld
* separate passwords for website account and being inworld
* Account restrictions  
* Account restrictions  
* CRAM-MD5 or a similar challenge-response type  
* Allow third party plug-ins in the viewere (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)
* Dictionary check to reject insecure passwords
* This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.
=== Other Issues ===
** CRAM-MD5 or a similar challenge-response type  
* The main existing vulnerability involving the viewer and passwords is that the viewer does not use a cryptographically secure mechanism to pass the password to the server, <b>not</b> that the viewer may be stealing the password.
** Dictionary check to reject insecure passwords
* In practice, trapdoored unofficial third party clients for applications have not historically been a major problem. This seems to be attacking an exposure that is primarily theoretical, and using a mechanism that has been known to be exploited to solve it.
<br/>
<br/>


== Flexibility ==
== Flexibility ==
Line 61: Line 72:
*** Via a "go to website" link in the client that passed an equivalent token.
*** Via a "go to website" link in the client that passed an equivalent token.
<br>
<br>
* As noted in section 1, this reduces flexibility for the *users*.
* As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes


=== Alternatives ===
=== Alternatives ===
Line 68: Line 79:
** OpenID - [http://openid.net/]
** OpenID - [http://openid.net/]
** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]
** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]
** Shibboleth - [http://shibboleth.internet2.edu/]
** CAS - [http://www.ja-sig.org/products/cas/]
** CAS - [http://www.ja-sig.org/products/cas/]
<br/>
*** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security
<br/>
 
<br/>
== Persistence ==
== Persistence ==


Line 78: Line 89:


=== Pros ===
=== Pros ===
*
* Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".


=== Cons ===
=== Cons ===
* As in the previous section, LL's objectives could be met without the browser logging in via the same mechanism.
* As in the previous section, LL's objectives could be met without the browser logging in via the same mechanism.
* Inconvenient for those with alts
* Inconvenient for those with alts or multiple clients
** Cumbersome to change alts and logon with multiple alts
** Cumbersome to change alts and logon with multiple alts
** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
* Inconvenient for those with multiple clients
** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes
* Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.
* Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.
* Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld
* Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld
* starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.
* this would make things harder for independent grids to use the official client, and have impact on the architecture discussions for a future open grid.


=== Alternatives ===
=== Alternatives ===
* Is this really needed?
=== Other issues ===
* Is this kind of persistence desirable ''for the client''? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".
<br/>
<br/>
<br/>
== Misc ==
* this should be an option for those who have increased security needs, users should be able to make their own risk/convenience decisions
* the feature especially forces those into an extra login step, who use an official viewer (homebrews will most likely quickly implement a way around this for convenience)
* starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.
* this would make things harder for independent grids to use the official client. Is this considered an advantage or a disadvantage by LL?
<br/>
<br/>
<br/>


== Signatories ==
== Signatories ==

Revision as of 01:43, 30 September 2007

This is a formal critique of Viewer Authentication that was requested by User:Rob Linden on the SLDev mailing list.

For a branch of the discussion see Talk page on the original proposal.

Summary

The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem.

There are no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response or due to allowing weak passwords.

Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method.

There seems to be no demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.

It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.

Security

LL's Objectives

  • To mitigate the danger of password capturing Trojans masquerading as third party viewers
  • Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.

Pros

  • Viewer does not have to process (and "see") username and password

Cons

  • The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.
    • Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).
    • NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.
  • But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.


  • Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!
    • Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
      • This kind of attack is not theoretical, phishing websites are a criminal industry.
      • It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer
    • Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns
    • Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
  • So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.


  • And the mechanism itself is relatively inflexible.
    • Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program
    • Links to secondlife:// can not pass parameters to the program
      • In fact allowing that was a security flaw recently found and fixed in the SL client. :(
    • It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.


  • Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
    • The issues raised in the next sections would mean that people would have an incentive to use this kind of client.

Alternatives

  • One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)
  • lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)
  • separate passwords for website account and being inworld
  • Account restrictions
  • Allow third party plug-ins in the viewere (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)
  • This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.
    • CRAM-MD5 or a similar challenge-response type
    • Dictionary check to reject insecure passwords

Flexibility

LL's Objectives

  • Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems
  • Extension of this to allow non-LL applications and web sites to participate in this single sign on system.

Pros

  • Enables username/password authentication to work on third party sites without them having to "see" username and password

Cons

  • This is really an unrelated issue...
    • The client doesn't need to depend on the website for this purpose, or this could be a command line option.
    • The client could just as easily be the 'authentication source' as the website.
      • Via a "go to website" link in the client that passed an equivalent token.


  • As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes

Alternatives

  • Use this mechanism for websites (including third party) only but not for viewers
  • Identity Metasystem - [1]
    • OpenID - [2]
    • CardSpace - [3]
    • Shibboleth - [4]
    • CAS - [5]
      • These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [6]) not for security

Persistence

LL's Objectives

  • To integrate the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.

Pros

  • Is this really needed or desirable (for the client)? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".

Cons

  • As in the previous section, LL's objectives could be met without the browser logging in via the same mechanism.
  • Inconvenient for those with alts or multiple clients
    • Cumbersome to change alts and logon with multiple alts
    • Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
    • As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes
  • Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.
  • Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld
  • starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.
  • this would make things harder for independent grids to use the official client, and have impact on the architecture discussions for a future open grid.

Alternatives

Signatories

Please sign this below with "~~~~" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with.

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Viewer_Authentication_Critique&oldid=33791"