[Poll]: Password Protection for Quests

I vote for option 1, if people can access the quests anyway, and our conceit is that we just do what other modding communities do about theft when that happens, then let's not waste the staff's development time protecting it. The only real benefit to keeping it seems to be that it will require the few who would try to dig a little harder than they would have to in other modding communities. I don't personally think that's enough to offset the downsides.

I'm in favor of removing passwords. As of now, they serve no purpose other than creating a false sense of security. Programs to bypass password exists, as you mentioned. I know of at least two and I'm sure there are more. Anybody who wants to open a quest can, so all the password system do is create the illusion that, by putting a password on your quest, it's safe and cannot be opened. Therefore, it serves no real purpose, and removing it would actually aid in the future development of ZC by allowing an easier release of the source code. In light of all this, I see no reason for keeping password protection around, and vote to have it removed.

I'm also in favor of removing passwords. The only positive purpose I see them serving is encouraging that people actually play the quest by giving the password out at the end, but there's no way to enforce that. If passwords are getting in the way of open source, by all means do away with them. I'd also like to see some way to get scripts out of a quest that imported files instead of putting it all in the buffer. I like importing stuff instead of keeping it in the buffer, but I also like letting people look at and reuse my scripts if they have the patience to try and port them.

I may be in the favor of removing it, but it could be re-done, and a converter tool could be made or something- if needed.
Although, that really would probably be pretty pointless. No matter what is done, someone would probably break it.

And if the encryption code isn't ridiculous, and random, someone could just use ollydbg to reverse it.
Here is a (terrible) example of a ridiculous attempt to keep hackers at bay.

void Encrypt1(char a) { // DooM inspired encryption
((((a)&1)<<2)+(((a)&2)>>1)+(((a)&4)<<5)+(((a)&8)<<2)+
(((a)&16)>>3)+(((a)&32)<<1)+(((a)&64)>>3)+(((a)&128)>>3));
}
void Encrypt2(char a) {
((((a)&1)<<1)+(((a)&2)>>6)+(((a)&4)<<5)+(((a)&8)<<2)+
(((a)&16)>>2)+(((a)&32)<<6)+(((a)&64)>>3)+(((a)&128)>>7));
}

// Filled with random BS that is further encrypted (to reduce hackability).
char key[15] = {Encrypt1(0xCA), Encrypt2(0x3d), Encrypt2(0x0e), ...}

for (i = 0; i < data.len; ++i) { // Encrypt the file or whatever
if (i&1 || i&6) {
key[i^2] = Encrypt1((i<<1)+(i>>1));
fileData[i] ^= passData[i+key[((i^32)&15)]+Encrypt1(i<<1)];
} else {
key[i] = Encrypt2((i<<1)^(i>>1));
fileData[i] ^= Encrypt2(passData[i+key[((i^32)&15)]+Encrypt1(i<<1)]);
}
}

[ANOTHER EDIT]
This is a fine example of why I dislike this kind of stuff. It's cludgy, and boring, often has loopholes, and it's just a mess.
No matter how you do encryption on this kind of project, there is usually a way to break it (reversing, memory editing, etc).
If it's open source that just makes it that much more of a pain. So...

Okay there is some misinformation in this thread. The idea that we have to remove passwords to release the source is silly. Encryption can stay in. Yes someone can simply fork the code to bypass it, just as they can fork the code anyway, just like they can write a [really] simple script to overwrite password hashes. But for most people the main branch will still be just as password protected as it is now.

The AGN staff never agreed on any position on this topic. AGN staff and ZC Devs agreed that the community was not okay with releasing the code as is and that we should do whatever we can to protect quest encryption(an idea that has always been a catch 22). I have always supported releasing the code as is. Quest protection has never been secure and it has always been a bare minimum deterrent. If passwords were gone it would hardly change a thing, except maybe more people fixing bugs on their own to keep playing. Passwords can stay just stop pretending we are doing any service by removing the encryption code and delaying development. They will continue to serve bare minimum deterrent.

Just about any idea for reworking quest protection has been discussed and rule as easily bypass-able. The only thing that would be an improvement would be to make quests self contained games completely changing how the software(and community sharing) works.

I support the source being released as is(encryption code and all).

That would probably be fine and dandy, but really, the encryption stuff could be compiled int a DLL at the very least (so others can't see it).

_Mitch wrote:That would probably be fine and dandy, but really, the encryption stuff could be compiled int a DLL at the very least (so others can't see it).

Doesn't matter. It will still be easily bypassed. So it really doesn't make a difference.

I guess that depends on what you mean. But I've never seen the encryption code so I don't know.

Unless the encryption is just plain stupid, I would imaging that it would make a little bit of a difference.
If the encrypting source is available all someone would have to do is search and find it, then they would know how it works.
If the encryption code is all pre-compiled into a binary, then you would have to reverse that binary to see how the encryption works.
It's a lot harder to decompile than it is to read C or C++ code.

Then again, someone could just patch ZQ and make it skip password authentication all together.
But that depends on how it is implemented, so I guess I'm clueless here. 0.o

[EDIT] I actually voted to remove the protection. Although I don't really know how much sway this vote has!

_Mitch wrote:I guess that depends on what you mean. But I've never seen the encryption code so I don't know.

Unless the encryption is just plain stupid, I would imaging that it would make a little bit of a difference.
If the encrypting source is available all someone would have to do is search and find it, then they would know how it works.
If the encryption code is all pre-compiled into a binary, then you would have to reverse that binary to see how the encryption works.
It's a lot harder to decompile than it is to read C or C++ code.

Then again, someone could just patch ZQ and make it skip password authentication all together.
But that depends on how it is implemented, so I guess I'm clueless here. 0.o

You are missing the point. It is irrelevant HOW the "encryption" works. The quest still has to be played, which means bypassing the "encryption", which means it can be easily bypassed for any purpose. I am not talking about encryption in general. The issue is how ZC works.

Any option to create more true security is simply much more work for little gain AKA a waste of time.

The lure of ZC was never its passwords anyway. At most, it was probably an added bonus.

Yeah, it would probably be a waste of time, but that's something I find myself doing a lot (like right now)... I have a feeling my post was kinda misunderstood.
I'm sorta assuming there is no "bypassing" the encryption; the file is decoded before the data is actually read (that's usually the point of encryption).

If the decoding code is compiled, how would anyone get to see it? Obviously the encryption isn't that good (I have seen quite a few exploits for it myself).
Also, anyone could just use ollydbg and either dump the memory after loading the map, or patch ZQ so it skips the password altogether (with the current version, it's 5 bytes I have heard).

Although it doesn't matter how one would get in there, it's doable, and not very hard.
So yeah, I agree, it's probably best just to remove all of it, and label the password bytes in a quest as "obsolete" or "deprecated" password bytes.
But it's definitely not my decision how the password stuff is going to be handled anyways.

Honestly, I think ZC/ZQ would have probably been better off with it not implemented in the first place, unfortunately. :\

_Mitch wrote:Yeah, it would probably be a waste of time, but that's something I find myself doing a lot (like right now)... I have a feeling my post was kinda misunderstood.
I'm sorta assuming there is no "bypassing" the encryption; the file is decoded before the data is actually read (that's usually the point of encryption).

If the decoding code is compiled, how would anyone get to see it? Obviously the encryption isn't that good (I have seen quite a few exploits for it myself).
Also, anyone could just use ollydbg and either dump the memory after loading the map, or patch ZQ so it skips the password altogether (with the current version, it's 5 bytes I have heard).

Although it doesn't matter how one would get in there, it's doable, and not very hard.
So yeah, I agree, it's probably best just to remove all of it, and label the password bytes in a quest as "obsolete" or "deprecated" password bytes.
But it's definitely not my decision how the password stuff is going to be handled anyways.

You are still missing the obvious problem. If you encrypt all the data how will the quest player read it? Let's say you separate ZQ files and ZC files, one for developing and the other for playing. ZQ files could be encoded with whatever password you want and ZC files could have a common password for ZC decoding. No bypassing! Sound perfect? Well let's forget for a second that we have completely redone quest files and loading (a great deal of effort and time). How much effort do you think it will take to find out the common code? Or better yet let ZC do the decrypting and grab the unencrypted data?

We could do this all week long, but there is one simple fact that makes it all moot. Our less than secure passwords have worked for 15 years and they will work even after Open Source. Hell, they used to be stored in plain text.

merchant says just release as is will yeah encryption and all that jazz.

Why would they have been stored in plain text! How unoptimized. 0.o
I get what you are saying, and I'm not disagreeing, it's just, I would have thought it would have used something a little more complex than just a single encryption key.
I'm more into randomized encryption. Where the randomization seed is calculated through some sort of hashing procedure.
Still, whatever- passwords were kinda useless anyways, and it'd probably be better without them...

I'm in favour of removing the password functionality and right now is a good time to decide such a major item of interest. Currently you can easily access and edit password protected quests made with Zelda Classic 2.50 through to 1.90 without issue, so the existing quests are already pretty much naked and if you were to improve quest encryption... the old copies of quests and Zquest will still float around the internet.

So yeah, either you do your darnedest to crack down on this and update all quests in the 2 quest databases and remove old copies of zquest and such or you just drop the issue and simply remove quest passwording. The latter doesn't run in to the issue of people hoarding old copies and websites maintaining old copies of stuff etc.

And making Zelda Classic Open Source will expose the inner workings of the password system, unless you exclude the code for it in the source code and try to maintain a separate branch or the program with it implemented but not publicly accessible and then people will probably favour the version that lacks DRM, maybe.

If everyone unanimously decided that they don't really care if the code for the passwords is made available or not, then it would be a bit simpler by virtue of not having different versions of ZC to have to manage. However, pretty much everyone would need to be on board with this, including the active community at purezc, not just the 10 people that voted so far.

Also just pointing out that you can't really remove passwords from ZC since they will always be needed to load older quests, but I get that "remove passwords" is not meant literally. Even if no one really cared about them anymore they would still stick around and you could still password quests, because ZC was just designed that way.

The real problem, is the community perception of how 'safe' their content is, using the existing system. User John believes that by setting quest, and cheat passwords, he is doing something meaningful, and doesn't realise that it takes all of five seconds to bypass it, as it stands. Thus, they stand up on a soap box, and rant against removing this feature. I doubt there are many people here, on AGN, that we need to convince, but rather, the PZC crowd, is the bigger culprit. I suggested the library module as a quick-and-dirty way to skirt the issue, not as a valid method of security. If a user wants special levels of security, and encryption, clearly they would need to devise their own module for it; and the terms of GPL take a somewhat dim view on that, in general.

If all forward-changes to a source set, must be made available, a security method, would also need to be made available. A randomly generated key file, would therefore be the most secure, but it's something that users of the open-source code should be making, not the present project leaders, who rightfully feel that all of this is just a sheer waste of time. I concur. I suggested making the encryption itself, a module, that allows one of three inputs: User-defined, precompiled lib (using the stock method), or, best of all, none.

The real question, is whether the community at large can grow beyond the need for this false sense of protection. :banghead:

Honestly, if the core devs opened up to the PZC community how the idea of not releasing the password and encryption routines as part of the source, was crippling future development, the perception of it would change in favour actual progress. I do not believe that the point has ever been nailed in to the heads of all the members, that this is more than simple logistics issue, and that it is indeed stalling exactly what they've wanted for years.

Hell, a developer strike would shake things up too. :gavel:

Really though, the core devs posting a clear, concise, and explanatory topic on PZC may do the trick.

I'm on board with removing it. I never really saw the point to the password system, anyway, when it's so easy to bypass.

CaRmAgE wrote:I'm on board with removing it. I never really saw the point to the password system, anyway, when it's so easy to bypass.

It gives me the right to dox someone so that I can go to their house and break their fucking shins with their arm after breaking it off for breaking into my quest by the International Law of GoFuckYourself.

*tips edgy fedora*

Gleeok wrote: However, pretty much everyone would need to be on board with this, including the active community at purezc, not just the 10 people that voted so far.

That seems like a pointless requirement when you yourself have stated how insignificant it would be to remove it and the decision to remove it in the first place was decided by a similarly small group of people.

SUCCESSOR wrote:That seems like a pointless requirement when you yourself have stated how insignificant it would be to remove it and the decision to remove it in the first place was decided by a similarly small group of people.

I'm not sure I'm understanding you here.

What I was basically saying is that if the ZC community would rather have a true open source development environment for ZC rather than keeping the idea that encryption is a big enough deal where it is preferred to keep it hidden, then I am totally on board with that. (I'm actually in favor of it for various reasons.) Last time it was brought up there was some resistance to the idea. At the end of the day I basically just do what the people want.

I'm pretty sure none of the other current devs would have any problems with this either. I suppose this might be becoming more of a "who's the goose" goose hunt.

At the end of the day I basically just do what the people want.

And that's the way the cookie crumbles.
Unfortunately dev's don't get to make all the choices (it's the consumers mostly).

BTW, no need for politics; we are all friends (or at least mutually beneficial acquaintances with similar views)- just say what comes to mind.

Gleeok wrote:I'm not sure I'm understanding you here.

What I was basically saying is that if the ZC community would rather have a true open source development environment for ZC rather than keeping the idea that encryption is a big enough deal where it is preferred to keep it hidden, then I am totally on board with that. (I'm actually in favor of it for various reasons.) Last time it was brought up there was some resistance to the idea. At the end of the day I basically just do what the people want.

I'm pretty sure none of the other current devs would have any problems with this either. I suppose this might be becoming more of a "who's the goose" goose hunt.

I am not saying I have a problem with the encryption code being removed. As I have always said I support the code being released as soon as possible. Last time you talked about this you said you don't really want to do the work of removing the encryption when someone will simply add in a way to bypass it anyway. I have never seen a point in making more work for Devs when keeping the encryption stuff in would only make it slighty easier for someone to bypass. There are tools to bypass the passwords already anyway and you cannot use the code to acquire someone's password. If a branch of ZC that bypasses passwords were made it would still be considered the same as the tools that remove passwords and wouldn't be allowed here at AGN or at PureZC so it wouldn't be much different than what's already been released.

The longer the Open Source release is delayed the longer the people who want to contribute are delayed from learning ZC code and learning how to contribute. There are several users who have expressed such interest who I haven't seen active in a long time. Like I said I just want the code out there for people to learn and possibly contribute to. If removing the encryption code will work out in a timely matter go for it. If it is a hindrance that's holding up the release then I'd rather it just stay in despite what members of AGN or PureZC may feel on the subject. Open Source release is long overdue. I'd rather keep the interest of potential developers than worry over current users getting butthurt over passwords.

Oh right, I get you. Obviously I agree, since I do sporadically complain about how dumb the whole thing is. ..In fact, I'm pretty sure my random complaining is what prompted this thread to begin with. :P

...Yep... >_>

[MENTION=42714]Gleeok[/MENTION]
I agree with gleeok this whole thing is pretty dumb.

you need to realise something everyone your quest are not protected its an illusion.

I understand why people want to protect their quests using passwords--they don't want people to be able to cheat. Really, what's the point of taking the time to make your chest challenging and cryptic if people are just going to activate cheats and cake walk through the whole thing? But there are ways around the password protection so those who are set on cheating will still do so.

I will admit that I do use some cheats when available. Mainly, I use the H key to restore my health when it starts beeping. Apart from that, I don't do much (except once when I was in a room where I needed bait and had yet to find a shop that had any for sale). I think the cheat system was put in place for those who wanted to test out their quests. But removing the cheats once your quest is finished doesn't make a difference if someone can just load it up in ZQ and add cheat codes. And the password feature does not act as the deterrent it should because people can get around it.

I suppose, in lieu of passwords, there could be an option to save a read-only copy of your quest file. That way ZC could open it, but ZQ couldn't at all.

Chris Miller wrote:I suppose, in lieu of passwords, there could be an option to save a read-only copy of your quest file. That way ZC could open it, but ZQ couldn't at all.

Encryption in ZQUEST and decryption in Zelda Classic (The quest player)?. Of course if the Zelda Classic project was open sourced than the decryptor would be spoiled and someone will definitely make a Zquest with the decryptor built-in.

Also, why should cheating be prohibited? Yes some idiots will use them to discover everything immediately and spoil puzzle solutions and stuff for everyone else (Or try to) but other than that (Likely temp bannable forum offense)? I don't see why there should be a restriction placed on how a player approaches a quest. Old NES, SNES etc. games had cheats readily available in them and it didn't spell the end of gaming lol.