Difference between revisions of "Viewer Authentication Critique"
Jump to navigation
Jump to search
Rob Linden (talk | contribs) (+CAS) |
(various bullets) |
||
| Line 1: | Line 1: | ||
This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list. | This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list. | ||
For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.] | |||
== Security == | == Security == | ||
| Line 10: | Line 12: | ||
** Silently buy L$ and pass onto another account | ** Silently buy L$ and pass onto another account | ||
** Pass token onto bot, and drop the users connection | ** Pass token onto bot, and drop the users connection | ||
** Install key logger | ** Install key logger to monitor the next website login | ||
* 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. | ||
* 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) | ||
* Too reliant on browser/OS implementations | * Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.) | ||
* Relies on browser security, and uses a mechanism often disabled due to security concerns | * Relies on browser security, and uses a mechanism often disabled due to security concerns | ||
* 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 | |||
=== Alternatives === | === Alternatives === | ||
* One time passwords | * 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.) | ||
* Account restrictions | * 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 | |||
* CRAM-MD5 or a similar challenge-response type | * CRAM-MD5 or a similar challenge-response type | ||
* Dictionary check to reject insecure passwords | * Dictionary check to reject insecure passwords | ||
| Line 46: | Line 53: | ||
* Inconvenient for those with multiple clients | * Inconvenient for those with multiple clients | ||
* 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 | |||
=== Alternatives === | === Alternatives === | ||
* Is this really needed? | * Is this really needed? | ||
== 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. | |||
== Signatories == | == Signatories == | ||
Revision as of 12:19, 29 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.
Security
Pros
- Viewer does not have to process (and "see") username and password
Cons
- Viewer still involves running trusted code on the computer and could initiate other attacks e.g.
- Silently buy L$ and pass onto another account
- Pass token onto bot, and drop the users connection
- Install key logger to monitor the next website login
- Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
- 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)
- Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
- Relies on browser security, and uses a mechanism often disabled due to security concerns
- 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
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
- CRAM-MD5 or a similar challenge-response type
- Dictionary check to reject insecure passwords
Flexibility
Pros
- Enables username/password authentication to work on third party sites without them having to "see" username and password
Cons
Alternatives
- Use this mechanism for websites (including third party) only but not for viewers
- Identity Metasystem - [1]
Persistence
Pros
Cons
- Inconvenient for those with 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
- Inconvenient for those with multiple clients
- 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
Alternatives
- Is this really needed?
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.
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.
- Matthew Dowd 11:27, 29 September 2007 (PDT)