Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Cave-o-sapien]

Have the sparkly graphics been complained about adequately here or on the MF forums?

Because man, they're awful. The visual cue that something has changed shouldn't obscure what has actually changed.

I hate to keep comparing this to Isotropic, but a few lines of a text log >>> sparkly graphics for conveying information quickly and accurately.

They have been complained about since the start of the closed beta. (and they have improved since then, but are still annoying)  I am pretty sure they know it needs to be changed.

Ok, thanks. I tried poking around on the Making Fun forums but there were way too many threads and sub-forums to parse.

[Darth Vader]

Oh, I see you all found the plans to my new weapon of mass destruction: Making Fun's Beta.

...What did you expect, another Death Star? That's stupid, why would I build another one?

[Kirian]

Oh, I see you all found the plans to my new weapon of mass destruction: Making Fun's Beta.

...What did you expect, another Death Star? That's stupid, why would I build another one?

Dude, even the second one was a bad idea.

[Darth Vader]

Oh, I see you all found the plans to my new weapon of mass destruction: Making Fun's Beta.

...What did you expect, another Death Star? That's stupid, why would I build another one?

Dude, even the second one was a bad idea.

Using plans from a bunch of bugs on a dusty planet 40 years prior was also a bad idea. But it was more a bad writing idea, just like the second Death Star. Wait a second... it is almost like all of these movies are unified by one single bad writer, whether or not he was saved from incompetence from others or not. I'll leave it as an exercise to the reader who this person is.

[pacovf]

Mmmm... Is it       Moat         ?

[werothegreat]

Oh, I see you all found the plans to my new weapon of mass destruction: Making Fun's Beta.

...What did you expect, another Death Star? That's stupid, why would I build another one?

Dude, even the second one was a bad idea.

Using plans from a bunch of bugs on a dusty planet 40 years prior was also a bad idea. But it was more a bad writing idea, just like the second Death Star. Wait a second... it is almost like all of these movies are unified by one single bad writer, whether or not he was saved from incompetence from others or not. I'll leave it as an exercise to the reader who this person is.

The plan was sound - the Death Star functioned as promised.  It was Tarkin's arrogance and overconfidence that did you in.

[Kirian]

Mmmm... Is it       Moat         ?

Nope, it's Joseph Campbell.

[Darth Vader]

The plan was sound - the Death Star functioned as promised.  It was Tarkin's arrogance and overconfidence that did you in.

I guess you could say escape was not his plan.

[werothegreat]

The plan was sound - the Death Star functioned as promised.  It was Tarkin's arrogance and overconfidence that did you in.

I guess you could say escape was not his plan.

"Evacuate?  In our moment of triumph?  I think you overestimate their chances!"

[rspeer]

This new game mode on MF where you only see the backs of the cards must be how you train to use the Force.

[Darth Vader]

This new game mode on MF where you only see the backs of the cards must be how you train to use the Force.

Yeah, and since I killed pretty much all the Jedi, I'll win every game!

[Schneau]

This new game mode on MF where you only see the backs of the cards must be how you train to use the Forge.

FTFY

[DavidTheDavid]

Re: the password discussion:
I've seen contrary opinions on the password thing as I've followed this thread off and on. There's an outstanding ticket on this issue. The passwords are not being sent between server and client in plain text, and if someone's machine is compromised, it would seem that you're hosed regardless.

Granted, that's not my field, and my code skills don't go further than rudimentary html and css. Can someone summarize why the above is wrong, or how concerns persist despite the above so that I can add that to the ticket on this issue?

[Cave-o-sapien]

Re: the password discussion:
I've seen contrary opinions on the password thing as I've followed this thread off and on. There's an outstanding ticket on this issue. The passwords are not being sent between server and client in plain text, and if someone's machine is compromised, it would seem that you're hosed regardless.

Granted, that's not my field, and my code skills don't go further than rudimentary html and css. Can someone summarize why the above is wrong, or how concerns persist despite the above so that I can add that to the ticket on this issue?

I think there are two related issues here:

1) The Windows application requires write permissions on C:\Program Files and writes the logs (which contain the password info) there. Logs should be written to the AppData folder for the user running the application.

2) I'm not sure I see a good reason to write the username and password to the logs at this point. What is the situation where that is needed?

[DavidTheDavid]

Re: the password discussion:
I've seen contrary opinions on the password thing as I've followed this thread off and on. There's an outstanding ticket on this issue. The passwords are not being sent between server and client in plain text, and if someone's machine is compromised, it would seem that you're hosed regardless.

Granted, that's not my field, and my code skills don't go further than rudimentary html and css. Can someone summarize why the above is wrong, or how concerns persist despite the above so that I can add that to the ticket on this issue?

I think there are two related issues here:

1) The Windows application requires write permissions on C:\Program Files and writes the logs (which contain the password info) there. Logs should be written to the AppData folder for the user running the application.

2) I'm not sure I see a good reason to write the username and password to the logs at this point. What is the situation where that is needed?

Does item 1 pose an elevated risk somehow?

Anything else from anyone?

[LastFootnote]

I agree with Cave-o-sapien.

[Drab Emordnilap]

I think there are two related issues here:

1) The Windows application requires write permissions on C:\Program Files and writes the logs (which contain the password info) there. Logs should be written to the AppData folder for the user running the application.

2) I'm not sure I see a good reason to write the username and password to the logs at this point. What is the situation where that is needed?

Does item 1 pose an elevated risk somehow?

Anything else from anyone?

I'm not an expert, but the AppData folder is kind of a best practices thing, right? Like, it'd bother most people if the logs were saved to your desktop, right? Saving them to the Program Files folder isn't much better.

[DavidTheDavid]

I think there are two related issues here:

1) The Windows application requires write permissions on C:\Program Files and writes the logs (which contain the password info) there. Logs should be written to the AppData folder for the user running the application.

2) I'm not sure I see a good reason to write the username and password to the logs at this point. What is the situation where that is needed?

I went through the least few pages and included on the ticket different password posts that seemed representative.


Does item 1 pose an elevated risk somehow?

Anything else from anyone?

I'm not an expert, but the AppData folder is kind of a best practices thing, right? Like, it'd bother most people if the logs were saved to your desktop, right? Saving them to the Program Files folder isn't much better.

[Seprix]

My computer still runs like it's fueled via a coal furnace whenever I play this game, and it never goes off like this in any other sort of activity I do on my computer.

[SCSN]

Re: the password discussion:
I've seen contrary opinions on the password thing as I've followed this thread off and on. There's an outstanding ticket on this issue. The passwords are not being sent between server and client in plain text, and if someone's machine is compromised, it would seem that you're hosed regardless.

Granted, that's not my field, and my code skills don't go further than rudimentary html and css. Can someone summarize why the above is wrong, or how concerns persist despite the above so that I can add that to the ticket on this issue?

I think there are two related issues here:

1) The Windows application requires write permissions on C:\Program Files and writes the logs (which contain the password info) there. Logs should be written to the AppData folder for the user running the application.

2) I'm not sure I see a good reason to write the username and password to the logs at this point. What is the situation where that is needed?

Does item 1 pose an elevated risk somehow?

Anything else from anyone?

Yes it does for different people using the same computer, e.g. underage siblings living in the same household (depending on the age, these are the absolute last ones you want to know your passwords).

And I assume that if the game crashes in some unexpected, not easily reproducible fashion, you guys are interested in taking a look at the log, and you shouldn't have access to those passwords either.

[AdamH]

The passwords are not being sent between server and client in plain text, and if someone's machine is compromised, it would seem that you're hosed regardless.

There seems to be an assumption made here that if someone can read a file on your computer, that your "machine is compromised" and you're totally screwed and it's not MF's problem. I don't understand where this assumption comes from, especially because it's not true. People put dots over passwords as they're being typed in because someone can be looking over your shoulder as you type, why can't you obfuscate passwords that are stored on the file system? Even if someone's "machine is compromised" why would you make it easier to find passwords when you could just XOR it with something, or hash it? Really, you should always, always, always, 100% of the time, without ANY exceptions, hash passwords before you store them. There is no reason whatsoever to not do this.

And that's the really concerning part for me. You expect me to download and run an executable on my computer. If we have to tell your developers to hash passwords before they're stored, then how much do they know about security? Or development in general? Systems have to be designed with security in mind or else they're going to be vulnerable -- how can I know that the same guy who stores passwords in plain text in the Program Files folder can write an application that won't give the bad guys Local Privilege Escalation on my computer? Let alone implement a communications protocol that can play Dominion without the integrity of the game being compromised.

Let me be clear, I'm not touching this application again until I can be reasonably sure that it's secure (and there are very few people that want your app to succeed more than me, seriously). Storing passwords in plain text is not secure. You can wave your hands at it as much as you want and say it's not a big deal, but now you just look silly waving your hands and saying wrong things. It's not hard to change this, why isn't it being changed? Ugh.

[philosophyguy]

Storing passwords in plain text is not secure. You can wave your hands at it as much as you want and say it's not a big deal, but now you just look silly waving your hands and saying wrong things. It's not hard to change this, why isn't it being changed? Ugh.

I want to emphasize Adam's point here. Security is really tough, and there are a lot of subtle ways that applications can have security holes. Never storing plain-text passwords is arguably the most uncontroversial, fundamental, and non-negotiable security best practice. If Making Fun's attitude towards passwords is "meh, not a real issue," then I have very little trust that you are taking security seriously on other issues that I am not smart enough, or deep enough in the code base, to find. Frankly, this attitude is the kind of cowboy coding I expect out of high school kids. It's beyond unacceptable for professionals. If computer programming were a licensed activity, this is the kind of thing that would get your license pulled by the accrediting organization. It really is that bad, and if you don't understand why, then you need to hire a security consultant yesterday in order to make sure your code is safe.

[theory]

Wait, is the criticism that they are storing plaintext passwords on your computer, or plaintext passwords on your server?  The latter is completely unacceptable.  The former, which by my cursory reading appears to be the case, was considered acceptable even by Google as of fairly recently: https://news.ycombinator.com/item?id=6166731  There's a not-unreasonable argument to be made that encrypting locally stored passwords is mostly security theater.

[Seprix]

If the plaintext on your computer is compromised by a virus or trojan, couldn't that have been prevented by simply encrypting your password? I don't know the first thing about security, so I don't know much.

[Drab Emordnilap]

Wait, is the criticism that they are storing plaintext passwords on your computer, or plaintext passwords on your server?  The latter is completely unacceptable.  The former, which by my cursory reading appears to be the case, was considered acceptable even by Google as of fairly recently: https://news.ycombinator.com/item?id=6166731  There's a not-unreasonable argument to be made that encrypting locally stored passwords is mostly security theater.

The former is the issue at hand.