Jump to content
Game-Labs Forum

move forums (and site) to https


Recommended Posts

Hello Admin,

 

It would be a good idea if the forums (and maybe the website) would be moved to https. This may seem as a low priority issue, but I think it is not. Let me explain.

 

Short explanation: Because passwords.

 

Long explanation:

Because it is a well know fact that people reuse passwords, and people like to keep their passwords organized (the human brain is awfully bad at remembering strong passwords) there is a big chance that people reuse their Naval Action forum password for other services, both Naval Action related and other, as well.

 

Since the connection to the forums is non-encrypted, username::password combinations are send in plain text over the wire (which ironically nowadays means through wifi). So any user logging in using a public or otherwise shared wifi router is extremely vulnerable to MITM (=man in the middle) sniffing attacks; anybody with a mild interest in the subject can harvest passwords at, for example, your local starbucks corner.

 

By migrating the forums to https this attack vector would effectively be disabled.

 

~Brigand

  • Like 5
Link to comment
Share on other sites

You don't need a https website to HASH passwords, which is already a pretty safe way of doing things. So i disagree and think that its a bad and misinformed point with a lack of understanding of what https actually does and how to properly secure passwords.

Edited by Dutch Dutchery
  • Like 2
Link to comment
Share on other sites

You don't need a https website to HASH passwords, which is already a pretty safe way of doing things. So i disagree and think that its a bad and misinformed point with a lack of understanding of what https actually does and how to properly secure passwords.

Dutch is definetly correct in that you dont need https to hash passwords and https(and http) is just a transfer protocol, and i would suspect that https is used by default for the login, the site itself and the forums apart from logins have absolutely no use for https.

 

 

edit: i have been looking around, and as far as i can tell IP board(the software used for this forum) uses SSL for securing login pages and potential store pages, which should be adiquate for the forums use case.

Edited by OlavDeng2
  • Like 1
Link to comment
Share on other sites

You don't need a https website to HASH passwords, which is already a pretty safe way of doing things. So i disagree and think that its a bad and misinformed point with a lack of understanding of what https actually does and how to properly secure passwords.

 

Here's the problem.  Either you're hashing on the client side, which means anyone with half a brain can reverse engineer the hash, or you're hashing on the server side, which means you're still sending the username/password in the clear.  Brigand has a very good point.

  • Like 2
Link to comment
Share on other sites

Here's the problem.  Either you're hashing on the client side, which means anyone with half a brain can reverse engineer the hash, or you're hashing on the server side, which means you're still sending the username/password in the clear.  Brigand has a very good point.

except that the important bits are allready secured with SSL(logins, and potential store pages), so if anyone puts their password somewhere else, honestly it is their fault.

Link to comment
Share on other sites

Here's the problem.  Either you're hashing on the client side, which means anyone with half a brain can reverse engineer the hash, or you're hashing on the server side, which means you're still sending the username/password in the clear.  Brigand has a very good point.

I can't tell you how wrong that is. Any decent hashing will not do that.

 

http://www.openwall.com/articles/PHP-Users-Passwords

 

The part i recommend you read:

 

When a user authenticates to the application with a username and a previously-set password, the application looks up some auxiliary information (such as the hash type, the salt, and the iteration count - all of which are described below) for the provided username, transforms the provided password into its hash, and compares this hash against the one stored for the user. If the two hashes match, authentication succeeds (otherwise it fails).

Edited by Dutch Dutchery
Link to comment
Share on other sites

The password has to be hashed after it is put into the web form.  Either that is done client side, which means human readable script (which would include your salt and obfuscation technique) in the web page markup itself, or (and this is usually how it is done) it is performed server side, which, if you're not using SSL, means you're sending the password in the clear.  

Link to comment
Share on other sites

The password has to be hashed after it is put into the web form.  Either that is done client side, which means human readable script (which would include your salt and obfuscation technique) in the web page markup itself, or (and this is usually how it is done) it is performed server side, which, if you're not using SSL, means you're sending the password in the clear.  

well if it is done server side, we dont have a problem as SSL as being used.

Link to comment
Share on other sites

You don't need a https website to HASH passwords, which is already a pretty safe way of doing things. So i disagree and think that its a bad and misinformed point with a lack of understanding of what https actually does and how to properly secure passwords.

 

I should probably not step into this discussion, but I think some clarification is needed.

It seems you are confusing two parts of password security. One part is about storing passwords or, more properly, password identifiers. The other part is about communicating the (knowledge of) the password with the server. My question to migrate the forums to https addresses the second part.

Storing passwords on the server is a bad idea. Fortunately, this fact is slowly becoming a known fact. Instead of storing a password, a password verifier should be stored. The accepted best practice is to hash the password (using a password hashing algorithm (such as BCrypt or SCrypt) or, less ideal, a key derivation algorithm (PBKDF2)) and only store the computed hash. Verification of the password is done by hashing the client supplied password and compare the resulting hash to the one stored on the server; if they match, access is granted.

However, before the password can be verified, it needs to be communicated to the server. The only* method of communicating safely with a server available to a web browser is (unfortunately) by communicating through SSL/TLS. In other words, by communicating over https.

Hashing a password on the client side (before transmission) to subsequently send it over a non-encrypted connection is, unfortunately, non-secure. The problem is two fold: first, the hash (as calculated on the client side) effectively became the password: since the server will grant access to whomever sends the hash, I could simply send the hash as well and impersonate you. The second issue is that, since the connection is non-encrypted, the integrity of the data you receive cannot be guaranteed. In other words: I can manipulate the information sent between client and browser and, as a result, I can remove the client side hashing (which is typically handled by a snippet of javascript code). The result would be that you would, unknowingly, send your password as plain text over the wire (=wifi nowadays).

Hope this clears things up a bit.

~Brigand

*other methods exist, but they are far from practical and typically only feasible within an organization which can control software on the client machines.

  • Like 5
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...