PDA

View Full Version : The New Security Encryption...



Zelda Master
12-28-2005, 10:56 AM
Is Impossible to break.

here is what i mean:[note this was tested on MY OWN passworded quest]

http://img517.imageshack.us/img517/4929/examppassword1jz.png

That encryption stops the password hacking of quests...

Great job Developers!:D :thumbsup:

Dark Nation
12-28-2005, 11:15 AM
Well, it's a one-way encryption. It's can't be undone.

For instance, one example of a one-way encryption (for a number) would be to add all the digits together. So, 21 would encrypt to 3. 47 would encrypt to 11. However, there's no way to go back by just looking at the encrypted version. 11 could have been 47, 812, 90101, etc. Granted, the encryption scheme is a lot more complicated than this, but you ge the point.

Snarwin
12-30-2005, 01:01 AM
Ooh, assymetric encryption. Nice.

If anyone is interested, you can find an article here. (http://en.wikipedia.org/wiki/Public_key_encryption)

koopa
12-30-2005, 05:27 AM
More like a hash function (link) (http://en.wikipedia.org/wiki/Cryptographic_hash_function) I'd guess.


* Preimage resistant (See one way for a related but slightly different property): given h it should be hard to find any m such that h = hash(m).
* Second preimage resistant: given an input m1, it should be hard to find another input, m2 (not equal to m1) such that hash(m1) = hash(m2).
* Collision-resistant: it should be hard to find two different messages m1 and m2 such that hash(m1) = hash(m2). Because of the birthday paradox, this means the hash function output must be at least twice as large as what is required for preimage-resistance.


The first means in plain English "if you look at the file you can't figure out the password".

ShadowTiger
12-30-2005, 12:09 PM
The question is, though, do the developers still have the ability to unlock a quest should the need arise?


They Who Use The Force For Good...

...

:p

jman2050
12-30-2005, 12:25 PM
The question is, though, do the developers still have the ability to unlock a quest should the need arise?


They Who Use The Force For Good...

...

:p

Yes

Questwizard88
12-30-2005, 01:52 PM
Also, I noticed that the challenge hash seems to be the exact same for some quests, so could that possibly be a potential security risk if someone requests a backdoor password for a quest that is not theirs, or could that actually be a bug of some sort?

Dark Nation
12-30-2005, 02:55 PM
which quests?

koopa
01-02-2006, 04:08 AM
Yes

Do the developers have access to our actual passwords or just the ability to unlock quests?

Gerudo
01-02-2006, 11:57 AM
judging from BH4's question, it's the ability to unlock quests.

i'm with QW on this one, this could potentially open the floodgates to people requesting quest passwords to quests that they did not make/create.

jman2050
01-02-2006, 01:08 PM
judging from BH4's question, it's the ability to unlock quests.

i'm with QW on this one, this could potentially open the floodgates to people requesting quest passwords to quests that they did not make/create.

We're not stupid. Nevertheless, the concern is sound. Idiots usually make themselves known well before they succeed in their retarded endeavors, so I'm confident whatever problems may arise will be handled in the correct fashion.

Cloral
01-02-2006, 01:57 PM
Better that than no way to get back a quest where you forgot the password.

Questwizard88
01-06-2006, 07:48 PM
which quests?sorry this took so long, but i found several that showed a hash of 1315bd77d206cbea1b2ab63adda13c1d:

1st.qst (ZC2.11B6)
Zelda-TheRevenge2.qst
altadd.qst
HiddenDualityDC.qst


Also, I made a set of three little test quests, each with one of these passwords:
440197663, theelricbrothers, and &#(@(%.
All returned the same hash as the quests above, 1315bd77d206cbea1b2ab63adda13c1d. Upon entering the correct passwords for each of the 3 test quests, I was told I had an incorrect password on all of them. I even proceeded to try entering each of the 3 passwords on each quest, and none of them worked.

Something doesn't seem right here, since it shouldn't be returning the exact same hash for almost every file I try to open. Its also odd that I got rejected on all three of my test quests, even with the correct passwords, yet 2.10's example_bs1st let me right in.

ZeldaLord
02-05-2006, 06:41 PM
I have the same problem, ALL quests give me the same challenge hash.


Well, it's a one-way encryption. It's can't be undone.

For instance, one example of a one-way encryption (for a number) would be to add all the digits together. So, 21 would encrypt to 3. 47 would encrypt to 11. However, there's no way to go back by just looking at the encrypted version. 11 could have been 47, 812, 90101, etc. Granted, the encryption scheme is a lot more complicated than this, but you ge the point.

Forgive my lack of knowledge in this area, but how exactly does the program check the password you input is correct? If all it's got to check it against is an encrypted password that can't be recovered, how does it ensure that the input is correct?
Taking your example, if the user's password is 2357, which encrypts to 17 (which is the only number stored in the file), how does the program know, when the same user comes to open the file, that the password is 2357, when all it's got to check the input against is 17, which 1466 or 108306 would also work with that?

Nicholas Steel
02-06-2006, 01:44 AM
because it will encrypt your input and then compare it to the password thus meaning...

when the user enters the password 2357, it gets encrypted to 17 (which is the only number stored in the file)

when entering the code to access the file it encrypts it and compares the encrypted number to the encrypted number protecting the quest file.

ZeldaLord
02-06-2006, 03:37 AM
In which case, that means that ANYTHING that adds up to 17 will register as correct. In other words, you might as well not have any encryption at all, as it would be easy for anyone to reverse it.

Nicholas Steel
02-06-2006, 03:59 AM
well how do you find out what equals 17?

Dark Nation
02-06-2006, 09:47 AM
Let me explain it a little better. MD5 is a lot more complicated than simply adding the digits together. It uses several checks and encryptions to come up with the hash value. So, a better comparison would be something like this...

The first 2 digits of the hash are the sum of all of the digits of the number. If the sum is more than 2 digits, add all of the digits of the sum together. If there are still more than 2 digits, keep repeating the process until only 2 digits remain. If there are less than 2 digits, put a 0 in front.

The next 2 digits are the sum of the first half of the digits of the original number. If there are an odd number of digits, the first half gets the extra digit. Do the sum calculation (like above) on the result until only 2 digits remain.

The next 2 digits are the sum of the second half of the digits of the original number. If there are an odd number of digits, the first half gets the extra digit. Do the sum calculation (like above) on the result until only 2 digits remain.

The next 2 digits are the sum of the first half of the digits of the number minus the sum of the second half. If there are an odd number of digits, the first half will have the extra digit. If you end up with a negative number, make it positive. If there are more than 2 digits after the subtraction, do the sum calculation (like above) until you get 2 digits.

The last 2 digits is the difference of the second 2 digits and the third 2 digits. If this is negative, make it positive.

This will give you a 10-digit hash.

So, let's try the number 93859030285676829344956824053.

The sum of the digits is 9+3+8+5+9+0+3+0+2+8+5+6+7+6+8+2+9+3+4+4+9+5+6+8+2+ 4+0+5+3, which is 143. This is more than 2 digits, so you add those together. 1+4+3=8. Make this 2 digits and you get 08. That's the first 2 digits.

The second 2 digits is the sum of the first half of the digits of the original number. There are 29 digits, so you use the first 15. 9+3+8+5+9+0+3+0+2+8+5+6+7+6+8=79.

The third 2 digits is the sum of the second half of the digits of the number. 2+9+3+4+4+9+5+6+8+2+4+0+5+3=64.

This fourth 2 digits is the difference of the first half of the digits of the number and the last half of the digits of the number with the valus summed together as before. 938590302856768-29344956824053=909245346032715. 9+0+9+2+4+5+3+4+6+0+3+2+7+1+5=60.

The 5th 2 digits is the difference of the second and third pair of digits of the hash value. 79-64=15.

So, the 10-digit hash value of 93859030285676829344956824053 is 0879646015. Now, see if you can find any other number that has that exact same hash value. An MD5 hash value is 48-digits long (actually, it's 16-characters, but a character translates into a 3-digit ASCII value) and it uses much more complex calculations.

On a side note: I found out what was wrong with the challenge hash system and it has been fixed in the latest beta.

Nicholas Steel
02-06-2006, 08:45 PM
thanks dn!

koopa
02-07-2006, 02:52 PM
So, the 10-digit hash value of 93859030285676829344956824053 is 0879646015. Now, see if you can find any other number that has that exact same hash value.


OK, how about 946786532175556746777532252511 ?
Let's see .. length, 30 digits.
sum of digits ... 143. Gives 08.
sum of first 15 ... 79.
sum of other 15 ... 64
Difference of halves ...


946786532175556
-746777532252511
================
200008999923054

sum of digits in that ... 60

difference of 79 and 64 ... about 15. Same hash?

On a similar note,
986786532979266487562495. Same again.

Dark Nation
02-07-2006, 03:34 PM
As I said, that was only an example. Just a bit harder to crack than a simple add of all the digits. MD5 is a lot more complicated. For instance, I've just gotten the MD5 hash for a 10-digit number. The hash is f9a98eb0f435c4c34a4dcd393731d971. Can anyone tell me the original number or, in fact, any string (number, sequence of numbers and/or letters, etc.) that has the same hash?

I've also been thinking about RSA encryption. It is considered harder to crack than MD5 but it's also 2-way, so, no challenge hash would be needed. However, since ZQuest would be able to decrypt the original password, I'd need to secure the decryption routine so that the private key wasn't readable to someone filtering through through the program's memory.

Thoughts?

koopa
02-07-2006, 03:50 PM
You could always use RSA and only include the public key in zquest, that is when someone creates a password it's encrypted and the ciphertext stored in the quest, when you open the quest in zquest you give in the password, it encrypts it, checks that against the stored encrypyted value, pretty much like md5 in a way. The private key would be in the hands of the developers only.

Personally I'd be for using md5 (or sha or similar) as
1) if someone uses a weak password it can be cracked whatever algorithm is used
2) if someone uses a strong password then even md5 isn't trivial to crack
3) let's suppose someone does take the time to disassemble zquest. They'd get the rsa key eventually in your scheme - and everyone's passwords. With a secure hash they'd still have that to crack, moreover there's no "master key" that would give access to all passwords.
4) out of principle, I prefer it if I know my password is not visible to anyone, even developers.

Of course you could use something like triple-md5 with different salt each time. But that, like my arguments, is probably excessively paranoid. After all, it's "only" a computer game.

EDIT: cracked. 7445125644

Dark Nation
02-07-2006, 04:04 PM
Okay. Here's a hash that's not in the MD5 Reverse Lookup Database: 6c72ebd3730722c3144cc86d5a3bd359.

KJAZZ
02-07-2006, 05:47 PM
Wow, that went way over my head. But I think I somewhat understand. Regardless, better encryption is always a good thing. :thumbsup:

Revfan9
02-16-2006, 10:52 PM
Wait, couldn't through an extensive trial and error deal isolate the code from Zquest that checks the password? After all, the assembly is read by hex, so if your like me (you know how to translate between hex and assembly) you can look at it and know what the code does. THerefore being capable of extracting the password checker.

SO this means that a password can be cracked, just not by standard means...

Dark Nation
02-17-2006, 08:58 AM
*Anything* can be cracked. It's just a matter of how difficult it would be.

koopa
02-17-2006, 12:51 PM
Wait, couldn't through an extensive trial and error deal isolate the code from Zquest that checks the password?

There are two ways to answer this question. Dark Nation gave the first, with enough time and effort you can crack any password. You could do this by just guessing and typing each guess, though that would not be the fastest method.

The second answer is that the passwords are md5'ed. That is a one-way hash meaning that if I type koopa as my password, the hash is e29159e59b2284a9dc777c775ae35d93, and this hash - in some form - is what is saved in the quest. When you open the quest, you type in the password, ZC computes the hash of your password, and compares that against the stored hash. If they match, you're let in.
To crack the password, that is if you get hold of my quest file and find the hash and want to find the password, you need to reverse the md5. No disasembling is required - the algorithm is public, described on wikipedia, and the source code is out on the internet anyway. The point is that knowing the algorithm does not mean breaking it is easy.
If you choose a weak password - like koopa - it'll be a matter of seconds to break it. If you choose lltk$21e4u**219tiasp1243@@$9 it might take a bit longer. For instance, I haven't been able to crack the last hash DN posted and I rather think I won't be able to in the near future (next 100 years or so).

So: yes, you can crack all passwords with enough time, but strong ones might take more than the average human's lifetime.