Basic question on the security of the "post" password submission

PHP
1

I am just beginning design of a site and had a quick question about authentication. The submission of id/password using the standard technique shown is pretty straightforward but is it secure or is this passing the pw as cleartext across the wire and this page should be https?

Any help would be appreciated, I would like the site to be secure.
Mark

<form action="index.php" method="post">
<label for="email">E-mail Address: </label><input type="text" name="email" id="email" size="25" maxlength="80" />
<label for="pass">Password: </label><input type="password" name="pass" id="pass" size="20" maxlength="20" />
<input class="submit" type="submit" name="submit" value="Login" /></li>
</form>
2

Thzat’s still a HUGE amount of extra JavaScript code needed just to provide that second key to the lock just to add slight protection for if the person stupidly used the same password elsewhere (and if they don’t have JavaScript enabled or disable it for pages that contain humungous JavaScripts as this one would then they are back to sending the plain text version anyway. Also since they are intercepting all of what you send from your browser they’ll collect the other passwords when you send them anyway.

There is a very simple and very secure way to send passwords from the browser to the server where you decide that you need it and it can be applied to ANY site without needing much in the way of code changes. It’s called HTTPS. That is specifically what HTTPS is for - as well as being the only way to do it.

If you want to secure something being sent from the browser to the server you use the right tool for the job - HTTPS and not the wrong tool (eg. a horse, a hammer, JavaScript, or oranges)

3

In the database yes but that isn’t what this thread is about. This thread is discussing how to secure the password between the browser and the server and the only way to do that is to use HTTPS.

The second most secure way for when HTTPS isn’t available is as plain text since that way there is only one possible value that will work for the password. It is vulnerable to a man-in-the-middle attack but then so is ANY method that doesn’t use HTTPS.

Using JavaScript to hash the password before sending it means that the server needs to be able to accept both the plain text AND has versions in case JavaScript is disabled. This makes it twice as easy for someone to crack the password since there are now two values that will work instead of one and a man-in-the-middle attack will retrieve whichever of the two is used and they’ll be able to use that to break in whether you hashed the password or not.

Sounds like vBulletin need to improve their password security by getting rid of the hash versions of passwords so as to reduce the number of values that will work for the password for someone trying to break in.

4

Using a packet-sniffer an evil person could see what information is being sent in the tcp packets, including post information a little like this:


POST http://yourwebsite/dologin.php

username=johnny.dacu&password=123456
5

It’s called the Man-in-the-middle attack. I don’t know how you would perform that attack over HTTP but I’m pretty sure it’s possible. If I did know how it worked I wouldn’t explain it either; wouldn’t want people to get ideas :cool:

6

This really surprised me.

To test this out, I used firebug’s Net tab and logged in facebook, and yes, the password is send in the clear with a POST request. :eek:

However, vBulletin actually uses a hash, with a fallback to plain text when javascript is disabled.

SMF also uses the hash method (1.1.x, I didn’t test the 2.0 RC).

Yahoo mail and Gmail are SSL by default, so those big-name sites aren’t valid for this exercise.

Hotmail / MSN / Live Mail POST the password in the clear, although I had trouble capturing it with firebug (the persist option kept being disabled).

7

They do.

8

I would advise against doing that as all it means is that there are now two versions of the password that will work to break into the account instead of one and the two versions are still being sent in plain text (depending on whether JavaScript is or isn’t available) even though one is a SHA-256 of the other.

Anything you do with JavaScript weakens the security.

9

Yes, but this is still open to replay attacks…

10

You can encrypt the password at the browser too. PHPJS project has translations of most of the php’s functions into javascripts. See the project here.

Before submitting a form, you can encrypt the password with md5/sha, … and send it to the server. This too works better - hashing again.

11

Yup, the method described here is prone to the replay attack.

I’ve outlined a method in another thread that doesn’t suffer from this (but has it’s own drawbacks, obviously using SSL is the only way to get it completely safe).

12

OK, but…
If the hash is sent over in clear text, then a sniffer could still use that to log in.

You might not know the password, but you know the hash, so you’d still be able to log in.

13

If HTTPS isn’t available (although HTTPS is the best option from a security standpoint), you can hash the password upon submission. I’d suggest a javascript implementation of SHA-256.

The hash would be sent in plain text, but the user’s actual password would not.

You might also want to salt as well as hash the password to make it a little more secure.

Note that if javascript is disabled in the browser, you’re back to sending the password in plain text.

14

Yes, it’s posted as plain ‘clear’ text. Using https will mean the request’s content is encrypted, including the password.

15

See, and that brings us back to square one again >_<

On the other hand, it’s the user’s responsibility to not use the same password everywhere.

16

Oh, forgot to add…wordpress is POSTed in plain text as well.

I really cringe at the fact a lot of logins send the password in the clear.

But, I guess it makes sense to have only one key per lock, and not two keys per lock.

17

It does and it doesn’t. If the real plain text password is intercepted on it’s way the attacker might be able to use the same password for a dozen other sites and email accounts too, and they get an insight into your password naming pattern.
If they intercept a hash they can still access the site in question, but won’t get so many clues to help them break into other accounts.

18

Using sha1 hash or md5 hash is the best option to protect password.

http://www.php.net/manual/en/function.sha1.php

19

On normal http request a post variable is sent plain text. but could anyone give me a real example about how could somebody intercept this variable? I know, is a noob question but i cannot imagine any scenario

20

Yes, that’s the most secure way to do it if SSL isn’t available since any alternative just makes it easier to crack by providing alternative values that will also work if captured.