Since when do the devs do resurections on request?

[Blacktooth]

That's a weird suggestion. How would closing the source code make the protocol more secure? (And is there anything wrong with it to begin with, as you seem to imply?) Anyone with a little knowledge of Java could reverse-engineer the class files anyway, and anyone without a little knowledge of Java could reverse-engineer the protocol, and any security protocol that relies on implementation obscurity is a bad idea to begin with.

I wouldn't consider it weird. It is fairly common practice. I suppose you would have to move the client to a compiled language, and move the moddable parts to a built in scriptable language.

I realize it wouldn't be 100% secure obviously, but it would be more secure. I would consider it worth the effort, but your mileage may vary

Perhaps and official repository for the various clients. *shrug*

And last but not least, firm rules on what is acceptable as far as account access goes. What is acceptable, what isn't, and a firm definition of any repercussions.

I don't really have an interest in setting up and maintaining a bureaucracy, though. I'm actually rather inclined to agree with those who say that account security is the owner's own problem. I don't see why I should have to take responsibility for people choosing weak passwords. I also wouldn't want to take away people's freedom in sharing accounts by setting up inflexible rules by administrative fiat.

Fair enough. So, you are going to ignore all future cases? Or take them as they come? In the latter case, what would you do?

Actually, one other thing. Firm definitions of what is and isn't acceptable as far as game mechanics go. As an example, I know wall jumping is difficult to get rid of, but should it be acceptable because of this. I know in most cases scents will be left, and that patches it up somewhat, but what about avoiding scents?

And then what? Enforcing each case of wall-jumping on unclear evidence, after it has been committed? Remunerating the victims? Moderating the game is another of those things that I don't in the least feel like doing. In that case, I'd rather use my time to fix wall-jumping.

Ok, then what about island hearth vaults? Is there not moderation there? Where does the moderation begin, and where does it end?

(It's not my intention to be aprioristically dismissive; I'm just not too fond of those suggestions.)

Yup, cool.

[loftar]

I suppose you would have to move the client to a compiled language, and move the moddable parts to a built in scriptable language.

But... why? What would that accomplish? By what mechanism? Is there anything wrong with the current authentication mechanism as it is?

Fair enough. So, you are going to ignore all future cases?

If it isn't explicitly my fault that an account is stolen, I would be inclined to ignore it by default. Especially so if the case may have some relation to in-game politics (as it turned out to possibly have in this case) -- just because I wrote the game doesn't turn the players into my wards.

Ok, then what about island hearth vaults? Is there not moderation there? Where does the moderation begin, and where does it end?

I know that Jorb takes care of such things every once in a while. It is likely that I would ignore them out of sheer laziness, but since it's Jorb who seem to get all the requests anyway, I have -- thankfully -- not had to decide thus far. I didn't necessarily mean that it is an unbendable principle of mine never to moderate anything; only that I really don't want to. I don't have a policy on the matter, and to be honest, I'm not interested in deciding on one. My hobby is programming, not running bureaucracies. Precisely for that reason, I choose to moderate as little as possible, so as to not set any precedents. If I choose to hear an occassional prayer, I only do so in non-public cases (as I thought this one was), again, to avoid setting a precedent.

That is precisely what I meant by my revenge on ElGato, too: He (willingly or not, I don't know) made me think that the case was completely private, which is a strict requirement for me to intervene, but then it turned out not to be. That's what I meant by taking revenge for having made me read 10 pages of raeg. It would not be wrong if you took that as a precedent. ;)

[ElGato]

Will I give him some sort of special 'Sodom price' because he's some 'special member'? No.

I never implied to anyone that I wanted a discount on anything

He (willingly or not, I don't know) made me think that the case was completely private, which is a strict requirement for me to intervene, but then it turned out not to be.

I honestly did not even think the situation would get this sort of attention. Sorry again for wasting your time.

[Granger]

The largest of these is the open client itself. If it were me, I would find some way of separating the client/server authorization from the moddable parts of the client. Someone with a chip on their shoulder, a little knowledge of Java, and the will to do so could wipe out a lot of hearthlings.

That's a weird suggestion. How would closing the source code make the protocol more secure? (And is there anything wrong with it to begin with, as you seem to imply?) Anyone with a little knowledge of Java could reverse-engineer the class files anyway, and anyone without a little knowledge of Java could reverse-engineer the protocol, and any security protocol that relies on implementation obscurity is a bad idea to begin with.

I havn't looked at the code, but unless you transfer the user/password combination in cleartext (preferably it should be secured by crypting it with public key of auth server) it should do it. Everything else is overkill.

And in case someone thinks that a modded client will or can leak login information: there is an official client, use that.

And last but not least, firm rules on what is acceptable as far as account access goes. What is acceptable, what isn't, and a firm definition of any repercussions.

I don't really have an interest in setting up and maintaining a bureaucracy, though. I'm actually rather inclined to agree with those who say that account security is the owner's own problem. I don't see why I should have to take responsibility for people choosing weak passwords. I also wouldn't want to take away people's freedom in sharing accounts by setting up inflexible rules by administrative fiat.

The simple policy that everything you get by sharing your account login is your problem should do it.

Actually, one other thing. Firm definitions of what is and isn't acceptable as far as game mechanics go. As an example, I know wall jumping is difficult to get rid of, but should it be acceptable because of this. I know in most cases scents will be left, and that patches it up somewhat, but what about avoiding scents?

And then what? Enforcing each case of wall-jumping on unclear evidence, after it has been committed? Remunerating the victims? Moderating the game is another of those things that I don't in the least feel like doing. In that case, I'd rather use my time to fix wall-jumping.

Good plan, keep coding.

I suppose you would have to move the client to a compiled language, and move the moddable parts to a built in scriptable language.

But... why? What would that accomplish? By what mechanism? Is there anything wrong with the current authentication mechanism as it is?

See above.

I read somewhere the claim that password recovery tokens dosn't expire.
Should that be the case then this should be fixed. Password reset tokens should have a limited lifetime, and expire the moment a successfull login is made.

If I choose to hear an occassional prayer, I only do so in non-public cases (as I thought this one was), again, to avoid setting a precedent.

Resurrecting characters should only be thinkable in case they got wasted because of a bug.
The definition of bug is not someone sitting infront of a screen logging into an account with valid credentials (ok, ones not extracted from the server somehow).

That's what I meant by taking revenge for having made me read 10 pages of raeg. It would not be wrong if you took that as a precedent.

FinalDeath for lying to a dev: IMHO a reasonable policy, especially for an alpha version which is provided free of charge.

[DatOneGuy]

Will I give him some sort of special 'Sodom price' because he's some 'special member'? No.

I never implied to anyone that I wanted a discount on anything

I know you didn't, was responding to an earlier post, was posting from my phone so digging it up is a real pita.

[ElGato]

I read somewhere the claim that password recovery tokens dosn't expire.

This is true.

[DatOneGuy]

I read somewhere the claim that password recovery tokens dosn't expire.

This is true.

I wonder if there's a reason for that or if it will be changed

[loftar]

I read somewhere the claim that password recovery tokens dosn't expire.
Should that be the case then this should be fixed. Password reset tokens should have a limited lifetime, and expire the moment a successfull login is made.

This appears to be true. Interesting. I was sure I had limited their lifetime, but apparently not so. It should be fixed now, being limited to 24 hours. I'm not sure if they should expire at successful logins, however, since that could mean that someone in possession of the current password could indefinitely block the legitimate user from changing it.

I havn't looked at the code, but unless you transfer the user/password combination in cleartext

Of course not, indeed. I'm actually quite content with the current authentication protocol. The client itself never looks at the cleartext password at all beyond hashing it with SHA-256, and thus the server never sees cleartext passwords at all (except over HTTP, since that cannot be fixed other than by patching the web browsers themselves). The authentication protocol itself, over which the password hash is transmitted, is TLS-protected (the client only accepting my exact server certificate). The "remember me" function does not save the password itself, nor the password hash, but a randomly generated 16-byte nonce generated by the authentication server on demand (after having authenticated to it otherwise), which is also saved on the server on generation, so that two clients can never store a valid auto-login simultaneously (and so that one can invalidate an auto-login stored on another computer). The authentication protocol is extensible, so I've thought of adding other mechanisms as well, such as TLS client certificate authentication or Yubikey or something. The only thing missing from it, that I can think of, is salting the password hash with the user-name, but the only exploit that would protect against is detecting users with identical passwords given the entire user database, so it's a rather minor issue.

What I know, the mechanism has only two weaknesses:
1) The autohaven.jnlp file contains a clear-text authentication cookie (which expires in 5 minutes), which could be read by sniffing traffic if one downloads autohaven.jnlp without using HTTPS; and
2) The game protocol itself is not encrypted or integrity-protected, and such a session could therefore be hijacked with a man-in-the-middle attack, or spied upon by sniffing traffic.

The simple policy that everything you get by sharing your account login is your problem should do it.

Well, again, I'd rather like to state that account security is the responsibility of the owner, quite simply. I wouldn't want to limit my responsibility only to account sharing.

[burgingham]

Do you really think it is smart to lay the only ways to get your hands on passwords out in the open? Then again I guess someone more inclined to find out about those things than me already knows it?

[loftar]

Do you really think it is smart to lay the only ways to get your hands on passwords out in the open?

What way are you referring to? Sniffing them over non-encrypted HTTP? That isn't exactly trivial to begin with (you'd need control over a router between the victim's computer and the server), and it is also a problem which every website in the world has, so I don't think I'd need to mention it explicitly for any h4xx0r to have thought of it. :)