For IP.Board 3.x, passwords are sent plain text. I normally don't see this as a problem.

However, I recently worked with a website that was exploited, and the login file was modified, so that the unencrypted password was both sent to an E-Mail address and written to a text file on the server.

Granted, the need for this is limited, but being that passwords are passed through MD5 anyway, if you do it with Javascript, prior sending the password, it would create an added layer of security.

Obviously, you'd need a fall back for those who don't have JavaScript enabled. Adding a simple check on the action would solve that problem, though.

You could always write your own in-house encryption system that's harder to recreate or brute force <_<

If your ACP or server is compromised, there is no scheme that could be devised that would prevent a sufficiently resourceful attacker from scraping passwords.

JS-based hashing could easily be removed (if it's even possible, which as far as I know it is not), and if you have a server-side fallback (which you would have to), then it would still work with people not seeing any difference.

Even if they used stronger hashing, that would still not prevent issues if someone has access to the passwords in the way that they could write to file. You need to ensure you have good security practices to prevent that.

If your ACP or server is compromised, there is no scheme that could be devised that would prevent a sufficiently resourceful attacker from scraping passwords.

JS-based hashing could easily be removed (if it's even possible, which as far as I know it is not), and if you have a server-side fallback (which you would have to), then it would still work with people not seeing any difference.

Even if they used stronger hashing, that would still not prevent issues if someone has access to the passwords in the way that they could write to file. You need to ensure you have good security practices to prevent that.

Isn't it better than nothing?

Isn't it better than nothing?

Not really, no. There is no tangible benefit to adding client-side hashing. For that matter, I can think of at least one reason why it would actually make security worse (substantially worse). (If you were referring to stronger hashing, sure, >I totally agree. But >it's complicated.)

As I said before: The onus is on you to ensure your systems are protected enough that attackers cannot gain access. If they do gain the kind of access Diego R is talking about, no kind of programming or methodology can prevent them from doing Very Bad Things.

It's meant to make it more difficult, not stop it completely.

I fail to see how it would make things less secure. Sending passwords plain text vs hashed. Seems like a no brainer.

I am on Ryan's side. I would love to see additional security implementations however what Diego suggests does no good.

It's meant to make it more difficult, not stop it completely.

I fail to see how it would make things less secure. Sending passwords plain text vs hashed. Seems like a no brainer.

Disregarding that browser JavaScript doesn't even support hashing: Unless the server performs further hashing or manipulation after the data is sent, that would mean you're comparing user input directly against the database for authentication. Which means... if anyone did get access to that database, all they would have to do to login to any account is to bypass the JS hashing and send the server that hash directly. Server says 'oh hey! They match! You're logged in now.'

You can easily MD5 hash a string with JavaScript... You're not thinking about it right.

Traditionally, browsers send:

login=someUser&passwd=somePassword

with browser hashing, it would send:

login=someUser&passwd=be3bb966fe47ca01c1609a25873e0192

So, on the post page, you'd just have to compare it like: md5( $salt . $_POST['pass'] )

With the rise of HTTPS, few sites send log in details in plain text. I think this would be a step in the right direction. Obviously, it can be broken, and still brute forced, but it helps protect against middle man attacks.

That doesn't really change much...

Instead of a plain text password, they're getting a hash that does the exact same thing... They simply need to provide the hash and they're logged in. No brute forcing involved.

Use SSL if you're concerned with it.

That doesn't really change much...

Instead of a plain text password, they're getting a hash that does the exact same thing... They simply need to provide the hash and they're logged in. No brute forcing involved.

Use SSL if you're concerned with it.

Difference is, the attacker doesn't have the plain text password, so can't try and use it somewhere else.

That doesn't really change much...

Instead of a plain text password, they're getting a hash that does the exact same thing... They simply need to provide the hash and they're logged in. No brute forcing involved.

Use SSL if you're concerned with it.

No, it's not the exact same thing. Plain text can be used on other sites -- hashes cannot.

MD5 would be worthless with IPS4.

As you've noted, if you're concerned about it, SSL is the best way to go.

I disagree. SSL uses more resources, slows down page loads, and adds costs. I don't think normal page loads need to be encrypted. Only sensitive data, like passwords, should be encrypted.

Again, I fail to see how it would be worthless.

Again, I fail to see how it would be worthless.

IPS4 uses a completely different hashing algorithm

I disagree. SSL uses more resources, slows down page loads, and adds costs. I don't think normal page loads need to be encrypted. Only sensitive data, like passwords, should be encrypted.

That used to be the case 4-5 years ago. I advise you to catch up with current server technology...

It is still the case. It's not as bad, but there are still performance differences. It's going to be slower no matter what because more data is being transferred.

Also, MD5, SHA1, doesn't matter. It can be done in JavaScript, too. I'm speaking on the current system.

It is still the case. It's not as bad, but there are still performance differences. It's going to be slower no matter what because more data is being transferred.

Nay it is not the case , in fact many websites only choose to run on SSL because it is faster now.

Nay it is not the case , in fact many websites only choose to run on SSL because it is faster now.

It's faster than comparitively it used to be, it's not faster than raw HTTP, but it isn't far off (excluding negotiating the initial connection). If you're talking about people using SPDY rather than just plain HTTPS, then that's a different matter as well.

That being said, I am not advocating against using HTTPS all the time, I think that would be fine.