Scratch

If you are using PHP and Panther, you could send something from Panther (a password for instance) to the PHP webpage which turns the string into a hash, then output the result a send the result to Panther.

So:
Panther Project would have:
[Get content from URL: (join "http://yourwebsite.com/md5.php?string=" with "(password)")]

and the PHP webpage (md5.php):

<?php echo md5($_GET['string']); ?>

With a salt, you add it to the string to be hashed as well.

Last edited by Magnie (2012-01-16 09:08:49)

SeptimusHeap wrote:

Magnie wrote:

If you are using PHP and Panther, you could send something from Panther (a password for instance) to the PHP webpage which turns the string into a hash, then output the result a send the result to Panther.

So:
Panther Project would have:
[Get content from URL: (join "http://yourwebsite.com/md5.php?string=" with "(password)")]

and the PHP webpage (md5.php):

Code:

<?php echo md5($_GET['string']); ?>

With a salt, you add it to the string to be hashed as well.

Cool. Could you help host and code the php side of things?

Sorry, no. Long Explanation of why I don't use PHP for these kinds of things.

You could use a little script binded to Scratch's sensor port, with Python or another lanuage. That'd work. (:

blob8108 wrote:

SeptimusHeap wrote:

Cool!

Is the output then always a number? Because I sort of want to hide the salt in the output.

It is, yes. You could convert the number to hexadecimal or something like that, but hiding the salt seems pointless, as a potential attacker could still access the salt. 

EDIT: Also, your algorithm's output only depends on the final letter of the input, I'm pretty sure. Similar input has the same output.

Really? That's disappointing. 

Here's what I'm planning to do.

Bob creates account with username/password combo:
Username: "Bob123"
Password: "golawnmowers123"

His password is hashed with salt 174716. The output is 746 (that's sort of the problem, the hashes are super short, the longer the hashes, the more passwords get different hashes, the harder it is to brute-force)

Now this salt is stored somewhere within the hash. In this case, let's say the position is the length of the input string divided by 15 (this is hard to do with such small hashes). Rounded up. In this case it's 1. The final hash that will be stored is:
717471646. The salt is underlined just to highlight it here, it wouldn't really be underlined. This is effectively Bob's password, but he doesn't know it. To a hacker, if the hashes were longer, it would be almost impossible to find the salt. Now what happens if Bob decides to log in again. Somehow his g key gets stuck and he types an extra 15 gs. (Again, if there were longer hashes, there would only need to be 1 extra g). This is the password:
"ggggggggggggggggolawnmowers123". The program would read that the salt would be located after the 2nd digit, so it would pick 747164 as the salt. This is incorrect and would hash the password differently to 2304. It would then insert the 747164 back in after the 2nd digit, like so: 2374716404. But even a smaller mistake such as "gilawnmowers123", although it would get the right salt, would (hopefully, if I can get a different hashing system) produce a different hash and result.

Last edited by SeptimusHeap (2012-01-16 11:11:46)

bobbybee wrote:

@SeptimusHeap
I suppose doing it that way might work, but I'm not sure if you really understand the purpose of the salt. For all I know, that salted password could be for Bob123 could be golawnmowers123Bob123. As you can clearly see, it doesn't really make a huge difference. The purpose of a salt is so that a hacker has to figure out the salt so it can be deleted, allowing him to get the hash. (which a supercomputer could decrypt)

I know. The salt is added to the pass and hashed, and then stored in the hash for the next login. The cool thing about it is that the program needs the pass to get the salt, and the salt to get the pass, so it's very secure.

bobbybee wrote:

Yeah, but just because it has a salt doesn't mean it's a good hash, or vice versa.

No, I know.

This is for my CloudGaming client, and was sort of the main way of storing data 
If only I could figure it out.

bobbybee wrote:

Oh. There is a difference between encryption and hashing, if CloudGaming is where this is going. You would hash the password, and then encrypt the data, perhaps having the key being the password.

Hmm 

This is being made in Panther, if that helps.

Storing the salt as part of the hash is not secure; you might as well not have the salt. Even if you vary the position of the salt, you're still not increassing the search space very much (particularly if the randomly-generated salt has a fixed length). A salt only really makes sense if it's kept completely secure. 

hashing without a salt.

You are awesome.

Thank you.

Magnie wrote:

SeptimusHeap wrote:

You are awesome.

Thank you.

Who?

You.

Anyway, I imported it into Panther and everything got screwed up. I tried to fix it, but had to get rid of the length thing 

Anyway, do you think it's fine to have different length hashes?