So, I guess I am pretty much looking for an expert in Java Script I personally haven't learned Java Script so please go easy on me 
Basically what I am trying to do is have when a form is submitted on client side Java Script takes the posted data encrypts it not using a HASH but using an encryption that can be decrypted using php. Then POSTing the data to a php file so that I can use simple php functions to take the data ($_POST['bla'])
Also, when the form is submitted it can't send the unencrypted data to the server it must stay on the client's computer until it has been encrypted.
If there is also an easier way where the form posts to a php file directly but some how using java script it encrypts certain form fields before sending it to the file. This way might be achieved by having like <input type="submit" onclick="<!-- Some Javascript Code Here -->">
Also it needs to run properly in IE and Firefox if you don't have time to test it in both just post the code I'll test it.
Thank You So MUCH!
P.S. for those of you who are going to tell me to use SSL instead don't. I know I could but I am using this for an open-source software.
Edit: Or even better have it use like sha1 hash if java script has it if not md5 if it has it and just post the hashed version the the php file. That way it only need to encrypt like passwords and then php won't need to hash it. Well you could use Rotate 13 encoding. This is compatible with javascript and php. Use this fairly self explanatory javascript function to encode each part of your form and then use php to transform it back.
I don't know how secure you want it but this should be OK. | Dougie1 wrote: |
Well you could use Rotate 13 encoding. This is compatible with javascript and php. Use this fairly self explanatory javascript function to encode each part of your form and then use php to transform it back.
I don't know how secure you want it but this should be OK. |
That's interesting, but I am not sure if it is really all that secure since it doesn't even have its own like.. iono function.. LOL
I meen like in php you could hash something using md5($string) because md5 is already in the php package where that is being created in the code. So ya.
Was looking for some sort of encryption algorithm that was already built into javascript.Why do you need it to be that secure???? If you really want it to be that secure get https or some other form of secure page.
| Dougie1 wrote: |
| Why do you need it to be that secure???? If you really want it to be that secure get https or some other form of secure page. |
As I said in my thread starter "P.S. for those of you who are going to tell me to use SSL instead don't. I know I could but I am using this for an open-source software."Question: why don't you want to use SSL? I don't understand what your software being open source has to do with this.
| MrBlueSky wrote: |
| Question: why don't you want to use SSL? I don't understand what your software being open source has to do with this. |
Ok, SSL is usually installed on the server by an administrator the software I am building is for the average person that has a shared hosting account where they don't have access to installing such things as ssl on the server.
Secondly if SSL can be installed by a shared host account the only free certificates usually have to the non computer savvy user a big scary do you wish to take this certificate with a whole bunch of reasons why not to on it. Which most users would probably deny.
So, if I use javascript or some client side language to encrypt the form data then send it to a php file it all happens in the back-end.
I understand why your saying to just install ssl. It's just this would probably the next best thing in case the webmaster doesn't have the option to install ssl or buy ssl.
Understand?
I see what you meen by how does ssl have anything to do with open-source, sorry i miss worded the statement. It should have been basically something summarized of the ^above^Why do you need it to be so secure? What is wrong with rot13 encoding which is compatible with both javascript and php? Most sites you visit have no security for posting passwords etc so why do you need security? If you use javascript to encode the parts of the password or whatever you are posting, surely a hacker can just look at the page source, see how it is being encoded and then somehow magically intercept the post data decode it (from the info in the javascript) and then viola, they have the password anyway...
| Dougie1 wrote: |
| Why do you need it to be so secure? What is wrong with rot13 encoding which is compatible with both javascript and php? Most sites you visit have no security for posting passwords etc so why do you need security? If you use javascript to encode the parts of the password or whatever you are posting, surely a hacker can just look at the page source, see how it is being encoded and then somehow magically intercept the post data decode it (from the info in the javascript) and then viola, they have the password anyway... |
Ya, but the question is would that 'hacker' go to all that trouble to get the password where as if it was sent as plain text he woudn't need to go to, to much trouble to get it. How about base64? is there any ways in javascript to encrypt data using a function instead of creating the algoritym right in the code.
It's all about making it harder for the hacker without making the functionality die for the user. This won't really affect the functionality maybe make it a little more slow but hardly noticable. | cr3ativ3 wrote: |
| MrBlueSky wrote: | | Question: why don't you want to use SSL? I don't understand what your software being open source has to do with this. |
Ok, SSL is usually installed on the server by an administrator the software I am building is for the average person that has a shared hosting account where they don't have access to installing such things as ssl on the server.
Secondly if SSL can be installed by a shared host account the only free certificates usually have to the non computer savvy user a big scary do you wish to take this certificate with a whole bunch of reasons why not to on it. Which most users would probably deny.
So, if I use javascript or some client side language to encrypt the form data then send it to a php file it all happens in the back-end.
I understand why your saying to just install ssl. It's just this would probably the next best thing in case the webmaster doesn't have the option to install ssl or buy ssl.
Understand?
I see what you meen by how does ssl have anything to do with open-source, sorry i miss worded the statement. It should have been basically something summarized of the ^above^ |
Oke, I understand. That makes sense. Well, Javascript doesn't have a built-in encryption function, so you will have to make one yourself or use a third-party Javascript. Making your own function should be not too difficult, you can just translate an excisting encoding algorithm to javascript, and I think there are probably third-party scripts you can use.
Next you can even go a step further in making it more difficult for a hacker to retrieve the sniffed encoded password by also obfuscating the javascript you use to encode the password.Thanks, do you know how to post data to a php script from javascript? I found this script: I am just not sure how to post the encrypted data to a php script. http://www.webtoolkit.info/javascript-base64.html To make it secure, you've got to hash the password. Anything else is useless.
With hash, a cracker will still be able to get the hash password, and login, but he won't retrive the original password.
MD5 in javascript
SHA-1 in javascript
Another SHA-1 code in javascript. Ya, Good point seeing as I don't need to decrypt the password then rehash it in the php file. I could just hash it there and it would be more secure. Thanks, but I still need to know how to send the data to a php file using post in javascript and then how to do all this like if someone could come up with an example of the code, It would be very helpful. As I said I really know nothing but maybe alerting and confirming in javascript.
You have to attach an event listener on the form submit, and modify the value of an input, and then fallback to the default form action.
On PHP side, you get the value of the input, and use it.
Read this doc and search on the website for more tutorials. Oh, ya I actually basically reinvented it I think what I am doing now is something similiar to gmail. I made login script which encrypts the data in the form using javascript when a button is pressed and then I have it submit the form.
So now when I use like sha1 to hash the pass before it is sent over no one listening in on information being sent over the line can get the password 
Which I guess is more secure then just SSL and a regular form.
What made me think gmail was doing something similiar is that when you log in on gmail the form data changes to like encrypted text. Before you are actually sent to another page. Encryption with Javascript is as good as useless. If the text is being decrypted at the other end, a cracker can simply read your Javascript code and see how the text is being encrypted, and then work out how to decrypt it. You might as well just send in plaintext as it will be just as useful and a lot quicker.
That's why we're not talking about encryption, but about hash 
| qscomputing wrote: |
| Encryption with Javascript is as good as useless. If the text is being decrypted at the other end, a cracker can simply read your Javascript code and see how the text is being encrypted, and then work out how to decrypt it. You might as well just send in plaintext as it will be just as useful and a lot quicker. |
Right but if it is hashed it can't easily be decrypted seeing as it's hash. If it is even possible to decrypt. Like Ranfaroth said.
| Ranfaroth wrote: |
| That's why we're not talking about encryption, but about hash |
If you were talking about what I am currently doing having it encypted not the hash well I need to change that yes and, with the encryption not the hash it is security through obscurity.Hashing in JavaScript is possible, but slow. You'd be better to submit it to the server and have the server do it.
But the OP wants to be able to decrypt his data on the server, so we are talking about encryption. My point above still applies.
Are you sure ? | cr3ativ3 wrote: |
| Ya, Good point seeing as I don't need to decrypt the password then rehash it in the php file. I could just hash it there and it would be more secure. |
And you're wrong : | Quote: |
| You'd be better to submit it to the server and have the server do it. |
Hashing before sending the password is more secure for the user (because nobody can get it) Sorry, didn't read the thread fully.
Anyway hashing the password on the client is no more secure than hashing it on the server, because something is still transmitted that the server will accept as a valid password. If your connection is not encrypted it doesn't matter where you hash your password because a cracker can still see what request to send to the server to get his desired result.
Hashing it doesn't make it much more secure. If a hacker is listening in on it, he probably won't know what your username and password are, but he doesn't need to. He only needs the hash if you do that.
So when he goes to log in, he just turns off javascript, and enters in the hashes he intercepted. And then he's logged in.
So the only way you can make it secure without SSL is to salt the hash with a timestamp of the current minute, so then the hash is only useful for that minute, and if a hacker listened in he'd need to act within a minute, but you're probably still logged in so you can make the code take notice of that. And even if the hacker managed to log in within a minute of you, he still doesn't know your password, and won't be able to log in as you again until he intercepts another hash and logs in within the minute.
| qscomputing wrote: |
| Anyway hashing the password on the client is no more secure than hashing it on the server, because something is still transmitted that the server will accept as a valid password. If your connection is not encrypted it doesn't matter where you hash your password because a cracker can still see what request to send to the server to get his desired result. |
All right.... I'm going to explain for the last time.
We compare 2 methods : - Sending the plain password, hashing on server and comparing the result
- Hashing on client, sending to server and comparing
Right ? No SSL here.
First method : the cracker sniff the transmission. What does it find ? The password.
Second method : he'll find the hash.
So with the first method, the cracker can login, but even more he has the password (which might be used for other purposes....)
With the second method, the cracker can login, but he can't guess the password.
Do you understand now why second method is more secure for the user ? | Ranfaroth wrote: |
First method : the cracker sniff the transmission. What does it find ? The password.
Second method : he'll find the hash. |
Yes, but in both cases he finds the data that he needs to send to the server to create the login request. He can then recreate that request using his own code. Just because the password that is typed is not the same as the password that is sent over the network does not mean that the system is more secure!
Now, if you're trying to prevent the cracker from finding out the user's password (because the user is using the same password on other sites), then this would work - though bear in mind the cracker can still use a dictionary attack against the hash. However, if you're trying to prevent the cracker from working out how to login, this method is worse than useless. Useless, because the data is still there in the clear. Worse than useless, because it gives the user and developer a false sense of security.
I hope this is clear enough now.I'm glad to see that you eventually understood 
| qscomputing wrote: |
| Ranfaroth wrote: | First method : the cracker sniff the transmission. What does it find ? The password.
Second method : he'll find the hash. |
Yes, but in both cases he finds the data that he needs to send to the server to create the login request. He can then recreate that request using his own code. Just because the password that is typed is not the same as the password that is sent over the network does not mean that the system is more secure!
Now, if you're trying to prevent the cracker from finding out the user's password (because the user is using the same password on other sites), then this would work - though bear in mind the cracker can still use a dictionary attack against the hash. However, if you're trying to prevent the cracker from working out how to login, this method is worse than useless. Useless, because the data is still there in the clear. Worse than useless, because it gives the user and developer a false sense of security.
I hope this is clear enough now. |
Yes, so are you saying that SSL is useless if you are using it to log in to a website? The "hacker" could then just send the same encryption request to the server to get in right?
If that is true then hashing it would be the most secure because it can't be decrypted where as SSL will be. As long as the user uses an abstract enough password the hash is more secure is it not?How, unless the hacker is on the same network as the target computer, is the hacker going to intercept a POST on port 80?
| coreymanshack wrote: |
| How, unless the hacker is on the same network as the target computer, is the hacker going to intercept a POST on port 80? |
Correct, unless such hacker found a hole in the security of such network or computer that is big enough to allow him to collect such data. | cr3ativ3 wrote: |
| coreymanshack wrote: | | How, unless the hacker is on the same network as the target computer, is the hacker going to intercept a POST on port 80? |
Correct, unless such hacker found a hole in the security of such network or computer that is big enough to allow him to collect such data. |
wow, i know if i were a hacker i'd go for the much easier targets that already had a known network hole. I dont think it matters how "big" your computer is. | coreymanshack wrote: |
| cr3ativ3 wrote: | | coreymanshack wrote: | | How, unless the hacker is on the same network as the target computer, is the hacker going to intercept a POST on port 80? |
Correct, unless such hacker found a hole in the security of such network or computer that is big enough to allow him to collect such data. |
wow, i know if i were a hacker i'd go for the much easier targets that already had a known network hole. I dont think it matters how "big" your computer is. |
Sorry I ment a big enough security hole to allow such attacks. I didn't meen the size of the computer lol . | cr3ativ3 wrote: |
| coreymanshack wrote: | | cr3ativ3 wrote: | | coreymanshack wrote: | | How, unless the hacker is on the same network as the target computer, is the hacker going to intercept a POST on port 80? |
Correct, unless such hacker found a hole in the security of such network or computer that is big enough to allow him to collect such data. |
wow, i know if i were a hacker i'd go for the much easier targets that already had a known network hole. I dont think it matters how "big" your computer is. |
Sorry I ment a big enough security hole to allow such attacks. I didn't meen the size of the computer lol . |
Ha, it's ok, that's understandable.
