[Poll]: Password Protection for Quests

[CJC]

If you've been around lately you may have noticed a lot of threads discussing password protection and an open source code release for Zelda Classic and its editor ZQuest.

This poll is to try and collect the raw numbers about passwords and their use in QST files.


Here are the facts:
1.) There IS a program available (somewhere) that lets anyone replace the hash of a password with the hash of a blank in the quest file, allowing anyone to open even protected quests.

2.) All of ZQuest's developers are on board with the removal of the password system, as it will streamline the release of the source code.

3.) There is an exploit that allows users to indirectly edit quests by abusing file names.

4.) AGN staff took the position that password protection was made available and should remain for the benefit of the community. However, due to 1 and 3 above, the only real protection for quests and their content is our connection as a community and our ability to shun users that misappropriate the work of others.


So... please select one of the poll options (if you use ZQuest to make custom games). You may elaborate in a reply if you so choose.


EDIT:

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 was under the impression that we had agreed that password protection would stay as a service to the community (as there was already the expectation that it was there). In the creation of this thread I may have paraphrased some of the issues incorrectly because I don't really understand file encryption, but it was never my intent to misinform anyone.
SUCCESSOR knows what's going on, though, so you should give his words more weight than mine.

[Anarchy_Balsac]

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.

[Russ]

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.

[Moosh]

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.

[_Mitch]

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...

[SUCCESSOR]

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).

[_Mitch]

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).

[SUCCESSOR]

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.

[_Mitch]

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!

[SUCCESSOR]

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.

[Anarchy_Balsac]

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

[_Mitch]

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.

[_Mitch]

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

[SUCCESSOR]

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.

[Tamamo]

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

[_Mitch]

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...

[Nicholas Steel]

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.

[Gleeok]

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.

[ZoriaRPG]

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.

[CaRmAgE]

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.

[Majora]

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*

[SUCCESSOR]

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.

[Gleeok]

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.

[_Mitch]

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.

[SUCCESSOR]

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.

[Gleeok]

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... >_>

http://i.imgur.com/gSmVoiE.png

[Tamamo]

Gleeok
I agree with gleeok this whole thing is pretty dumb.

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

[TheDarkOne]

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.

[Chris Miller]

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.

[Nicholas Steel]

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.

[Tamamo]

Just curious but if people want the encryption gonethat would men addiing a bypasss do to the encryption being stored in the header of old quest before 2.5.2 if this is the case i see no point since it would be done regardlesss if the encryption code is released.

[Isana]

I'm indifferent to the presence of the password protection feature in the sense that I don't think it would be too big of a deal
to release the source code as is. Some people would complain, sure, but I imagine most would get over it.

However, I'm also not necessarily opposed to simply redacting this code from an open source release, but it would be a bit
of a pain to maintain compatibility with existing quests in this case.

Basically, I'm more in favor of releasing the code as is, but I wouldn't complain if the open source release were approached
differently. (≧∇≦)

Side note: Has anything been said about this on PureZC yet? Is their input on this something we need and/or want? (・o・)

[_Mitch]

I agree, some people would probably complain, no matter what is done. I was actually going to post about the politically correct thing to do... But Honestly, I think anyone that complains about this is pretty nutty. It'll be open source, and it's a free project.

These are just my opinions:
I personally think the best option is to remove passwording in future versions of ZQ- making all the old passworded quests openable without any password input. After all, if this project is open source, why have closed/passworded quests anymore. I think it should be more of an educational thing; look at other people's quests and learn stuff.

I don't think anyone really wants passworded quests, and even if the passwording stuff is left in the source, it's not faux protection. Redundant passwords just makes some users, who know about the source, or certain tools able to remove passwords from quests able to edit older quests, while others don't know about it. If the passwording code is left in, even more tools for editing quests will become available, and there will be users who naively think either their quest is safe, or that some other quest can't be opened- while other users are opening the quests.

I'm thinking ZQ could ignore the password in older quests (like it wasn't there), and then you can save them without the password, still, I'm happy however it's done. I'm even happy if support for older quests is completely eliminated, if people want them, they could just use an older version.

Regardless of how this is handled there will be people who say "I'd rather it this way" or "why isn't it like this"; there will be people who think it could have been done better. Also, important to note, most people who use ZQ/ZC are not scientists, hackers, or programmers, and many of them are young kids. Iit would also be nice if ZQ is all inclusive, without the need for 3rd party tools to edit older or passworded quests.

[zaphod77]

There is no way to password protect quests reliably. period.

Bottom line is the player still has to decrypt the quest data, without knowing the password.

because of that, the format can be reverse engineered, and an editor that doesn't respect the password can be created.

Opening the source would make that process easier, but it's already been done.

Ripping can't be stopped with a password. cheating can't be stopped with a password. even if it cold be stopped with a password, there's always Cheat Engine. And quest editing can't be stopped wit ha password, even without open source. its' totally pointless. Best to watermark the graphics/audio such that theft can be proven instead.

[Samer]

Password protection is a farce, first of all, somebody with even the slightest knowledge of cryptography can easily find the password. RSA Encryption, which is one of the highest levels, is also a farce. Someone could easily load up of a memory viewer or disassembler with Visual Studio or anything else with similar capabilities and obtain the password from the memory address (hash) table. Second, no one can make money off quests. You really want to protect it? Get a copyright protection patent, wait you can't because no one owns the intellectual properties of Zelda. In other cases, if you are knowledgeable, since .qst files are essentially structured like ROMs, is to use some kind of extraction program like PeaZip or ISObuster and find the password that way.

The argument for having password "protection" for fan projects is just rubbish.

[smashbro596]

personally passwords was a stupid feature. especially for me who wants to just mess around others quests with no intent on uploading and redistributing them.

[Gleeok]

Started a public thread at pzc about this:

http://www.purezc.net/forums/index.php?showtopic=68524

[Tamamo]

Gleeok
Well if you Zig when your suppose to Zag and Zag when your suppose to Zig your gonna get your Penis caught in your zipper, and nobody wants thats that for you Gleeok. It's a bloody mess.
"Why are we talking about this literately?"