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

Dale Glass dale at daleglass.net
Fri Oct 19 04:33:22 PDT 2007


On Wed, Oct 17, 2007 at 05:17:22PM -0700, David Kaprielian (Sabin) wrote:
> 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!
Darn, missed it.

> 
> 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!
So what does this mean? A captcha to login? I can't imagine that sort of
thing being welcome.

> 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.
I must disagree here. The web is THE insecure service. How many
paypal/bank/etc phishing mails did you get this month? I got a few dozen
at the very least.

The viewer isn't vulnerable to this at all in the current setting when
normally launched by the user. (excluding DNS cache poisoning I guess)

By simply using SSL and verifying the certificate used by the server you
can make the standard viewer refuse to talk to any non-LL auth server.


> 
> 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.
The problem is that it seems it's been implemented half way. Encryption
solves part of the problem. Verifying that the auth server is good fixes
the remaining issue: that the viewer will happily hand out your
cleartext password to whatever server it connects to.


Note that I'm talking about the standard LL viewer here, but third party
viewers don't really matter. In the current situation if you let a third
party viewer login at all you're already implicitly trusting it. That it
might get your password is about the last thing to worry about.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071019/afdf6662/attachment.pgp


More information about the SLDev mailing list