PHP Encryption Question

[Falkon303]

Ok, so let's say I have the following

<form id="form1" name="form1" method="post" action="" enctype="application/x-www-form-urlencoded">
  <label>
  <input type="password" name="pass" id="pass" />
  </label>
  <label>
  <input type="submit" name="submit" id="submit" value="Submit" />
  </label><br>
  <? if (isset($_POST["submit"]) && preg_match("/</", $_POST['pass']) == "0") {echo md5($_POST['pass']);} ?>
</form>

The question I have is how to encrypt the variable for the "pass" field during post.

If I have a network sniffer, this shows the password completely as text. I am fairly positive there is a method for encrypting prior to post, but am not aware/familiar of it yet. Help appreciated.

- Ben

[Nile]

I don't get it, what way is pass being encrypted? Can you also explain what you're trying to do and provide all your code.

[djr33]

There's no point. You could use Javascript to do some sort of masking of the text by applying a pattern-based "encryption" algorithm, but then it would be THAT, and NOT the actual password that is sent to the PHP. This means:
1. That would be visible on network monitoring and it would act as a password if you wanted to hack the site (just skip the javascript and submit manually).
2. The algorithm for "encryption" would be available within the javascript available to the user, so it could be "decrypted".
So, again, this isn't encryption, but just masking/transformations.

This is the standard and, basically, just accept it. If you need a reason, just think of any website (google, paypal, this site, etc.) that has a login and that's how it works. You can make it confusing and complex to submit, but nothing will actually hide the data being submitted.

The "password" attribute on an input field IS just a textfield with the text displayed, by the browser, as bullets, not letters. It's not secure nor intended to be. It just stops people from reading over your shoulder.

You MUST send a valid password across the network, no matter how you do it, and that will be available through anything that can monitor all network traffic.

Just like wanting to hide source code (which would make rendering a webpage impossible), there's no solution to this that still allows you to log in.

[CrazyChop]

If you really have a need for such security, it is better to get go VPN. Usually over secure network, there is already encryption at the lower network layers.

[djr33]

Though I don't know the details about that, the issue is still very simple:
1. You are sending data over a network.
2. You must send that data over the network.
Regardless of how you encrypt it, a network administrator who has full access should be able to see what you're sending, and if it can be decrypted on the server it is possible (if a bit challenging, maybe) to decrypt it as the network admin.
Basically, if you're on a network where you worry about the admin spying on you, get a new job, or something like that.
I'm sure a secure connection of some sort is helpful for this, but I'm not sure what even that will do against a network admin.

[Falkon303]

never mind, I have figured out a way to do it.

Using ajax, you can use "onkeyup", and send a value from an input outside of the form to a hidden input within the form, but also have the variable encrypted through the dynamic request.

This will send an encrypted string through the post, and you just have to encrypt that encryption in your db to do a comparison, so it's totally possible.

Thanx for the feedback.

[djr33]

That's not secure. All someone on the network would need to do is copy whatever you do send, turn off javascript in their browser, then send that value and it will act as your password. Whatever you actually send to the server IS the password, in essence, so going through a number of steps to generate it first is a waste.
That will stop weak hackers, etc., but a network admin will probably be able to get around it if it matters.
Again, think about all the websites that DON'T do this, and that now your website is javascript dependent, so people can't log on who don't use javascript.

[Falkon303]

That's not secure. All someone on the network would need to do is copy whatever you do send, turn off javascript in their browser, then send that value and it will act as your password. Whatever you actually send to the server IS the password, in essence, so going through a number of steps to generate it first is a waste.
That will stop weak hackers, etc., but a network admin will probably be able to get around it if it matters.
Again, think about all the websites that DON'T do this, and that now your website is javascript dependent, so people can't log on who don't use javascript.

The reason I bring this up is that I used that post form and Wireshark and saw how odd it was that the variables were wide open....

I know some people "spoof" encrypt post variables, just to defeat would-be attacks, but you bring up a very nice point.
Also, my current website will be javascript dependent, and a non-js version is in the works as well.

What about this -
If I pulled the current time based on "keyup" action and used that as a form of post authentication (encrypted, and meshed inline with the password). It could be similar to a session, but this way when people repost, if the date doesn't match the server side, it will fail.

so in other words - onkeyup, grab current time, on submit = (end timespan) + 1 second for server processing

It seems this would work great. Thank you much for your responses djr33.
Another issue I have to consider is that the "onkeyup" characters will be sent as post variables as well, similar to google suggest I imagine, so I may want to attach salt to every onkeyup.

- Ben

[djr33]

The time idea is a good one in theory, but not practical in that it wouldn't be hard to fake that later and it would be difficult to know that it is exactly one second later, not 5 (if there is a connection issue for a moment), and still possible to see what's being submitted so you could extract the password and resend with the right time.

In general, I still don't see why you need this extreme level of security-- NO other websites use it. Unless you're working for the government, or something at that level (and at that point the network admins would be authorized anyway), I don't get why it's so worrying.

If you're willing to sacrifice accessibility for security, consider using flash, java, or another system like that which would be harder to reverse engineer.

Or think of another sort of password, such as one that is visual, like a CAPTCHA, or something else creative like that.

In the end, what you have right now is so complex that even if it works, it doesn't seem really worth the sacrifice to being ajax-dependent. Beyond that, the odds of a network admin hacking you are much less than someone hacking you another way entirely, regardless of the password being sent locally.


The best idea I can come up with for this is to do something like this:
1. Store your password on the server raw (or, if you want to do an extra layer of md5, etc, on the whole thing, go ahead).*
2. When you submit the password, "encrypt" it (with md5, or similar) INCLUDING the current time.
3. To check if this matches the password on the server, check it against a mirror of this method: the user's password, and the current time/times 1 second less than the current time until 10 seconds before. (Thus giving a 10 second window.)

*However, even if all this worked, you'd still be submitting the password in the first place, when you store it on the server (or change it on the server).

[Falkon303]

check this out -

---UPDATED: now showing algorithm client side so the flexibilities are shown. With some comma removal from the array values, this thing will be perfect.... It'll be a great sub for https://!

http://diblab.com/encryptest/loginform.php

Once I vary the string lengths, and shift char values random increments, this will be fairly secure from hackers. Now the people who watched me program it through one of the 6500 windows os backdoors, they are the one's who could crack it fairly easily. I'll throw up the new source code when it's perfected if you are interested.

- Best

- Ben