Password change?

err theres no email feild for the loby, so even if someone was to steal your pasword i am uncertain what they could do with it...

Still, why does the ZKL not care about it? I really don't know a single other application that would show the password to everyone. I've come across plaintext saving, but only with warnings! The key problem here is that at the moment of chosing the password, the player doesn't know that his password is not securely saved.

@[V]ddabaeqepp: Surely my ingame name is nowhere to be found in other games. No google search will ever return information about me. I'm completely anonymous by using a gamer tag, right? /sarcasm

And if i care about the password being visible, i apparently care about other people reading it. If those people obtained access to my PC (and plan malicious things), they'll no doubt find my email (or other crucial access stuff) before the lobby. Even if it's friends or so, i still like being the only one to know my passwords. Nobody will ever care if somebody screwed you up because of a leaked password.

Not even speaking of trojans or whatever other crap you might happen to come across in and around the internet.


But yes, i'd like to change my password. Should i contact the admins in the lobby or is there some sort of PM feature i'm missing?

A lot of the best open-source project have small close-source sections around user security. Would it really be a bad idea to close off the password protection code?

Still, password stored as plaintext in an easily visible area is a hopelessly low bar for security. Any completely-ignorant-of-cryptography noob can steal your account that way (even if such people are likely underrepresented among the people who'd compromise your account for malicious purposes).

Yeah guys, thats hilarious.
You store passwords as plain text, but pass them to springrts:8200 as hashes. Thats completly wrong. The only place when you need hashes - is database, you need to pass them as plain text in packets and use packet encryption for the whole protocol(tls for example)
But who cares...

Indeed, protocol was made by amateurs some time ago. It's all wrong and provides no actual security. But we cannot change it easilly now.

@MauranKilom yes, MD5 of password in itself provides no good security, most can be insta broken using rainbow tables.

I plan to add symmetrical encryption of password to ZKL .. its rather trivial change if you want to do it feel free to help.

In PC there is basically just one way to provide at least decent security - RSA and other assymetrical encryptions. Best with hardware chip which stores private key and performs actual encryption.

Any software form of "remember my password" means huge compromise of security and means password cna be retrieved trivially (even if its not in human readable form it is in machine readable form..)

quote: Zero-K is open source. Any security we would add (like symmetrical encryption) is false one because anyone could simply look at code or slightly modify it to read your password back.

Linux is opensource, and so is OpenSSH stack. Evaluating your claim (opensource = insecure) with 'linux' and 'openssh' results in linux and openssh being inherently absolutely insecure. :P

Also there are things like keystores and such.

quote: They are called salts.

Salt is inapplicable on client as such.

quote: To use keystore we would need to use certificates -> we cannot change what we have now.

Maybe that's harder on some platforms than others >.>

You can't protect your account here. Don't even try, but you can cry.

Now that this is said, what you can do is protect spring lobby/zkl/website from compromising your overall security, ie. your other accounts.

So my advice on selecting a password for this totally insecure protocol is:
1) don't use the same password anywhere else (obvious, but useful reminder)
2) don't use the same password generation rules that you use anywhere else (unless you use "pwgen -s" or similar)
3) why not pick a very bad password and have fun with it? its not so often that you can be careless when picking a password (because a strong password wouldn't protect you)

Showing the password in cleartext (instead of bullet/asterisks) is something that should be fixed, even if protocol and website are vulnerable. Maybe there should just be a simple fix that allows zkl to never persist password and request it everytime (when it is started, or when it connects). It won't fix all the protocol/website brokenage, but for some use cases it may help.

RSA doesn't help in any way to help secure storage of the password. Unless you encrypt the secret key and request a password. In which case, symmetric encryption would be just as good. But since you would be asking for a password, why go through that extra hoop and not request the lobby password instead of the password to unlock the lobby password...

quote: err theres no email feild for the loby

The was none.
http://springrts.com/dl/LobbyProtocol/ProtocolDescription.html#REGISTER:client
http://springrts.com/dl/LobbyProtocol/ProtocolDescription.html#CHANGEEMAIL:client

I'm too frightened to check whether clients and server have been updated to handle it. Reading code may be bad for your health.

quote: we cannot make password-changing application

Me not understand.
http://springrts.com/dl/LobbyProtocol/ProtocolDescription.html#CHANGEPASSWORD:client

quote: Saving a salted md5 (or whatever other hash) would be completely sufficient, wouldn't it?

No.
Salt only helps to prevent precomputed/rainbow tables. When properly implemented.

(Salted) md5 is supposedly one-way (stop laughing). Server is expecting an unsalted md5 hash from client. So, saving a salted md5 wouldn't work. Unless you really want to troll and use md5 as an obfuscation mechanism and use rainbow tables lookup to actually reverse the saved password, then hash it again before sending it to server.

You could store the unsalted hash. The real secret is not the password anyway, its the hash itself. So you would be saving the real secret in cleartext. It looks more gibberish, but its still the unencrypted secret, which is the only thing required to login. Actually, we can consider that the "cleartext" password is actually an obfuscated version of the real secret (the hash). So enjoy, there is obfuscation built-in!

Now, if protocol had specified a salt (or salting mechanism), it would have prevented leet haxxors from using publicly available precomputed rainbow tables. Yay.

so who can do this beside yourself @licho ? i hope you have at least one stand-in...