Difference between revisions of "Viewer Authentication Critique"

From Second Life Wiki
Jump to navigation Jump to search
Line 74: Line 74:
* Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all
* Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all
** Question: how many people have, or even know they have, static or semi static IPs?
** Question: how many people have, or even know they have, static or semi static IPs?
* Lock account if too many consecutive logon requests (to prevent automated dictionary attacks) - a user should be able to unlock an account via the website using additional validation such as CAPTCHA's and providing additional information on file such as date of birth.
<br>
<br>
* 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.
* 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  
** CRAM-MD5 or a similar challenge-response type  
*** Note that the proposed authentication mechanism via a web form might prevent any attempt at implementing a challenge-response mechanism
** Dictionary check to reject insecure passwords
** Dictionary check to reject insecure passwords


Revision as of 04:14, 3 October 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.

Note

It was not explicit what the goals behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and Objectives listed here are what SLDev believe them to be based on the original description and e-mail discussions.

Summary

There are currently 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 in the it would acclimatise users to starting the viewer via a web page. At present most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords, due to security compromises in the LL websites or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).

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. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.

There seems to be no real 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. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client. There is an argument that the seperating the passwords and logon for the forums would actually improve security.

The suggestion of provided an embedded way of displaying the web form within the viewer so that you will not have to always start the viewer from a web browser is a non-starter, not just because of problems with the current code in handling web proxies, but because it would be very easy for the embedded web form handling code to log the form data before POSTing to the web site thus undermining any benefits gained.

Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.

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.
  • To consolidate the authentication implementation in order to support back-end anti-fraud work

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


  • It is suggested that the viewer will embed the web form within the viewer -
    • This escalates the importance of addressing a number of current problems with llmozlib in the current viewer code:
      • there are problems compiling llmozlib on the Linux platform
      • proxies are not supported
    • In any case, a modded client easily log the form data before submitting it to the webform, i.e. all the concerns about clients grabbing passwords would still apply!


  • 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 viewer (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)
  • For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)
  • Do nothing, keep everything as it is.
    • Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers
    • It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises


  • Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)
  • Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all
    • Question: how many people have, or even know they have, static or semi static IPs?
  • Lock account if too many consecutive logon requests (to prevent automated dictionary attacks) - a user should be able to unlock an account via the website using additional validation such as CAPTCHA's and providing additional information on file such as date of birth.


  • 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
      • Note that the proposed authentication mechanism via a web form might prevent any attempt at implementing a challenge-response mechanism
    • 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 synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.

Pros

  • Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different

Cons

  • As in the previous section, LL's objectives could be met without the viewer 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 have an impact on the architecture discussions for a future open grid.

Alternatives

  • As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).
  • 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".
  • There is an argument that the forum logon should be seperated from the SL account logon
    • This would fit the practice of those using alts, when they only use one account on the forums but would need to check the account details of various alts.
    • Having seperate passwords would isolate security compromises in the forums software from compromising the SL account itself.

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=34253"