[sldev] [Viewer Auth] Office hour high points.

[David Kaprielian (Sabin)]

At Zero's office hours yesterday, we discussed a number of issues 
surrounding scripted commerce, the safety of tying authentication into 
the viewer, and alternative approaches like challenge-repsonse.  Listed 
below is a brief summary of what was discussed.  You can read the full 
transcript here: 
http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2007_Oct_16 
Thank you to all who could join and help out!

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.

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.

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.