[sldev] [Viewer Auth] Office hour high points.
matthew.dowd at hotmail.co.uk
Tue Oct 23 02:38:15 PDT 2007
> 1) Can I ensure that my build of the viewer / my scripted commerice AV / > my bot can log in w/o reading HTML> i.e: do I need to have human eyeballs to log in? Short answer - at > least once!> > The issue is this: there may come a time where we may want to make > logging into your Second Life account somewhat smarter. It may, under > certain circumstances, take more than just your name and passsword to > get in, and for this we need a single code path that can be very very > flexible.> There are many, many ideas as to how we can implement additional account > security. However, all of these ideas mean that login may become more > complicated than a simple firstname/lastname/password format. Our goal > in revamping the viewer authentication is to make it so there is only > ONE code path that handles login so that we never have two ways of > logging in that may have different strategies or requirements. To do > this in a flexible manner, it should be done over web and HTML.
Firstly this is confusing having a single code path (which means having a single backend webservice for authentication via both the viewer and the web) with having a single UI which is really what doing things over HTML gives you. You can still have a single codepath and yet have multiple UIs.
You will, in anycase still need to support multiple UIs, you have built the client so that all the text strings are in resource files so that you can have multiple translations of the client, and indeed there is work going on elsewhere within LL to eliminate any remaining hardcoded strings to improve this. You will therefore need to support multiple HTML logon pages for each of the languages! As the many of the translations are being done by third party efforts you'll also need a way for those people to contribute to translations of the HTML login form. If you intende to start adding smarter mechanisms to authentication than username and password (which someone may be able use without being able to read the text), you will certainly need to translate the form into different languages!
The HTML form approach gives you the flexibility to change the logon process on the fly without requiring a client download - in practice, it would be unlikely you could make much use of this. Any unnanounced change to the logon process is liable to cause confustion and outrage amongst your users - people do not take kindly to unexpected changes in how they access things. Moreover, any unannounce change will upset those developing third party clients which don't use the HTML form to logon (either because they log on automatically, or are designed to text based or other non-graphical/low-graphical environments) - do you really want to alienate the open source community?
Psychologically, having to download a new client for changes in the logon UI would be better for both LL (it reduces the temptation of making a quick unnannounced change with the repercussions mentioned above) and for users (who expect changes when downloading a new client). Moreover having a single backend API for authentication rather than mixing the API with the UI as the proposal does, is more in keeping with the aspirations of the Archtecture Working Group activities.
Many of the "smarter" authentication mechanisms mentioned in the office transcript as being "enabled" by this approach, actually will not be. Neither voice recognition or other biometric methods can be acheived via a HTML form - when these *are* used over the web, these are done via embedded ActiveX, Java Applets or pre-installed plugins. I'm pretty sure that the embedded browser in the SL Viewer does not support ActiveX or java Applets, and I think it highly desirable that the embedded browser continues not to do so! As such supporting these would require additional code to the viewer, and would probably result in the viewer using a different HTML webform from the website authentication! Likewise, private certificate or key chain authentication, would require additional UI in the viewer for handling private certificate stores etc.
As mentioned on the wiki page for suggested questions - could what LL what to achieve be done by having a soft lock on an account which is activated by suspicious activities (such as failed logons etc). When an account is soft locked a logon via the viewer is rejected, but the user can go to their account pages on the web and release the soft lock (using additional authentication means such as captchas etc.)?
> 2) Isn't the web just less safe than the viewer?> > Web is not any less secure. The web has many vulnerabilities but is > tested and used by millions each day, whereas the SL viewer's login > vulnerabilities are not known and only used by thousands of people. > We're requiring the use of SSL for logins to make it more secure.> Also remember that we have an in-viewer login screen so logging from the > website is opt-in security.
It is the security of HTTPS and SSL which is tested and used everyday by millions, and this would be used by both the proposed webform approach and a webservice API approach. The backend code for handling a HTML webform will be used and tested by precisely the same number of people (i.e. thousands) as the backend code for handling a webservice API, and it is of course here that vulnerabilities would lie.
Any additional security by using a web browser tested by millions a day is of course lost by allowing the use of embedded browser code in the viewer which is used by merely thousands!
Finally, as many have said you SHOULD NOT implement a means to start a logged on viewer from a logged on web session. Not EVER! If users become used to this you increase the likelihood of phishing scams being successful. There have already been attempts to replicate the SL Website account page - see http://forums.secondlife.com/showthread.php?t=217613 for one found last week (but now taken down).
If people get used to logging on via the website, not only will this cause confusion and extra support headaches when people install multiple clients (as you are encouraging them to do via firstlook and release candidates), but you increase the risk of people being caught out by phishing e-mails of the form "You have received a message within secondlife, please click here to logon and receive you message".
> 3) Why ignore industry best practices like challenge-reponse?> > Challenge-response is only used to make sure a secret doesn't cross the > network unencrypted. Since we're using an SSL connection to pass the > token, it stays encrypted in transit. Challenge-response also requires > the user has an engine to compute the response, and we prefer using > standard web technology for this.
No - challenge-response is not only used to make sure a secret doesn't cross the network unencrypted but that the secret is not transmitted to the server either. Take the recent exploit whereby a URL on a webpage could result in the authentication going to a thirdparty server. Had you been using challenge response, this would not have been an issue as the thirdparty webserver would never have received any information during the attempted authentication which could have been used to compromise the account.
MD5-Challenge Response is a well established mechanism for this with well established implementations used world wide by millions of users including millions of web users, so is no less secure than any other standard web technology.
The next generation of MSN Hotmail has arrived - Windows Live Hotmail
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SLDev