Ugh, I hate to spend any amount of time defending MakingFun during this debacle, but having the plaintext password stored on your computer isn't a huge deal. If someone already has access to your computer, they can get all your passwords saved by Chrome/FF/IE anyway. Unless you're master-password protecting those, too, in which case, OK, I get paranoia I suppose, but xkcd exposed that insecurity years ago.
If they're sending the password plaintext insecure, that's a different problem altogether.
That sounds reasonable until you realise that the file in which your password is stored in plain text is the same one you would send to MF to report a crash.
And while we all know that it's thoroughly retarded to re-use login details between different services, the reality is that people are lazy and that I just changed my PayPal password.
For this reason, I use different passwords for all my major web activities, which includes anything with money on the line or information about my identity. I know people who use a password management application with a master password, but I never got around to trying that.
On top of this, storing a password in plain text anywhere is completely indefensible. It's not, there's no argument here. That's appallingly insecure. I don't have anything to add, honestly - it's that simple.
I would caution against overreacting here. Have you ever saved a password in your web browser? That's plain text.
Yeah browser saved passwords are plain text last I heard. That's kind of appalling in itself, and so I don't have my browsers remember any of my passwords. But even there, at least none of the browser saved passwords ever get sent across the server. They just populate your password fields before you submit forms, right? The major danger with browser saved passwords is people using your physical machine while you're not looking.
Now I'm no security expert either, but I'm interested in the topic and may even pursue a master in information security in the near future. Does anyone know how Unity apps communicate with the server? If it's some sort of SSH connection then sending unencrypted information like passwords is bad but not a catastrophe, so long as password information is still hashed server-side.
Normal web apps use TCP/UDP protocols or whatever, whose packets can be observed quite easily by outsiders. For this reason, it's extremely important that all sensitive information be encrypted or hashed before even being sent to the server. Given the need to obfuscation the password at some point client side anyway, a normal web app (like Dominion Online V1.0) has no business to not perform the obfuscation step of the sensitive information being sent to the server before doing anything else with that information.
So it all comes down to whether or not the password is sent to the server in plain text. We can't conclusively say it does just from the log. It it doesn't, then one possibility is that the client side log is being completely generated client side with only client side input (which would mean the log is limited to non-server side issues). Another possibility is that the client receives the errors from the server and then the client side finishes writing the log. This second possibility is quite nonsensical to me as the client application can just save the obfuscated password to the log at that point and cannot send the log report back to the client with the plain text password without resulting in a security breach.
Like SCSN, I'm very skeptical about this plain text password revelation as it appears in a log file. It even logs errors, right? That's something of value to the server-side administration.
You know, I was out of the loop on the whole open beta thing, only finding out about it about 2 hours ago. Man, I was even having trouble downloading the thing. It seemed like it was freezing up my network connection on my computer, and failed to download anyway. Now I read through this thread and well these failings of Dominion Online are amusing at this point.