Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 2 down vote favorite
1

A well known CMS called Joomla allows users to register and the password appears hidden as you register with dots a normal experience online - at this point you think just you know it. But if the site is using http then in fact the password is POSTed using plaintext.

This shouldn't be allowed!

I can understand that passwords are stored as salted hashes in good systems so even if the passwords are discovered on the db you cant use them to login.

Is that pretty much it?

Before we talk about password reset - in this case a good system cannot remind you of your password as it is not recoverable! It can only reset it for you and again isn't this sent plaintext over the net ??? So why cant that get stolen..

The issue is when the real plain text passwords are known by anyone or any system other than the user then identity is lost.

share|improve this question
For this maybe you can use authentication server, so the password is not on your joomla installation. For example, there are some openids, as well facebook and google logins. This is very secure actually to login to the app via google, as it's the highest level of trust you can give yourself by loggin in via your email account to another website, therefore on the market, one google account on a website you can sell for $10 which is 10x more then it's actually worth, because of the added security. – Andrew Smith Aug 7 '12 at 21:01
2  
Joomla also allows bad men to shoot innocent children. How can that be justified? – David Schwartz Aug 8 '12 at 3:18
edited question to be more answerable – Rory Alsop♦ Aug 8 '12 at 11:14

4 Answers

up vote 14 down vote

You have to use https. This is not a responsibility of the CMS application, but a responsibility of the person deploying the system, to purchase a signed SSL certificate from a known trusted certificate authority (note you can purchase for free from say http://www.startssl.com or included in the cost of your domain registration at say http://gandi.net ) and force all traffic to be only sent via HTTPS.

Even if the CMS application say hashed your password client-side (using say javascript), sent the hashed password over the network, and then checked the hash server-side, the hashed password (say hash=bcrypt('Correct Horse Battery Staple', salt)= '$2a$14$XUgYF0o3flsoGam2GHiw8OlQv9BBR/ihAwS/k83fZk.YjJ1hA/04.') would still be sent over in plaintext for anyone to eavesdrop. These eavesdroppers would still be able to do a replay attack (e.g., modify the client-side javascript to instead of hash an entered password, to just send back the captured hashed password $2a$14$XUgYF0o3flsoGam2GHiw8OlQv9BBR/ihAwS/k83fZk.YjJ1hA/04.) that they intercepted. Also, note that this effectively turns the client-side hashed password into the effective password; so ideally you would additionally further hash the received hash server side to compare against what is stored in the database. Or they could just intercept the session cookies sent over the network and use those to mimic activity of a currently logged in user.

Or they could just do mess with routing to do a man in the middle attack, so you send the password over to their server.

Furthermore, if they required you to use SSL without having purchased a certificate, the users may be scared away due to the browser warnings of an untrusted certificate.

A more complicated scheme may convince you that there is more security than there actually is, even though it would be trivial for an attacker to circumvent. All that is required is to set it up using HTTPS.

share|improve this answer
I assume that any 'reputable' blog cms not using https then should be avoided. – landed Aug 7 '12 at 21:01
1  
@landed - Pretty much yes, be wary of your password being sent in plaintext if you log into it over http. But again, the CMS doesn't implement https, that's the web server (e.g., you configure apache/nginx to use an SSL certificate and direct http traffic to https). On some http sites like stackexchange, you use an openid to authenticate your identity; e.g., if you use google as your openid provider, you give your password to google over https to authenticate. This is less than ideal due to cookie theft; but better than cleartext passwords. – dr jimbob Aug 7 '12 at 21:20
For internal use, you can do with a self-signed certificate. Since only a limited set of people require access to a typical content management system, you can tell them to ignore certificate warnings for this site -- though this might give them bad habits in the future. – dhasenan Aug 8 '12 at 5:21
2  
@dhasenan If you're doing it for internal use (e.g. at a company) then I'd recommend setting up your own private Certificate Authority and getting the SysAdmin to add that CA as trusted on all machines. I've just done it on a test website that only myself and my wife use to avoid the self-signed warnings. – IBBoard Aug 8 '12 at 9:04
up vote 8 down vote

Well, Joomla is a webapplication, it's not the webapplication's responsibility to provide an SSL interface so you can use HTTPS. This task is for the webserver on which the webapplication is running.

share|improve this answer
up vote 7 down vote

Joomla has had a "Force SSL" setting since version 1.5. You can set it up by changing either the configuration.php file, or using the admin web GUI.

Its set to "None" by default, mostly because several hosts don't support SSL/HTTPS out of the box. You probably want to change it to "Administrator Only" to secure only the admin interface, or "Entire Site" if you want to secure even the public facing front-end (useful if you have front-end logins.)

share|improve this answer
up vote 2 down vote

Sending passwords to websites in plain-text (e.g. a standard HTML login form on a CMS, forum or other web script) isn't secure. Similarly, sending passwords in emails (whether a new one as a "reset" or not) is insecure. Any time a password is in plain text then it is insecure.

The question is whether the account (and the site) is important enough to warrant SSL to encrypt the password in transit - security is always a trade-off of lockdown versus usability and your "risk appetite".

For Joe Bloggs' forum for him and his friends, assuming each of them follows decent security practice and has a unique password that they've not re-used on other sites(!), then the level of interest from a hacker is going to be very low. To sniff that password, they need to be on a hop between the user and the server, which is generally a high-effort task for low-value accounts (it lets him into the forum). If they re-use passwords then the value of each account is increased, but the size of the haul is still comparatively low compared to a simple phishing attack on bank accounts or social media.

If you want passwords that are encrypted before transit and aren't susceptible to replay attacks then you need to use something like Apache's mod_auth_digest, which uses a challenge-response mechanism. Your CMS or other script may have a plugin or "MOD" that enables this option.

There is no similar fix for passwords in emails - once it is sent then it is plain text and you can't do anything about it**. Just don't do it!

See PlainTextOffenders.com for examples of bad "passwords in email" practice, along with related stories of worse practices that become evident by the emails.

.

.

** This ignores the option of PGP encryption, but that requires the recipient's public PGP key so that you can encrypt it for their eyes only, which scripts generally won't have access to and many users will not have even set up

share|improve this answer
Good response, though again I wouldn't recommend HTTP digest authentication (mod_auth_digest) over SSL; it generally looks ugly; forces you to use MD5 (quite weak hash; though not necessarily demonstrably broken in this case); all traffic will still be sent unencrypted and unlike SSL is still vulnerable to a MitM attack (attacker reroutes traffic to server they control using Basic Auth; throws up a mirror of your site and captures the password when you try logging in). – dr jimbob Aug 8 '12 at 13:42
HTTP digest is no replacement for SSL, but in the low-risk case of "I want to do something more secure than plain text but it isn't valuable enough to warrant an SSL certificate and the unique IP that a cert requires" then it is a better option than plain text HTTP POST. Traffic is unencrypted, but that isn't a concern on most CMS systems (which are, by nature, public) and the password shouldn't be vulnerable to a replay attack of password. Not sure about session hijacking via cookies etc, though, to be honest. – IBBoard Aug 8 '12 at 15:33
Agreed. I'm also not sure if modern browsers clearly differentiate Digest Authentication from Basic Auth (alerting attentive users to the MitM I described previously; though sophisticated MitM attack would be possible if you build a fake digest auth that can use a stolen server nonce from the real site in a MitM). I think if you use digest authentication you aren't supposed to have sessions with session cookies, but your browser essentially re-logins (with your cached token) with each page. This probably doesn't play nicely with most CMS's expecting session cookies. – dr jimbob Aug 8 '12 at 16:43
Also with modern browsers, you can have multiple SSL/TLS certificates at the same IP address nowadays; I use this frequently. See RFC4366 (first point in introduction). Granted a non-self-signed SSL is not always possible; e.g., in the case where you don't control your domain and can't get the person controlling it to give you/let you set up a SSL certificate. – dr jimbob Aug 8 '12 at 16:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.