Lack of interest Suggestion Regarding Login Security

[Pulser]

I'm considering ordering XF just now for a migration from vB. One thing I noticed while playing with a demo install on the homepage is that passwords are sent via POST to the Xenforo back-end in plaintext, and then processed there. (you can see this happen using a Firefox addon such as "tamper data")

Now, I understand that I could simply use SSL and this would be much less of an issue. And if it comes to it, I could SSL the logon process (or more likely the entire site to protect the session cookie and identifiers) to get around this.

But this isn't ideal for people who might not want the expense or inconvenience of SSL certificates (sure, we run on dedicated servers with IP addresses available, but people on shared hosting might not be able to get this so easily). At present, I am aware that vB 4 sends user passwords after client-side javascript MD5'ing. Sure, this isn't protection against sniffing and replay, but it prevents anyone from seeing the plaintext password, and ensures plausible deniability for the site operator, as the plaintext password never even travels to the server in a regular install.

So where am I going? Well, I have a Wordpress installation for testing out various things, and one of the plugins I enabled on it provides "semi secure" (as the author terms it) login, by client-side encrypting the login process. It's protected against replay attacks, as there appears to be a form of session token sent to the client, and the Javascript processes the user's submission, POSTing the password back using public/private key RSA encryption.

All this happens transparently to the user. Sure, it requires Javascript, but so do most websites on the internet these days, including most of the rest of Xenforo So I was wondering if something like this would ever be on the cards for inclusion in Xenforo. At present, I was evaluating the various platforms I could move to, and was dismayed to find that most (if not all) still send the user password in clear-text. With a mobile oriented site, there's a high likelihood our users are accessing our website via a mobile device, particularly over open WiFi connections. This would expose their login passwords to anyone using one of the many readily available WiFi sniffer apps (even for phones). With our current setup, while the MD5 would be available to an attacker, and they could log in using the account, they would not know the actual password, and thus the user would not be at risk if they re-use that (or similar passwords).

As such, while I am really keen to move to XF, I feel this is a major stumbling block for us. I can't bring myself to step back and expose our users to this risk, and do so with a good conscience. Sure, I can use SSL as I mentioned before, but this isn't ideal for everyone.

Tl; dr:

So the suggestion? Is something like http://wordpress.org/extend/plugins/semisecure-login-reimagined/ feasible in XenForo? Worst case, I'd have to buy a licence, and look at trying to plug it into the authentication framework, but I'd prefer to not be buying the software and then immediately starting to adjust something as fundamental as the login system, before it was able to be used. I don't know if my PHP knowledge would be up to it, having been used to modifying vB before, which I'm more familiar with... Also, would this be something involving edits to "critical" files, or could form an "addon"?

Thanks

Pulser

 

[Deebs]

SSL is easy to implement I do not deny that, what is hard is links to 3rd party sites over HTTP as that will force the browser to display warnings. That is the hard part. I am currently beta testing a mod which implements 2 factor authentication using Yubikeys on my testforums.

 

[Pulser]

SSL is easy to implement I do not deny that, what is hard is links to 3rd party sites over HTTP as that will force the browser to display warnings. That is the hard part. I am currently beta testing a mod which implements 2 factor authentication using Yubikeys on my testforums.

Sounds interesting... I was considering use of Google 2-factor, as Google handles the SSL of the transmission of the QR code... It would only be for staff primarily. I'm going to try get a XF licence ordered up in the next couple of days so I can start to look at the API and how easy it is to add stuff (I saw an addon the other day for Steam login, and Steam is very similar to OpenID (it's just a crippled implementation of it), so I was thinking it might be time to try mod it to do OpenID, which would handle login security for us)...

Loads of solutions, I'm just trying to figure out what's best.

 

[MGSteve]

SSLing the whole site is a bit excessive and can be quite a lot of work and in any case, any external images linked to by users in their posts would result in a broken padlock anyway.

The easiest way around this is for XF to have logins via SSL as an option, so if you have an SSL certificate, you can use it to submit the logins via.

I presume XF doesn't send login info via POST for every post made on the forum like vB? Otherwise that's going to blow the SSL logins out of the water anyway.

 

[Deebs]

SSLing the whole site is a bit excessive and can be quite a lot of work and in any case, any external images linked to by users in their posts would result in a broken padlock anyway.

The easiest way around this is for XF to have logins via SSL as an option, so if you have an SSL certificate, you can use it to submit the logins via.

I presume XF doesn't send login info via POST for every post made on the forum like vB? Otherwise that's going to blow the SSL logins out of the water anyway.

This is what I suggested earlier in the thread so I hope Kier and Mike consider it. I might spin it off into a separate request. Cannot verify but I believe once the initial login has been performed it then sends a token. (Will have a proper look tomorrow)

 

[MGSteve]

That would make sense Deebs, I can't believe that even VB sends the password with every post like that, when a token would surely do. I guess they do that to avoid session timeouts and lost posts.

 

[Pulser]

I can't really get my head round that either tbh, but it would stop sessions timing out on long posts... I am thinking right now that to use ssl would be overkill, as I can't ssl the whole site, or we have insecure elements on almost every page there's an avatar or signature image from off site...

I can ssl the login perhaps (I gather this isn't an option just now, but I don't have xf to look). I didn't see it in the online trial though... But if you do this, you open up the avenue of just stealing the session cookie to get in, as it is by its nature, sent to every page... I know that every other forum is vulnerable to this, and it's just something you accept. But if I was adding ssl and going to that expense, as someone unfamiliar, I would presume sessions were protected by it, without unprotected content errors...

I guess this leaves us no further forward... Some kind of login protection or 2 factor would be nice. OpenID would prevent plain passwords too, as I understand... Either sounds feasible given the extensibility advertised...

 

[Deebs]

I can't really get my head round that either tbh, but it would stop sessions timing out on long posts... I am thinking right now that to use ssl would be overkill, as I can't ssl the whole site, or we have insecure elements on almost every page there's an avatar or signature image from off site...

I can ssl the login perhaps (I gather this isn't an option just now, but I don't have xf to look). I didn't see it in the online trial though... But if you do this, you open up the avenue of just stealing the session cookie to get in, as it is by its nature, sent to every page... I know that every other forum is vulnerable to this, and it's just something you accept. But if I was adding ssl and going to that expense, as someone unfamiliar, I would presume sessions were protected by it, without unprotected content errors...

I guess this leaves us no further forward... Some kind of login protection or 2 factor would be nice. OpenID would prevent plain passwords too, as I understand... Either sounds feasible given the extensibility advertised...

The thing we are attempting to stop at the moment is the transmission of cleartext passwords. If my session is hijacked my password is still safe. Once I put my Yubikey system live I can not worry about that particular password being compromised as it will be a "cheap" one but I would much prefer to have it sent over an encrypted channel.