Follow us on Twitter!
Never in the field of human conflict was so much owed by so many to so few. - Winston Churchill
Friday, April 25, 2014
Navigation
Home
HellBoundHackers Main:
HellBoundHackers Find:
HellBoundHackers Information:
Learn
Communicate
Submit
Shop
Challenges
HellBoundHackers Exploit:
HellBoundHackers Programming:
HellBoundHackers Think:
HellBoundHackers Track:
HellBoundHackers Patch:
HellBoundHackers Other:
HellBoundHackers Need Help?
Other
Members Online
Total Online: 15
Guests Online: 13
Members Online: 2

Registered Members: 82909
Newest Member: awais
Latest Articles

Uncrackable Encryption?

Arrow Image A description/proof of concept to make cracking near impossible.



I know, I know, no encryption is uncrackable. But this one is going to be harder than any to crack. I spent several hours thinking of ways to make it harder for us to crack into a website. It would be harder even if we had access to the bakups.

The concept is, stack encryption algorithms on top of each other, forming them into one, causing one encryption that will take decades to crack even if it is a 3 letter password.

SHA-1 is 160 bit encryption.
MD5 is 128 bit encryption.

For now, MD5 is most used, but easiest to crack.

Heres the code for the index.php or html, whichever you prefer:

<form name=\"form\" action=\"login.php\" method=\"post\">
First Name:
<input type=\"text\" name=\"firstname\">
<br>
Password
<input value=\"hidden\" type=\"password\" name=\"password\">
<br>
<input type=\"submit\" value=\"Submit\">
</form>
You see it uses the post method for those looking over your shoulder at your URL.

Heres the login.php:

<?php
$name=$_POST[\'firstname\'];
$pass=$_POST[\'password\'];
$file=\"login.php\";
$hash1=sha1(\"$name\");
$hash2=sha1(\"$pass\");
$hash3=sha1_file(\"login.php\");
$encrypt=md5(sha1(\"$hash1.$hash2.$hash3\"));
echo \"hash is: $encrypt\";
?>

You see it starts by getting the user and pass.
It then uses SHA-1 to hash the user and password separately.
It then creates a hash of the login.php.
After all these hashes have been generated, it then uses them as salts on top of each other to double dutch them

into an MD5 hash.

Lets calculate that:
2 beginning sets of SHA-1
Thats 360 bits
add the digital checksum of the login.php
540 bits

take that 540 times another 180 bits
97,200 bits times the 128 bit encryption of MD5
12,441,600 bits TOTAL.

Thats a lot of bits. Even the NSA wouldn\'t be able to crack that without a few decades work. I would have to say

it would be illegal in a lot of the world but it will be damn secure ;)

Say someone got your backups. The hash they get is double dutched with MD5 on top, they would have to wait for

it to crack- showing an SHA-1 hash. They begin cracking the SHA-1 hash. OH LOOK! 3 more SHA hashes to crack.

As we all know, brute forcing a password over 6 characters is a pain. try brute forcing that double dutch

rendering the MD5 into 40 characters. That in turn is 120 char + a couple of periods. The login.php hash will

have a lot of char in it if someone doesn\'t know which is which. the username can have alot of char, if the

person is smart, the pass will be at least 8 characters.

What do you all think?

Bl4ckC4t

Comments

The_Cellon November 02 2006 - 16:52:36
Correct me if I'm wrong but aren't hashes unique only up to a certain amount of digits? This way a hash of a 500 word string could be the same of the hash of a 4 digit string..
wolfmankurdon November 02 2006 - 18:35:22
Erm, gut instint here but wouldn't piling hashs on top of each other increase incidence of collisions? let me work it out and ill get back to you
wolfmankurdon November 02 2006 - 18:38:55
Okay say you can only have 100 posible hashs, so you have 100 results, you hash them and some of them may hash to the same thing, so say you know have 50 possibilities, but if you hash them you may end up with some of he ones you droped earlier (they hash to the same thing) and you end up with less hashs, pressumably it will eventually end up with 0 hashs and so infinate collisions, im not sure if this is 100% true maybe it platues at some point
JohnDoeon November 02 2006 - 18:48:30
It would be INSANE to brute it... BUT the collision algorithm would perform even better than it usually does because u stacked alot of encryption ontop of each other.
bl4ckc4ton November 03 2006 - 00:05:24
Yea, I didnt take into account the collision possibility. Although, the collisions wouldnt be as bad (i believe) if you changed the double dutch to go into SHA-1 over MD5. It would probably cut the collision rate in half. Bl4ckC4t
Arto_8000on November 03 2006 - 00:49:21
For the algorythme I don't think using sha1_file is a good idea. Imagine you change just a caracter in this file and all your hash can't no longer be used except if you have a backup of that file ... For the method in itself i think using random salt for each password is way much better in security, except if someone find where you stock your salt for the password.
bl4ckc4ton November 03 2006 - 02:01:20
Your encrypting the login page. Not very many people change the login page, its the least risk for screwing it up.
The_Cellon November 03 2006 - 11:34:35
I would also like to add that it doesn't matter how much you encrypt it when your code is exposed. It's not that hard to write a brute forcer for double dutch or something similar.
Zarrayon November 09 2006 - 19:57:31
There is a uncrackable encryption Smile its called randomized one time pad. But the cons are that it requires a unique key and a key with an equal length to the tobecipherd text. google it Smile
err0r33on November 09 2006 - 21:08:57
Wippi! That rocked (: Thanks dude.
err0r33on November 09 2006 - 21:09:12
Wippi! That rocked (: Thanks dude.
revolt0163on March 01 2007 - 13:17:41
Zarray: "There is a uncrackable encryption its called randomized one time pad. But the cons are that it requires a unique key and a key with an equal length to the tobecipherd text. google it" yes but it'd be useless for this, since the key would need to be transfered over the internet, and someone could probably be able to see it (the key has to remain a secret obviously).
j4m32on December 19 2010 - 23:28:33
@revolt0163 : Not necessarily, in the case of a server side script demonstrated (PHP), just store it server side since the client doesn't need to decode it, no "transfer" across the internet is required for that. Store the cyphertext in a session or a cookie... the key can be kept pretty much private. If you were one time padding the request data: yes this would be the case.
cdmafhsson May 10 2011 - 22:11:16
1) You mean, sha1(x) is less secure than sha1(sha1(s))? 2) By first applying sha1 you compress the input and therefor reduce the entropy. Then, you reduce is further by using md5 (128 bit). 3) As already said, your salt is too static Wink
ic0nson May 30 2011 - 14:14:21
this encryption is barely better than normal sha1, u got it wrong with Kerckhoffs's Principle. Imagine the Attacker knows your Cryptosystem. The attacker uses the same method you use to check if the password ist correct after the login. The Username ist public, and the hash of the loginscript is public so the only left unknown parameter is the password, u bruteforce the password using your formula for verification , ... , profit
Post Comment

Sorry.

You must have completed the challenge Basic 1 and have 100 points or more, to be able to post.