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

 

[Karelke]

while the MD5 ... they would not know the actual password

I don't agree with that. It's very easy to crack a md5 hash, check out http://www.golubev.com/hashgpu.htm
If someone is sniffing your HTTP traffic for md5 hashes, most likely that person is smart enough to crack the hash with the above tools.

But no client side encryption is not good either, I'm surprised to read that XenForo send the user password in plain text through the pipe? If so, then I'm voting for encryption (and something better than md5 please).

 

[Slavik]

This point is completely moot. vBulletin also posts the data as plaintext as well.

 

[Deebs]

I would love an option to perform the login over an SSL connection, make it a toggle for those of us with valid SSL certs.

 

[Deebs]

This point is completely moot. vBulletin also posts the data as plaintext as well.

Actually it is not, more and more people are using mobile devices to connect to systems, passwords should be protected from the source all the way to the authentication system. Just because other software doesn't follow best practise means XF should follow suit.

 

[erich37]

are you saying XF-Login is not secure?

On a sidenote, I have found this while surfing (see links below).
what is this? Would this help?

http://en.wikipedia.org/wiki/Pretty_Good_Privacy

http://www.cypherpunks.ca/otr/

 

[Deebs]

are you saying XF-Login is not secure?

On a sidenote, I have found this while surfing.
what is this? Would this help?
http://www.cypherpunks.ca/otr/

XenForo transmits the cleartext password in the post data when performing a login:

POSTDATA=login=Deebs&register=0&password=mycleartextpassword&cookie_check=1&redirect=%2F&_xfToken=

 

[ragtek]

This point is completely moot. vBulletin also posts the data as plaintext as well.

sure?

vB is sending the password md5 hashed (if js is enabled)

 

[erich37]

XenForo transmits the cleartext password in the post data when performing a login:

I thought Kier is "salting" Passwords?
... whatever that means...?

http://www.kierdarby.com/2010/03/seasoned-authentication.html

 

[Floris]

sure?

vB is sending the password md5 hashed (if js is enabled)

So, as an attacker, turn JS off? ..

 

[James]

I thought Kier is "salting" Passwords?
... whatever that means...?

http://www.kierdarby.com/2010/03/seasoned-authentication.html

The password salting occurs on the server, this suggestion is to mask the password as soon as you press submit (i.e. from the web page to the server)

 

[James]

So, as an attacker, turn JS off? ..

Isn't this suggestion to mask the passwords from outside sniffing? In which case, the attacker having JS disabled whilst sniffing the POST process shouldn't affect what the user is doing.

 

[Floris]

Isn't this suggestion to mask the passwords from outside sniffing? In which case, the attacker having JS disabled whilst sniffing the POST process shouldn't affect what the user is doing.

Sounds like a valid point indeed. +1

 

[Robbo]

sure?

vB is sending the password md5 hashed (if js is enabled)

This is hardly a problem for sniffers. No doubt there would be no salt so a rainbow table could easily be used.

To OP:
If you are handling sensitive data you should be using SSL. It is the only way to stop sniffers properly. The wordpress plugin you have linked is a extra layer indeed, but not something that would be hard to get past. A hacker could reverse what the mod does and use rainbow tables to get the password they want. Any extra security added client side with JS is only something that would slow a hacker down.

Pro tips:
Want your site to not get sniffed because of sensitive data? Get SSL!
Don't want to have your password stolen when in a public place? Don't use the same password for all your important stuff and don't use crappy passwords.

 

[Slavik]

XenForo transmits the cleartext password in the post data when performing a login:

sure?

vB is sending the password md5 hashed (if js is enabled)

vbulletin post data with js enabled.

POSTDATA=vb_login_username=bon&vb_login_password=*myplaintextpassword*&cookieuser=1&s=&securitytoken=1317840907-17c3e37cf057b516515151613d52777c943e84d1c&do=login&vb_login_md5password=*mymd5hash*&vb_login_md5password_utf=*mymd5hash*

 

[Deebs]

vbulletin post data with js enabled.

POSTDATA=vb_login_username=bon&vb_login_password=*myplaintextpassword*&cookieuser=1&s=&securitytoken=1317840907-17c3e37cf057b516515151613d52777c943e84d1c&do=login&vb_login_md5password=*mymd5hash*&vb_login_md5password_utf=*mymd5hash*

Slavik,

I am not interested in the failings of other software products, only XenForo.

 

[Deebs]

This is hardly a problem for sniffers. No doubt there would be no salt so a rainbow table could easily be used.

To OP:
If you are handling sensitive data you should be using SSL. It is the only way to stop sniffers properly. The wordpress plugin you have linked is a extra layer indeed, but not something that would be hard to get past. A hacker could reverse what the mod does and use rainbow tables to get the password they want. Any extra security added client side with JS is only something that would slow a hacker down.

Pro tips:
Want your site to not get sniffed because of sensitive data? Get SSL!
Don't want to have your password stolen when in a public place? Don't use the same password for all your important stuff and don't use crappy passwords.

Lets look at your pro tips:

It is now quite easy to SSL enable a webserver, the problem arises if you have to modify core files in an application to make it support SSL connections without throwing exception errors. Converting an entire site to run on SSL is a nightmare as any 3rd party links will cause warnings to be displayed. Simply saying Get SSL! is not the correct answer.

I do not use the same password and anything I access *is* important to me, I also use extremely complex passwords in nearly all cases. The problem is that I am not the majority of users who will use the same or weak passwords both online and offline.

For me the simplest is a checkbox inside the core which says "Use SSL for login/logout procedure" along with a "SSL Port" form for those that maybe running it on a different port.

 

[Slavik]

Slavik,

I am not interested in the failings of other software products, only XenForo.

The point is the original poster was making some comment about the vbulletin login being more secure than xenforos. The be all and end all is, that it isn't.

If you realy want to handle your logins with the postdata obfucated, then SSL is the option to use.

 

[Robbo]

Lets look at your pro tips:

It is now quite easy to SSL enable a webserver, the problem arises if you have to modify core files in an application to make it support SSL connections without throwing exception errors. Converting an entire site to run on SSL is a nightmare as any 3rd party links will cause warnings to be displayed. Simply saying Get SSL! is not the correct answer.

I do not use the same password and anything I access *is* important to me, I also use extremely complex passwords in nearly all cases. The problem is that I am not the majority of users who will use the same or weak passwords both online and offline.

For me the simplest is a checkbox inside the core which says "Use SSL for login/logout procedure" along with a "SSL Port" form for those that maybe running it on a different port.

I have read on these forums that people can use SSL quite easily. If you want to secure from sniffers then get SSL is the correct answer. It is that simple.

Adding what the OP suggests would be bad for 2 reasons. People will assume their website is more secure than it is and people will be very unforgiving to XenForo because they were under the impression it was securing them as well as SSL.

 

[Pulser]

I don't agree with that. It's very easy to crack a md5 hash, check out http://www.golubev.com/hashgpu.htm
If someone is sniffing your HTTP traffic for md5 hashes, most likely that person is smart enough to crack the hash with the above tools.

But no client side encryption is not good either, I'm surprised to read that XenForo send the user password in plain text through the pipe? If so, then I'm voting for encryption (and something better than md5 please).

Oh I totally agree. MD5 is trivial to reverse using rainbow tables. Ideally, something session hashed would be used, but the key exchange problem always becomes an issue... Exchanging this key securely, and having a salted hash in the database is slightly more complex when you start to add in the session element in what the user sends back. And over a non-SSL'd link, it's pretty hard to do...

This point is completely moot. vBulletin also posts the data as plaintext as well.

Not in my experience. I just logged into my current (stock login system) site, and my password example was hashed as 69faab6268350295550de7d587bc323d (which is the MD5 of "goodbye" as I entered)

I thought Kier is "salting" Passwords?
... whatever that means...?

http://www.kierdarby.com/2010/03/seasoned-authentication.html

You are indeed correct, Xenforo salts passwords server side This means that if some malicious person were to attack your server, and gain SQL access via some kind of SQL injection attack (which is highly unlikely via XF, but perhaps via wordpress if they shared a db (ugh use separate databases #justsaying) then it's not possible to easily reverse passwords. I would refer anyone after expansion on this to Kier's link for more info, as he explains it much better than I could... It's an important security step that salting carries out, but it only takes effect on the stored data on the server. It's no use for protecting before the data is at the server.

Isn't this suggestion to mask the passwords from outside sniffing? In which case, the attacker having JS disabled whilst sniffing the POST process shouldn't affect what the user is doing.

Exactly We're talking about someone on their phone or laptop connecting via wifi. The attacker has no access to control their javascript... So they would be unaffected unless using a comprimised PC, but that's not something to worry about, as keyloggers are a bigger issue in that case.

This is hardly a problem for sniffers. No doubt there would be no salt so a rainbow table could easily be used.

To OP:
If you are handling sensitive data you should be using SSL. It is the only way to stop sniffers properly. The wordpress plugin you have linked is a extra layer indeed, but not something that would be hard to get past. A hacker could reverse what the mod does and use rainbow tables to get the password they want. Any extra security added client side with JS is only something that would slow a hacker down.

Pro tips:
Want your site to not get sniffed because of sensitive data? Get SSL!
Don't want to have your password stolen when in a public place? Don't use the same password for all your important stuff and don't use crappy passwords.

Indeed, a rainbow table can be used on vBulletin passwords with relative ease. (it is plain MD5)

There is no sensitive data being handled here. This is a standard forum, it's just that, being involved in security myself, I was a bit aghast that plaintext passwords were in use.

RE the wordpress addon, I would be interested to see if someone COULD decrypt that password, given it is using public/private key encryption with 3K RSA... Without having access to the server (OK wordpress isn't the most secure, we all know), I can't honestly think how I would decrypt and get the password out... RSA is safe in my humble opinion, and OpenSSH appears to be good enough for our purposes in logging into servers I believe it's the same principle, though if I'm mistaken here I would love to know... Not that it's anything major, more a concept of liking to understand these things.

Finally, SSL is the ideal solution. I could get an SSL certificate. But I'm sure there's plenty of other XF users who can't get one, or don't think of getting one... I felt it was something worthy of consideration, given the aims of XF to expand larger and larger Sure, everyone else does it... But isn't that a nice chance to try and be different And yes, don't use bad passwords, and don't reuse similar passwords. All things I practice, but not all things that users of every XF forum will practice...

The point is the original poster was making some comment about the vbulletin login being more secure than xenforos. The be all and end all is, that it isn't.

If you realy want to handle your logins with the postdata obfucated, then SSL is the option to use.

I'm not saying it's more secure in fairness - I'm suggesting it's less prone to someone unskilled spying the password using one of the ready-made "password spy" apps you get for Android... The suggestion I was proposing would but XF (IMHO) in front of all other rivals in terms of login security "out the box". Sure, SSL is the best option, and everyone knows that here (including myself), but consider the number of forums running without SSL versus those with it... I figured it was a reasonable concern, although not a deal-breaker in any sense. It's a "nice to have" just to stand out from the crowd.

I have read on these forums that people can use SSL quite easily. If you want to secure from sniffers then get SSL is the correct answer. It is that simple.

Adding what the OP suggests would be bad for 2 reasons. People will assume their website is more secure than it is and people will be very unforgiving to XenForo because they were under the impression it was securing them as well as SSL.

Totally agree that SSL is easy enough I was having a look the other day. The only thing I am unsure about is how it would be any different if this (or something like it) were added, given the fact it's presumably not going to be the biggest selling feature. A note next to a config option for it perhaps? But even so, IMHO the average user has an expectation that their data won't be sniffed. Sure, they are wrong, and most people don't worry... But in tesco style, "every little helps" sometimes IMO anything to improve this would be a step forwards. Sure, session cookies wouldn't be encrypted, but that's one session being stolen. Next login, that one is presumably null and void (if they aren't logged in forever)?

Anyway, interesting feedback. I will look at SSL, but am fully aware it's utter overkill for our implementation. I'll also start looking at adding a login subsystem myself for the RSA implementation, as I guess this isn't going to be something Kier and Mike would be that interested in, judging from the feedback here.