Possible change in logging on to SL

Let us assume you are correct, that the proposed system introduced no new risks (I'll come back to this).

The system offers the benefit that it hides the password from the client. What protection does this actually provide. I don't think that there is anything I can achieve knowing your username and password, which couldn't be achieved by clever coding in a rogue client without it knowing your username and password with the possible exception of masquerading as you in the forums, jira or support system.

So the benefit is actually quite low.

So what is the cost - well it makes life difficult for those running multiple clients, it breaks a lot of the current future architectures discussion for supporting third party sims etc. it makes life difficult for those using the client on existing third party sims using OpenSIM, it will involve additional development time for both Linden developers and OpenSource developers. It adds additional testing, QA time, a risk the initial rollout will introduce bugs etc.

Does the cost warrant the benefit?

(the answer itself is not as important as making sure the question is properly considered!)

Re the risks - these are on the wiki but I'll outline two:

i) because the client cannot get your password you'll be lulled into a false sense of security that you are protected against third party clients. Someone earlier in this thread (I think it was you) hinted that client could not steal passwords that would enable someone to get at your credit card details or steal land. However, I don't need your credit card details to steal - I just write a client which secretly buys L$ (charging your card on file) and syphons them to an alt. As regards land theft - well I write a client which every time you teleport (or logon), it scans the sim for any land you have permissions to sell, silently sets them for sale to my thief-bot alt, sends an IM to said theif-bot who comes and buys the land.

ii) if people get used to logging onto SL via a website, it opens up whole new phishing possibilities e.g. e-mails of the form "You have received a xxx in SL. Please click here to logon" which take you to a fake mockup of the official SL logon page which steals your password.

Matthew

Nopey, all are forgable (or at least mutable).

That this was even proposed shows a lack of understanding that authentication is a combined technological and social system and you can't improve one side in order to fix the other side.

More bluntly: the security proposal is fundamentally, inherently impossible and Proposer Linden should have known that. That he didn't ought disqualify him from working on it.

This is more than disturbing. If it's actually the case that there exists some user interface that results in cleartext passwords on the wire that's a *critical* defect. (Personally, I'd label it a showstopper, and the application and website should be taken down until corrected, and new passwords required when service is restored.) Is there a jira on this?? Does the viewer also send the password unencrypted--no salt, no nothing?? (Sorry to be so lazy--I'm just not up for delving into the source at the moment to discover the answer myself.)

Say it ain't so.

the difference is that if thief has usernames and passwds thief can set them aside for future use. and when thief does choose to use them it will not be so obvious that they were gained via thiefs rogue client.
now otoh, if a rogue client was discovered to be doing things such as setting land for sale and so on it would take only a matter of hours for word to get around. grabbed passes? it might take weeks for people to put 2 and 2 together, and even then it would be called 'guesswork' and 'hypothosis'

i can login and logout five alts into the website faster than i can log two alts into the clients. my browser stores both usernames and passwds. my client only stores passes.
i'll conceed on the geeky opensim stuff as i know sfa about it.
qa time? i didnt realise there was such a thing
secretly buying L$ is a problem, yes. but it is a risk no matter what the login method. i personally use land-holding groups, and the groups are owned by alts. nina can buy for group and deed to group, but cannot sell land. i realise that this isnt a typical setup though, so i suppose it can be counted as a risk. but it is a risk no matter what the login method.

i believe it is yahoo that uses a custom watermark feature for login pages. ll could implement something like that to minimise the phishing risks.

bear in mind it is not my intent to offer ironclad proposals. im simply bouncing ideas.

The password is sent over encrypted and it is the encrypted form that the server validates against. Although it is not possible to decrypt the form sent over the wire to the original password, the problem with the current approach is if the encrypted form is sniffed, the encrypted form can be used to authenticate with the server!


Hence one of the things being suggested in the critique is to change this to use a challenge response mechanism so that the password is never actually sent over the wire.

To understand how this would work, lets use a very simple example with numeric passwords.

My password is 321.

The server sends a challenge which is a random number e.g. 536

The client sends back the addition of this number plus my password i.e. 867

The server compares the response with what it thinks my password is plus the number it sent.

OK, in practice the maths is much more complex!

Matthew

Are you refering to CAPTCHAs? i.e. a graphic containing text which you have to type in? If so that is to prevent automated logons (and potentially dictionary attacks on user accounts) rather than to prevent phishing.

Matthew

Sorry, I was referring to when you have multiple versions of the client installed such as the main client, the release candidate client, the first look client, the beta client, the Nicholaz client, the Donzatas client, a client you've just compiled yourself etc.

Some of us - especially those working on code submissions will have more than one version of the client installed - although having all of the above is excessive.

The proposal is that you log on with the website and it launches the client - but in the case you have multiple ones installed which one will it run? Will it actually run the one you wanted to run?

In the first iteration the answer is that you will not easily be able to chose without directly editing the confguration for how your browser handles the secondelife:// protocol handler!

There is talk that this will only be temporary whilst a better solution comes along - the cynical might comment that lack of URLs in the forums is only temporary

Matthew

no, it is a graphic/watermark that you create, it is then shown near every legit login form on the site.

surely someone would whip up a righ-click context menu for that, similar to 'open with...'

I have to say that seeing this in the wiki discussion, combined with the "Gee whiz! Let's do SSO, where do I put that group of bits" tone of the original posting to the dev list, really set off alarm bells for me. It is as if LL thinks it should re-invent all the security lore of the last 15 years. None of this is rocket science, but I think that if you try to just jump into a unified security scheme for as diverse an offering as SL will eventually be, you'll end up spending a lot of time reinventing the wheel.

Rather than anyone spending time talking about things like encription methodology, I would be happier if your first goal, Matthew, was to get broad agreement on the detailed requirements for a security design. I'm still unclear on what exactly LL INTENDs to accomplish, because the suggested solutions don't really seem to match up with the stated requirements. Then hand that requirements list to an ASP security professional (LL's pals at IBM used to have quite an array of them, don't know about now), lay out a coherent approach and get back to us when done! I realize that LL is under the gun to get all partnered up with 3rd parties, and to own the grid-grid interworking standard. But there is only one way to get a good design. Agree on requirements (I think a lack of agreement underlies the discussion here), and THEN design. Not the other way around.

I just did a packet trace on my SL client (well actually Nicholaz's client) showing it clearly does use SSL for the authentication exchange. As for the forums <=> agni.secondlife <=> my account page password equivalences I don't know.

I am no longer testing as a change on the (https) My Account page caused me to be locked out of the forums for a 15 minute "wrong password" holddown. I've now changed my forum password which seems to also be my "My Account" password, and I have no frigging idea what my client password is but it is working now and I'm done messing with it on a weekend where I'm certain to get no support at all.

Nina, sorry you read my lost antecedent as meaning that your proposal was anything. I meant that Rob Linden's proposal is bollocks, and still do.

Cool, I iz in ur account stealin ur lindenz!

I agree - we (by which I mean the open source submitter community) aren't sure either.

My best attempt was to split the critique into what I think their three intentions were:

security - and we feel implementing *existing* challenge response algorithms e.g. MD5-CRAM would be better investment of time than trying to hide password from clients.

flexibility - which I think means SSO - so we've listed some exisitng SSO technologies and hinted this needs a lot more discussion

persistence - which is synchronising forum and SL logins basically, which no one yet has given a good reason why they would want it.

This is partly to prompt the Lindens into articulating *what* they want to achieve as the original wiki page mixes implementation, design and intent!

Matthew

While I deeply appreciate the effort that folks are putting into getting the Lindens to get their shit together, isn't the exact opposite of the direction software requirements specification is supposed to happen?

Because it is too easy to be exposed to this sort of thing. From the LL Blog:

I think forcefully matching the website login to the viewer login is an awful, ridiculous idea.

However, since you're so desperate for a pro . One positive (if one of little pratical use and in some cases it would actually be contrary to the user's wishes) aspect would be that it increases consistency when the viewer launches the browser instead of presenting the information in-world.

I.e.: if your main is logged on to the site, and your alt is logged on in-world and you wish to check your transaction history = you'd see the transaction history for the wrong account. If the two were inherently linked, you'd always see the transaction history (or whatever section of the site really) for the proper account.

The exploit was actually entirely LL's fault because they weren't validating untrusted input and had nothing to do with IE.

What does this imply for being on the forums on one computer and inword on another, like I am most all the time I'm inworld?

Would we still be able to be logged in to the forums on two machines at once?

Like to know when this will take effect?

I often run two clients at the same time to adjust poses and check permissions.. This does not sound like I can do that any longer. I know a lot of builders/animators that do this.. Are we all just screwed now?

No, it just means more keystrokes and requires interaction with the website. See Matthew's post #68 in this thread for how it would work.

Or we can each wait for our favorite 3rd party client to evade this altogether. As Matthew says, ironic. So the net effect would be to drive more people to use 3rd party clients. Oh, and also to put bots even further from the security umbrella than they already are.

It won't affect this. It will affect those using multiple clients or logging in as multiple alts from the same computer.

Matthew

Dunno - hopefully never.

Matthew

I had Netscape and IE on my computer I got from Dell. I do not use either, but instead use Opera (I can resize the pictures and text a lot more easily on Opera; everything looks very tiny on the other web browsers).

I use IE7. I think it's fine. Call me stupid.