[sldev] [Upcoming Changes] Website Viewer Authentication

[Barney Boomslang]

Hey,

> process.  In other words, residents will not have to type their name and
> password into SL viewers and applications, they'll type them into our
> website instead.  The process that occurs is as follows:
> 1: After logging into the website, you'll be taken to a new page that
> has the same login location options the current SL viewer has.
> 2: When you hit the Go button, a form is submitted to a php page, which
> redirects to a secondlife:/// url that has a web key appended to it.
> 3: The secondlife:/// url itself will launch Second Life with locational
> details and the web key will authorize your account for login.
> Note: You can find more detailed information (the whys and hows) on the
> public wiki at https://wiki.secondlife.com/wiki/Viewer_Authentication

You just decided to make life a big pain for many people.

- those with many alts who like to run them without changing the main
alt on the web site (to look at the web friends list for example -
standard way for me)

- people who use different browsers. The secondlife:// hook can only
start one browser and for example on the Mac it's not easily
changeable which one that is, unless you install additional 3rd party
tools. (multiple browser versions are standard for most ppl doing
their own builds)

- anybody who builds special clients like ajaxlife, sleek, libsl, whatever

and for what benefit? In what way is a website and redirection to a
secondlife:// URI with a login token more secure than just entering
the data in the client itself? The "bad" client will do it's bad
things regardless on how it is started. It doesn't care for the login
and the password, it just waits until you are logged in and then
starts to rob your L$ account or dispense your inventory over the
grid.

Actually embedding the login process into the website and having the
client start automatically due to a security token lowers security -
it adds up a whole new slew of possible attacks, because the simple
login screen of the client wasn't suspectible to XSS attacks and stuff
like that. And if the client automatically logs in without user
intervention, one website hack will empty your virtual pockets.

At least have an intermediate stage where the user has to confirm the
login - remember your recent security problem with regard to that
little browser problem where -autologin was passed to the client? What
you now did is you just reinvented that exploit and made it a feature
...

bye, Barney