Did you ever thing the password that you submit into a page without SSL can be read from network listening hack technique?
It is a simple way to prevent this security issue.
In most of Content Management System, the user’s password store in database with hash algorithm. Such as the MD5 or SHA1 or etc…. Just your server reduce one operate in Hashing algorithm if you have more than one.
You must do a function with JavaScript and hash the input element with type of password. The value of this element before sending must be hashed with JavaScript.
See the header of normal login :
Content-Type: application/x-www-form-urlencoded Content-Length: 54 username=user&password=MyPASS&normallogin=Normal+Login
The hacker can read your data from header of your request.
password=MyPASS
More security with JavaScript
With this method you can create the secure form for login.
Content-Type: application/x-www-form-urlencoded Content-Length: 80 username=user&password=f4c0724be9899724b6d7549a71144441&securelogin=Secure+Login
password=f4c0724be9899724b6d7549a71144441
Use this method
In my idea when you hashed the password before the submit that the user privacy have been increased.
First we need a hash algorith that use in your password in server. For example we use MD5 in this example. Your password store in server with SHA1 hash.
In normal mode you use this method for checking sum for inputting password.
$password = sha1('myprivatevalue' . md5($_POST["password"]));
But when do hash in password value in client side reduce one operating:
// we do not use md5 for this because this method applied in client side with JavaScript
$password = sha1('myprivatevalue' . $_POST["password"]);
It’s a simple way to protect real string password but hacker can still hack your login form with inject the request (Thank to Ben hockey to remember this issue.).
You must use some way to prevent the hackers to inject request to your server.
My name is Muhammad Hussein Fattahizadeh. I have 24 years old. I study information technlogy engineering in Payam Noor University of Iran.
#1 by Muhammad on December 2nd, 2008
I say the password in common CMS’es store in database with hash algorithm. You must reduce one function in your algorithm and put it in clientsite Scripting language. See my complete example.
#2 by ben hockey on December 2nd, 2008
i saw your post http://dojotoolkit.org/forum/dojo-core-dojo-0-9/dojo-core-development-discussion/security-tip-network-listening-hack-techni and thought i should respond.
this is really a “false sense of security” because if the password i entered is “password” then the md5 is 5f4dcc3b5aa765d61d8327deb882cf99. great! now you don’t know that i entered “password” but… that doesn’t matter.
the value that the server is going to look for now to validate me is 5f4dcc3b5aa765d61d8327deb882cf99 but guess what? this is the value that is submitted in the header and so when i submit my login in the open the hacker can see 5f4dcc3b5aa765d61d8327deb882cf99 and use that value to spoof the server.
the only thing gained by transferring the hash of a value in the open is that it’s a little more difficult to read 5f4dcc3b5aa765d61d8327deb882cf99 but as far as security is concerned, it might as well say “password” because you’re still transmitting your credentials in the open.
that is why it’s a “false sense of security”
#3 by ben hockey on December 2nd, 2008
server side hashes are too late for ensuring a secure transmission. server side hashes will only help obfuscate the stored data and do not add any security to the transmission of the data. if you don’t get it yet then you need to take a step back and think about it a little longer.
even though you are sending a hash of the data in the header, you are still sending the header unencrypted! that means that the header can still be seen by a hacker. if i transmit 5f4dcc3b5aa765d61d8327deb882cf99 in the header then the hacker can see 5f4dcc3b5aa765d61d8327deb882cf99 in the header. since the server side validation is now expecting a hash value, now, all a hacker needs to do is submit the intercepted hash value of 5f4dcc3b5aa765d61d8327deb882cf99 in their own header and the server will think that it’s me since the hacker sent a valid hash. nothing was gained by a client side hash.
a securelogin with a password of “password” is only as secure as a normallogin with password of 5f4dcc3b5aa765d61d8327deb882cf99 – there is NO effective gain in security by hashing a password at the client! if this is not clear then be careful – you have only fooled yourself!
#4 by Muhammad on December 2nd, 2008
I know but with this method the real string of password will be protect from reading.
the hacker can read just the hashed value and can be inject the request of hashed value. Inject the request always can be applied and have several ways to prevent inject the post request. such as the captcha in brute force method. or hidden fields and etc…
The result of this method is the hacker can not find out the real password string. and just see the hashed value of that.
#5 by Jess on December 16th, 2008
Decoding an md5 hash (or any other short encrypted string) is fairly easy. MD5 dictionaries do exist (as related to your example of using md5):
http://www.google.com/search?hl=en&q=reverse+md5+dictionary
Furthermore, the string can be brute forced locally (not on your server)… and then there’s the possibility of an exploit to the algorithm, depending on what you’re using. You have no control over either of those once the hash is in the hacker’s hands.
If a hacker is able to retrieve the string you’re sending in the format you’re expecting it, that’s just as bad nomatter what format that is. Given time, ~any~ short string can be decoded in any standard algorithm, and it can always be injected and sent to you regardless of what else is on your page.
Furthermore, the assertion that adding captcha or hidden fields prevents a hacker from injecting the encrypted password is wrong. Plenty of methods exist to selectively enable or disable individual scripts in pretty much any browser. Look at NoScript for firefox. If the hacker has the md5 hash, he can disable the client-side hashing script, keep the captcha system enabled, and inject the hash with the captcha filled out. Right there is a successful login with a captcha system in place.
Also, hidden fields are not “hidden”, and are even -less- protected than any other method discussed. They can even be manipulated without any tools or extensions, just by saving the page html, changing it, and then submitting the form of the manipulated page. (Also look at “firebug” and “tamperdata” for firefox).
Client-side techniques cannot be trusted. Hands down. Do not, ever ever ever, rely on client-side techniques for protecting data. Ever. Also, don’t even think for a second that including them, even with other methods, helps security at all. It doesn’t. Javascript hashing least of all.
You should be using SSL for transmitting private data, and your users should be encrypting their data when using any wireless device as well. There’s no substitute.
The only thing your suggestion is doing is making a standard html login form inaccessible to users without javascript enabled. There’s no security improvement… you’re just blocking out legitimate users.
#6 by Jess on December 16th, 2008
I’m not sure what happened to all my line breaks… My post was much more legible before being mangled server-side. You might also want to look into that…
Best of Luck.
#7 by Jess on December 16th, 2008
Also…
Please do not suggest that anyone uses raw $_POST data when storing to a server-side database. Your suggested code also opens you up to a variety of other injection attacks, and doesn’t mention it at all.
Best of Luck.
#8 by Muhammad on December 17th, 2008
First sorry i was so busy and can’t approve your comment.
.
You’re rights. I think this is the method for increasing the security of your privacy of users of web site. for example the users’s of your site have same password in another site. that the hacker can listen in and use it to another login page.
I know the hash and md5 also can be decode but the hacker must have a costing much time to decode that. This is the tip for increase hacks operation.
SSL is the securest technology but with this tip you have a simple method to increase the time and tries of hack.
But yes this is the simple way and hackers can be going on of target. Thank again for reading my article.
#9 by Chris on December 30th, 2008
Muhammad, you keep replying in defense of your method. While it is always good to be creative in solving security problems, if you’re arguing against what has been said here, then you just don’t understand. That is OK! Allow me to attempt, if you will.
When you submit a normal login form with the username of “user” and the password of “password”, these values are visible by a variety of methods, this is agreed.
When the server gets this data, assuming the password is stored as a hash in the database, it must apply the hash function, then compare the value to the database’s to look for a match.
Assuming you employ your method, then the values “user” and “5f4dcc3b5aa765d61d8327deb882cf99″ are thus exposed to interception. When the server gets this information, it checks directly against the database value without the need to hash it.
In either case, if a ‘hacker’ sends “password” and it is hashed then compared server side, or if the hacker sends “5f4dcc3b5aa765d61d8327deb882cf99″ and it is compared server side, there is no difference in the security of the code. Either way, the hacker can use their chosen method to intercept the data that is being posted in the form that the server is expecting it in. When the server EXPECTS a hash, and the hacker HAS a hash… that is no different than if the server EXPECTS plaintext and the hacker HAS plaintext.
Further, client-side hashing eliminates the possibility (at least the practical possibility) for hash salting, since your salt value would have to be within javascript code, and thus obtainable by a would-be hacker.
Again – it is always a good thing to be interested and creative when advancing data protection, but it is VITALLY important that you be prepared to abandon an idea or concept when shortcomings or loopholes are pointed out. Security is an industry with lots of chaff, and it’s all or nothing. Either it works, or it doesn’t, and I’m sorry to say, this method does not work – in that it does not achieve it’s stated purpose of increasing security.
#10 by Chris on December 30th, 2008
Also, I wanted to add – the formatting on my comment (specifically, line breaks) was not preserved after posting it.
#11 by Chris on December 30th, 2008
Sorry for the comment storm.. heh. Here’s what I like to do (I’m a PHP programmer): before a form is displayed, generate a random string and place that string into an array in $_SESSION, I usually call it $_SESSION['___form_hash']. Place this hash string in a hidden input. When the form is submitted, check that the posted hash is in the array $_SESSION['___form_hash']. If it is, remove it, and proceed with processing the form. If it is not in the array, then it can be assumed that the POST data did not originate from a valid form. I also clear out $_SESSION['___form_hash'] before generating a new hash if there are already 5 in it, sort of ‘expiring’ old hashes. This permits a user to leave a tab open with a form on it, and use the site a little, then submit the form, but not to a great degree. This has it’s downsides by way of user inconvenience (they may have to refresh a page with a form on it that has been open a while), but it does also prevent data conflicts by enforcing a sort of ‘time to live’ on a form. Most importantly, this DOES increase the security of a form without relying on client-side methods.
#12 by Muhammad on January 14th, 2009
Sorry for lot waiting, I’m in the university exam
.
Yeah your method is right but with this method the user privacy has been increased. When you use both of theme the operation is so complicated and hackers must to pass the more operate to find the way.
#13 by Toby on January 15th, 2010
Muhammad, the point everyone is trying to make is that user privacy is *not* increased. Presumably the increase in security you mean is that someone snooping the network traffic cannot see the password in clear text. However it is trivial to lookup MD5 hashes for common passwords (not to mention possible to straight up crack with a few Playstation 3’s). For the site in question the villain doesn’t even need to do a lookup or crack anything; he can just send the hash, like Chris and others noted. Anyone bright enough to snoop network traffic will know this.
_Assuming that forcing an attacker to look up a hash is sufficient deterrence is a dangerously incorrect assumption_! The proper approach is to send this information over a secure channel. A cheap SSL certificate is maybe $20/yr, and some hosts let you piggy-back on theirs for the cost of hosting. Use a server-side salt to store the hashed password so your database isn’t vulnerable if it is compromised.
#14 by Toby on January 15th, 2010
Hmm I am a year late to the party…no longer 2009. :/
#15 by Muhammad on January 25th, 2010
Thanks for reading my article, Toby … It was just a way for increase user privacy that the user know the real string of password not be saved and the network does not carry the real password string … it was the increasable way for security solutions…