Re: Salted MD5 login to prevent sniffing in non https

[Stefano Gargiulo]

PS. When you sniff it the standard joomla security token is already unvalidated so you cannot use the raw md5 string to do another login!

2011/12/15 Stefano Gargiulo <rast...@gmail.com>

Reading this reply in the "New hashing algorithms for Joomla" thread:

 During login, the password is

is transferred in plain text, if not SSL is used.

I tought: why not increase security also for non SSL sites using a salted hash login method (SMD5)?

I explain:

You can use the one-time joomla token (there is a one-time token in any Joomla form no?) also as a salt to pass to a javascript md5 function.

So you can code the login form in a similar way:

<form onSubmit="saltPassword()"....

function saltPassword(){
....
     inputboxpassword.value=js_md5('$token'+'--'+inputboxpassword.value)   //this will also celan the DOM from the real password (can be done also without distrupting user input box obviously)

....
}

this will transmit over the wire each time a different md5 password!!! unsniffable! (the salt is done with a random token so it is very difficult to reverse engineer the md5.)

Obyously in the server sithe validation you shuld have somethig like this:

"WHERE MD5(CONCAT('{$token}--',password))='$formReceivedMD5OnetimeSaltedHash'

i prefer to have this  in the SQL to prevent also that also the data from the mysql server and the php joomla server goes in clear (no one uses mysql over SSL!!!!)

my 2 cents.

Stefano.

[Stefano Gargiulo]

[Nicholas K. Dionysopoulos]

Hi Stefano,

If I understand your implementation correctly, we'd either have to store the password unencrypted in the database, or the user would have to remember the 32-digit salted MD5 sum of his password AND the 32 digit salt, as this is what is stored in the database's password field. In one word: impractical. I would rather see something different. If we can find a JS implementation of asymmetric cryptography we can encrypt the user's password before transmitting it to the server. Using per-session public/secret key pairs would essentially offer us a great degree of protection for logins, even without SSL. BUT! Once the user is logged in, we send him a cookie. It's conceivable that a third party intercepts this cookie and impersonates our user. This attack is trivial to perform wherever there is an open Wi-Fi hotspot and people logging in to HTTP sites. Therefore if you want to protect your users against impersonation attacks buy an SSL certificate. That simple. Any other solution is just a half-baked workaround which gives a false sense of security to those who don't know anything about cracking.

Also your point about nobody using MySQL over SSL is a little moot. You are correct that nobody uses MySQL over SSL, but then again, why should he? No server administrator on his right mind would have this traffic go through the open Internet, if not for security then certainly for performance and cost reasons. Usually, the MySQL and web server are on the same machine. Using "localhost" in the connection parameters instead of "127.0.0.1" also means that we're telling PHP to use named pipes instead of TCP/IP, therefore there is no data exchanged outside of the box. Even in the case of separate boxes, the database server with the web server communicate over a very fast (Gigabit and higher) internal network at the host's premises. Obviously, if someone infiltrates the data centre physically he can sniff the traffic, otherwise he'd have to compromise the root account of a machine connected on that network and have the NIC run in promiscuous mode to sniff the packets. Frankly, if someone does this kind of infiltration, the fact that the MySQL data is unencrypted is the last thing which I am worried about. That's why nobody uses MySQL over SSL, unless connecting from a local client (e.g. his desktop) to a live server – which is a bad idea anyway, but I digress.

Cheers,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Sam Moffatt]

I agree, most JS based mechanisms essentially go part of the way to
just implementing SSL with the risk that you can't actually do that
all that securely in JS. As Nicholas correctly identifies you are
forced to store the password in plain text which makes the site
vulnerable to an SQL injection attack and other curious attacks around
passwords that rely upon them being plain text (I saw one that used an
ORDER BY and another user account to effectively guess the password of
users via a user list if the order by clauses weren't scrubbed for
only the fields they need).

The cookie based attack is also a problem though we do some extra
checks on the client to make the simplistic attack of just taking a
cookie a little more challenging, again the correct behaviour here is
to use SSL and secure cookies to make sure that can't happen.

Additionally we don't do a search where the password matches because
if you just do a WHERE clause on the generated password to find the
user (which is what your snippet appears to suggest), someone could
conceivably create an attack where they randomly supply passwords and
brute force their way into an admin account.

Finally there are already extensions out there that provide login
functionality including some which implement RSA (or at least they say
they do) which is a much better way of handling these things. If
someone wishes to have this functionality, they can deploy one of
these extensions. Otherwise I'd suggest using HTTPS.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Marius van Rijnsoever]

On Fri, Dec 16, 2011 at 3:24 AM, Sam Moffatt <pas...@gmail.com> wrote:
> I agree, most JS based mechanisms essentially go part of the way to
> just implementing SSL with the risk that you can't actually do that
> all that securely in JS. As Nicholas correctly identifies you are
> forced to store the password in plain text which makes the site

> vulnerable to an SQL injection attack.

This is partly incorrect.

When I have seen JS to secure plain passwords, quite commonly hashing
is done (can't decrypt/reverse that vs SSL that does allow
decryption). SMF uses this to prevent plain password transmission by
default, but can't be applied to Joomla without changing our hashing
methods (break backward compatibility).

There are some JS based SSL methods, but neither hashing and
encryption methods force storing of plain text passwords in the
database!

I did do some work towards getting a new JCrypt class into the core.
Many of the JS encrypt classes use outdated algorythms. I did find one
that has "proper strength SSL" encryption (and was GPL licensed), but
the problem was that there is no GPL licensed PHP decryption library
available. The option was to use PHP addon packages such as RSA_Crypt,
but that would mean it would not work on all servers (which is why I
stopped working on Jcrypt)

It is possible though, here is a free working example:
http://extensions.joomla.org/extensions/access-a-security/site-security/login-protection/11519

With regards to this patch for different password hashing methods. It
may benefit large commercial enterprise type clients, at the risk of
breaking some sites when they are moved hosts. However this solution
is for when hacker already gained full access to your sites,
downloaded your mysql tables and just got bored after destroying your
complete site. Now they want to get other user passwords and this
solution would take the bruteforce attack time from a year to a few
decades :)

It would be better to focus on preventing your whole site being
compromised. Prevention of plain password transmission would be a good
start. In addition PLEASE consider the following extension into the
Joomla 2.5:
http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/12731
It prevents 95% of Joomla attacks by blocking SQL injection and Local
File Inclusion of vulnerable 3rd party extension. I believe we have a
duty to protect joomla users from these basic hacks. They are common,
automated bots make heavy use of these (I get about 50 attempted
attackes on my site per day) and it is very easy to block. Wouldn't it
be great if we can stop 95% of attacks, by including a simple plugin?

Thanks, Marius

[Nicholas K. Dionysopoulos]

Marius,

I STRONGLY disagree about password encryption. Plus, you did not read mine and Sam's reply. Let me reiterate.While it does secure the transmitted data (password) it does squat in securing the cookie. Even though Joomla! tries to strengthen the cookie, it is conceivable that a hacker CAN steal your cookie and impersonate you when not using SSL. If you want to protect your site's visitors, buy an SSL  certificate. Otherwise you're trying to treat cancer with aspirin. Security is not about just encrypting the password.

Even though it's off-topic, the SQLi detection in the plugin you mentioned misses a lot of attacks and throws quite a few false positives. If the Joomla! project decides to include such a feature, I can gladly donate the exact code I am using in my for-a-fee GPL extension as I've seen it work much better. That said, I consider the whole concept very silly (despite me offering such a solution) because it tries to fight the symptom, not the cause. The cause being developers using raw MySQL statements with unescaped data. The mere use of JFactory::getDbo()->quote($incomingData) is adequate to prevent the majority of SQLi attacks.

Also, regarding your statistics, have you taken apart the attempted SQLi's on your site? You will see that 99.999% are targeting old versions of components (2-4 years old), Joomla! 1.0 and -drum roll, please- Mambo! Since the end of November they've become much worse and there is at one US-based ISP where half of those attacks are originating. What does this tell me about Joomla!? Nada. It just tells me that some script kiddies got their hands on outdated hacking scripts and consume their time in a futile attempt to hack outdated software not installed on your site.

For what is worth, and I know I am way off topic, the most common cause of hacked sites I've seen is 0777 permissions. Either directly or indirectly, because they make people put their FTP pw in the configuration.php files, which can be read (if there's another compromised account on the server) and give the attacker full access to the site. That's the major security threat for all CMS out there, not just Joomla!. And we can do nothing about it.

Nicholas K. Dionysopoulos
Web Development & IT Services
http://www.dionysopoulos.me

http://www.AkeebaBackup.com

[Marius van Rijnsoever]

Hi Nicholas,

Its naive to say that SQL injections and LFI's are only in old
components. Look at the vulnerability list:
http://docs.joomla.org/Vulnerable_Extensions_List

Still lots of current extensions added, even from experienced and
reputable developers.. Guess what LFI and SQL injections are still the
common ones.

Sorry to hijack the thread slightly, I decided to reply when I saw the
misinformation that for some solutions cleartext passwords need to be
stored (can give examples of why not if needed).

It just comes down to the overall approach. You can say, no need to
secure x because someone can always hack with y. No need to prevent
SQL injection attacks, as they mainly for old components. No need to
prevent clear text password transmissions, as they can always get the
cookie, etc etc. That approach is flawed in my opinion. My preferred
option is to lock down as many methods by default.

I agree with you that SSL is essential and with official certificates
costing around 5 dollars, there is really no excuse and a much better
solution.

There are lots of softwares out there that add some default protection
against clearpassword sniffing. Its not all "protective", but makes
things one step harder.

There is no downside to blocking queries containing
../../../../../etc/password or obvious SQL injection attacks. Its
fantastic that you have better code to block these common attacks and
that you are willing to share these. The Joomla project often gets
blaimed for security flaws in 3rd part apps. Since they are common,
easy and they have affected extension from experienced developers, I
think it is our duty to add some default protection against them. This
will make the Joomla platform much more secure.

And for the record I agree with you that altering the type of hash
that is stored in the Joomla database has minimal effect on security
with downsides of being able the "break" sites,

Thanks, Marius

[Andrew Eddie]

> In addition PLEASE consider the following extension into the
> Joomla 2.5:
> http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/12731

Just a couple of quick comments on this - forgive me if it takes the topic astray, but it does highlight that the complexities we have to deal with.  

On a process note, please do not nebulously ask to have extensions added into the core - this is happening all too often.  Ask the author's themselves to contribute or ask them if you can contribute on their behalf or just start a new discussion on what do we want and how can we design it from the ground up.  That's how it works.  Aside from that, a feature of this magnitude has well and truly missed the 2.5 boat.

Second, and apart from a not-so-easy-to-read coding standard (and, seriously -> /* Create table: the dirty way */), the approach is fundamentally shaky because Joomla has already booted up and made database queries (on top of that, it's up to the user to ensure this plugin fires first).  The idea of adding addition security layers is fine but just throwing an extension at it is not the right way to approach it (well, it could be, not not this one).  The only SQL prevention worth it's salt is at the DB layer itself (as Nic has already pointed out).  I'm pretty sure it would throw a false positive saving a tutorial about SQL hacking or similar ;)

IP block is ok in theory but the plugin doesn't account for masks or ranges.  I also wouldn't use JError::raiseError as that's going to want to touch the DB even more and load a template (and goodness knows what else).  There's also a huge risk that an attacker can disable a site by deliberately trying to get a "good" IP blocked (that just happens to belong to where most of your "safe" traffic comes from).  Whatever the case, the whole shebang needs more configuration and reporting UI to support it and much earlier intervention in the bootstrapping sequence.  Let's focus on designing this properly and safely if it's going to be done at all.

Regards,

Andrew Eddie

http://learn.theartofjoomla.com

[Nicholas K. Dionysopoulos]

Marius,

Don't put words to my mouth. I would never say that. I mean, you have no idea who the heck I am and never watched my security presentation I have delivered across the world, right? I said that most of the attacks you see ON YOUR SITE are targeting old components. Did I mention anything about components not being vulnerable? No! Please learn to READ before replying.

I could address all your other points but it's a waste of time for me as you are apparently not reading what I write.

[Marius van Rijnsoever]

On Fri, Dec 16, 2011 at 2:56 PM, Nicholas K. Dionysopoulos
<niko...@gmail.com> wrote:
> Marius,
>
> Don't put words to my mouth. I would never say that. I mean, you have no
> idea who the heck I am and never watched my security presentation I have
> delivered across the world, right?

Wow that is completely uncalled for. I have never said anything to
insult you and just wanted to make a small contribution to the
discussion. If you know me I would never make any derogatory comments.
No need to go to personal attacks and mention "who you are"

[Nicholas K. Dionysopoulos]

Implying that I am oblivious to the fact that recent extensions have security issues IS very insulting to me. It is insulting because of who I am, what I do for a living and everything I've written regarding site security - that's why I mentioned the "who I am" part, I have no intention to compete for whose is bigger. You pretty much implied that I don't know what I am doing in my profession. If this is not insulting then what is? Also note that you said I implied has nothing to do with what I said, so you DID put words in my mouth. That was uncalled for. I just replied to what you wrote. If you don't like my comments, don't put words in my mouth. Fair and simple.

Nicholas K. Dionysopoulos
Lead developer, AkeebaBackup.com

Sent from my iPhone
Please excuse my brevity

[Marius van Rijnsoever]

Please take a step back Nicholas. I never implied anything like this.
Look at my replies and see that I have been very polite, stating many
times that I agree with you. Remember things on an online forum never
sound like the way they were intended.

Can we get back to the discussion now?

[brian teeman]

On Friday, 16 December 2011 00:05:10 UTC, Nicholas K. Dionysopoulos wrote:

 The cause being developers using raw MySQL statements with unescaped data. The mere use of JFactory::getDbo()->quote($incomingData) is adequate to prevent the majority of SQLi attacks.

With the, hopefully very soon, commit of support for non-mysql databases aren't extension developers going to have to ensure that they dont use raw mysql statements in their code from now on.  Won't that have a nice side effect;)

[Nicholas K. Dionysopoulos]

Sure, let's get back to the discussion. After all, it's a public forum, people can read our posts and draw their own conclusions.

FWIW I am against SQLi protection in the core, but not because I do not consider it a real threat. On the contrary. I believe that if you add too many security features (of dubious efficiency) in the core you are making your users complacent. The end result is that they are reluctant to upgrade their components, as they THINK they are protected anyway. Little do they know... The question, therefore, is whether we want to add a feature which blocks legitimate requests (e.g. Forum posts discussing SQL), doesn't block all nefarious requests and makes our users complacent under a false sense of security.

This feature is not going to make it in the core. I had proposed a similar feature about a year ago and I was presented with more or less the same arguments. I came to believe that they are valid. You do need reporting, exceptions and a site owner with a working brain to have this feature perform as intended. This Is usually too much to ask from the average Joomla! User.

Nicholas K. Dionysopoulos
Lead developer, AkeebaBackup.com

Sent from my iPhone
Please excuse my brevity

[Stefano Gargiulo]

I agree the critical, i'm also for the always https pratice (i worked in security and sso identity management), the only way to full security, but consider that most beginner users doesn't know how, and some can't configure ssl in their hosting, and sometimes if you have to use things like iframes to http contents using https causes the browser popup problem.

So i mean, https is the solution bu you should provide some basic security out of the box.

What's the percentage of joomla https sites ib the world over the joomla installations? most extension developers e comnerce sites are also in http and these users are the most techies. https is good but it requires a lot of time

I'm sorry for the raw example i gave but sure you can and must have md5 in db instead of plain:

Think to have this in js
Js md5(salt+md5(inputbox.value))

And
md5(concat($token,md5passfield) in sql

Yes in this way you cannot have salted hash in db but just hashes but if they compromise your db it's pribable they also have your php salt variable printed or destroyed your site as said the important of using hash in db  is to protect user privacy

Ps to provide a basic security out of the box also against session hajacking (cookie sniffing) you can enable an ip check session mechanisn.

regarding mysql and ssl: some shared hosting providers doesnt have a good dmz and also some universities and schools, but yes them i was saying this just to let you know that im a fan of ssl and i think is the definitive solution

Ps a tip for you all: you dont have to buy ssl certs startssl.com gives you free ssl certuficates (is a CA validated by all browsers)

Best regards
Stefano
Written via android

[Stefano Gargiulo]

I agree also this point so i dont pretent my request to be implemented was just a point of reflection. instead let's start to sensibilize over the need of ssl (add https as a suggested system requirement for joomla in the future?)

[Marius van Rijnsoever]

Nicholas, we will have to agree to disagree on the what level of
protection is optimal in the core. Please note that disagreements are
common even among experts and that this does not detract from either
of our reputations. In my main line of work differences of opinions
are valued, as they can prevent deadly consequences. Also I have been
developing Joomla components for more than 5 years and do know about
security. Therefore please give me the benefit of the doubt that I
also know something :)

Users by default are complacent, rarely upgrade, always take the
easiest approach and only consider their security when they have
already been hacked. No actually in real life I am an optimist, but am
a pessimist on this issue because of some studies and real life
experience. I tried to find an article that showed the distribution of
Joomla versions on the www, but that website has since gone (Jfoobar).
It was done by a previous Joomla core developer that assumable wrote a
crawler that detected versions of Joomla sites through google. Quite
cleverly done, he could even tell the exact joomla version of each
website. From memory 90+% of Joomla websites where outdated and only a
few ran the latest version. Interestingly this was in the time where a
major security flaw was discovered in Joomla 1.5.5 and months after
discovery lots of sites where still running vulnerable versions. Why
do I bring this up? People do not even keep their Joomla version
itself up to date, guess what percentage of Joomla installation run
the latest versions of their components (very few in my opinion).

>On the contrary. I believe that if you add too many security features (of dubious efficiency) in the core you
> are making your users complacent. The end result is that they are reluctant to upgrade their components,
> as they THINK they are protected anyway.

People that think about security always upgrade immediately. The
problem is that 99% do no think about security setup their site, do
not check their installed components for updates, or check the offical
list of vulnerable extension or just forget about upgrading. You are
not going to make people complacent by adding some basic security
features to the core, as security minded people implement "best
practice" regardless of what is in the core.

The second point I want to illustrate is the point "people should use
SSL, everything else is suboptimal and should not be implemented".
Unfortunately 99% of Joomla sites do not use SSL and are therefore
theoretically vulnerable to sniffing hacks. Take as an example all the
joomla.org related sites. I just checked most of their login forms and
could not find a single one that uses SSL (yes even the administrator
login pages that I could find). If even joomla.org does not use SSL
for logins, why should basic Joomla users with minimal knowledge care
about implementing SSL. Although a congratulation is in order to
yourself for being the elite 1% of joomla users that runs SSL by
default!

Let me summarise the scenario for everybody. Users are generally lazy
when it comes to security and don;t implement the required security
measures (I agree with you that in my experience the majority of
server hacks are due to non-joomla vulnerabilities, but that is a
story for another day). On the other hand we know that Joomla 3rd
party vulnerabilities are common, are still happening, can happen
regardless of the experience of the extension developers, are easy to
exploit and are being exploited. We also know that the majority of
these hacks are due to mysql injection or local file inclusion. In
addition people rarely use SSL to protect their passwords and cookies.

I again agree with you that just because of the above scenario that NO
half hearted solutions need to be implemented into the core. But we
have two options here (feel free to think of more if you can)
1) Do nothing, as people should be responsible for their own site security
2) Accept that because Joomla is so accessible for relatively
inexperienced users and that exploits are common, that some basic
protection is wanted.

Ok lets get back to what we could achieve and I will therefore also
come back to what started this thread (which made me realise that I
partly confused this thread with the "type of hashing of database"
thread that is going on concurrenty. oops sorry) :P

1. Hashing passwords before submission.
Hashing of passwords using javascript on the client side to prevent
transmission of plaintext password through http is possible. Even
without storing plaintext passwords in the database itself this is
possible, just look at softwares like SMF (will skip on the details to
stop this reply getting even longer). However this is not possible to
implement for Joomla due to hashing being a one way street and such a
solution would break all backward compatibility.

2. Encrypting passwords before submission.
Most javascript libraries implement RSA encryption using old
standards. When I was looking at implementing a JCrypt class for
Joomla I did manage to find one GPL javascript encryption library that
had proper handling of padding to prevent adaptive chosen ciphertext
attacks (too complicated to go into detail in for this post). However,
at that time no GPL library was available to do a proper decrypt on
the server side. However cryptographic libraries that can be installed
with the PHP core could do this, but may not be installed on all
servers. Since I preferred a solution that worked on all servers, I
stopped that work. But we can add this JCrypt library which can
provide default "plain password transmission" protection if these
libraries are installed (normal joomla behaviour if the libraries are
absent). Yes there are still issues with "cookie sniffing", but a
hacker having a plain text password is worse.

3. Preventing SQL injections and LFI's
Agreed that blocking requests can result in disruptions of valid
submissions (like when someone is discussing SQL injections in a
joomla forum components). However the key is not to "block" requests
but to "sanitise" the global variables. Worst case scenario with the
"sanitise" option is that the "SQL attack string" is not formatted
correctly (and therefore the forum post won;t show the correct SQL
attack syntax correctly). The post action will still work, as the
request is not blocked. If someone has a hacking forum, it can add the
forum component to the exclusion parameter field (and the forum
component input will not be sanitised) or a well aware security expert
can just unpublish this proposed sanitising plugin. Then of course
there will be a long discussion on which regex should be used to
detect attacks. There will not be a perfect regex for sure, but it
will be able to stop the bulk of attacks.

Well this turned out to be a way longer response that I had
anticipated. Since I am not in the decision making process of what
goes into the core, I guess my opinions are irrelevant :). But there
are certainly things that we can do. The Joomla project sometimes gets
marked down on security which is not its fault (a badly designed 3rd
party component is). But wouldn't it be nice to add some basic
protections for the 99% of the less informed users. As long as it is
implemented correctly, it will add to the reputation of Joomla and
other softwares have demonstrated that these solutions can be
implemented in the core successfully.

Thanks, Marius

[Andrew Eddie]

On 16 December 2011 22:53, Marius van Rijnsoever <mari...@gmail.com> wrote:

> 3. Preventing SQL injections and LFI's
> Agreed that blocking requests can result in disruptions of valid
> submissions (like when someone is discussing SQL injections in a
> joomla forum components). However the key is not to "block" requests
> but to "sanitise" the global variables.

This doesn't solve the problem of stripping out valid content. You
cannot tell from looking at the request how the data is going to be
used. SQL can look like normal content. The key is to sanitise data
when it's used. No security training I've ever been to advocates
sanitising data before you know how or where it's going to be used.
Better to spend time crafting regex's to scan files to defective code
and putting them on the VEL than to waste CPU on every request "just
in case".

> Since I am not in the decision making process of what
> goes into the core, I guess my opinions are irrelevant :).

Your opinion is relevant but you need to realise that the decision
making process is not about what your opinion is, it's about what code
you've contributed.

> But there
> are certainly things that we can do. The Joomla project sometimes gets
> marked down on security which is not its fault (a badly designed 3rd
> party component is). But wouldn't it be nice to add some basic
> protections for the 99% of the less informed users.

Yes, but it's a trade off and no substitute for trying to keep sloppy
coders off the streets.

> As long as it is
> implemented correctly, it will add to the reputation of Joomla and
> other softwares have demonstrated that these solutions can be
> implemented in the core successfully.

That's not necessarily correct because of the reasons Nic, I and
others have cited. All you do is shift one problem (security) to
another arena (support for glitchy false positives and lower
performance) and you still have the time bomb of sloppy code on your
site.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.7 developers

>
> Thanks, Marius

[Stefano Gargiulo]

Yes, but it's a trade off and no substitute for trying to keep sloppy
coders off the streets.

Less of the 1% of the Joomla Extension Directory related websites uses HTTPS!

So joomla extension developers are sloppy coders?
No, SSL is hard to configure well, if you don't think so please put it as a requirement of the platform in the joomla installation code!

1. Hashing passwords before submission.
Hashing of passwords using javascript on the client side to prevent

transmission of plaintext password through http is possible...

 

. However this is not possible to
implement for Joomla due to hashing being a one way street and such a
solution would break all backward compatibility.

I understand, but requiring a password change after the main upgrade is not so dramatic:
After upgrading to this kind of hash joomla can throw this message at first login:
"Your password is expired, a mail was send to you with a link to reset your password."

PS. Also a configurable password expire period to engourage periodic password change can be a good thing to implement in the core (prevents brute force).

Yes there are still issues with "cookie sniffing", but a
hacker having a plain text password is worse.

Also cookie sniffing can be made a litte bit more frustating for hackers:

Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session.

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

Yes this not prevent sniffing behind a NAT, but IPv6 is coming! 
Yes users can change IP and lose connection to the site but losing network connection is a network problem so user will not hate joomla for that.

 3. Preventing SQL injections and LFI's
> Agreed that blocking requests can result in disruptions of valid
> submissions (like when someone is discussing SQL injections in a
> joomla forum components). However the key is not to "block" requests
> but to "sanitise" the global variables.

I also thing that the better way to do that is "when it is used" so better to sanitize query in the joomla core database access classes, and a whitelist is better than a blacklist (this is a general rule of security).

I know it is an hard work to define a whitelist of permitted query to filter them in JDatabase class, but think also at awesome advantages the platform can take with such  a thing:

For instance this can be done defining a rule for extension developers: "you have to define a whitelist of regexp or rule for your sql queries in the extension.xml file" and  this will automatically implement also a nice feature possibility for the CMS, a permission request modal window for site admins: when he install an extension a list of used db parts (write / select) can be presented as a PERMISSION REQUEST like done in Android Market and similars for app permissions!  

for instance

This app requires following permissions:
- Read your user data  [required]
- Read/Write your articles data  [required]

- Read/Write your articles data  [required]

- Read/Write your modules        [optional]  

- Read/Write your k2_items        [optional]  

Do you want to install it?

This will be not so charging for the CPU because JDatabase class can filter a set of rules only for the current extension, so not so many rules, and this can help also to delete non used tables when unistalling an extension or maybe also in the upgrade process. Anyway i know this is an hard work  and requires hard case study and got risk to make things complex for developers (but, enforces them to code well thinking a little bit more on their SQL optimization and security)

PS. this structure can be also used to "profile" apps and database time.

Anyway, don't take me seriouly this is just an idea for.... 5.0?
-----
Another little security idea can be also an anti-bruteforce system, i mean to put in db temporary  table (a buffer table) a row with a date for each failed login for "user+IP" key and delay/deny login requests after 3 failed login requests, this also to notify administrators of bruteforce attacks (a similar thing is implemented in Moodle and works well).

Best regards,
Stefano.

2011/12/16 Andrew Eddie <mamb...@gmail.com>

[Andrew Eddie]

On 17 December 2011 00:39, Stefano Gargiulo <rast...@gmail.com> wrote:
>> Yes, but it's a trade off and no substitute for trying to keep sloppy
>> coders off the streets.
>
> Less of the 1% of the Joomla Extension Directory related websites uses
> HTTPS!
>
> So joomla extension developers are sloppy coders?

I'll take a note out of Nic's book and ask why are you putting words
into my mouth :) But to that comment, yes, some Joomla extension
developer are sloppy coders and in a perfect world it would be great
if the JED had the ability to "sniff" them out (pun intended).

> No, SSL is hard to configure well, if you don't think so please put it as a
> requirement of the platform in the joomla installation code!

Well yes and no, but my point was ensuring that Joomla is rock solid
when it can be used (which, at the very least, is any site with a
shopping cart).

[Marius van Rijnsoever]

Thanks for the reply Andrew. I have contributed code and lots of time
to the Joomla project in the past. But moved onto other projects as it
wasn't the best timing for Joomla to accept my help for various
reasons. I am happy to help out again, but want to discuss ideas first
avoid wasting everybody time (including mine) with additions that are
not required/wanted.

No doubt some of these ideas have been considered in the past and I am
sensing a slight reluctance to re-evaluate some of these ideas. You
bring up a couple of valid potential issues:

1. Performance.
Sanitation of variables with 2 regex' would make an insignificant
change to server load.

2. False positives
Sanitation of variables can be implemented with minimal disruptions.
For one it would not affect the Joomla CMS itself (you would exclude
joomla core components) and would also not involve the backend (hacker
can do easier things if a person was foolish enough to give him
access). This means that any new workload generated would be at the
address of the 3rd party developers. Not to insult anybody but with
the new release cycle every joomla release breaks backward
compatibility. This is actually a good thing, as this allows the core
to improve much faster and prevents massive changes in a single
release like Joomla 1.6. Joomla third party developers have had a lot
of curve balls thrown at them recently and if properly implemented
this will only be a very minor issues. For instance during an install
a component that needs to be excluded from global var sanitation would
just add its name to the sanitiser plugin exclusion parameter.

3. False negatives
This is really the sticking point of a proposal to do this. There is
no point implementing a regex filter, if hackers can bypass it by
changing UNION SELECT to UnIoN SeLeCt. There has been lots of work
done by other people on good hacking detection regex's. I would be
more than happy to go into more detail. But that would be irrelevant
if the Joomla Core team are not going to consider adding new security
features regardless.

Currently hacking Joomla is like shooting fish in a barrel with a
shotgun. And this has got nothing to do with core vulnerabilities or
script kiddies that waste time with automated attacks looking for
mambo era components. And you can see the appeal of shooting with a
shotgun to a 14 year old hacker. I don't want to give away and tips
that can get sites hacks, but here is a short summary to illustrate my
point. Hacker A wants to deface some Joomla sites and monitors sites
that conveniently report new Joomla vulnerabilities. He then uses
google using a simple search query to not only find Joomla sites, but
a detailed list of the x thousands of sites that run the vulnerable
joomla component. Then it is just a matter of running a simple hack
script and if that Joomla site has got no additional protection,
someone will spend a week trying to get their Joomla site back up.

I wish it was as simple as blaming a few bad coders, as the lists
shows it can happen to experienced developers. Even if only a dozen of
sites run a dodgy component, google will show up exactly who they are.
And joomla gets a bad reputation with those users, despite Joomla
itself having nothing to do with it. (they just say "I installed
Joomla and get hacked every time, Joomla sucks")

The aim of these discussions is not to stop all Joomla related hack,
but work on a way we can replace the "shotgun" of a hacker with a
regular "fishing rod"

What is your opinion on a JCrypt class Andrew? It could be easily
implemented to prevent plaintext passwords submission by default (even
joomla.org would benefit from this feature as it currently submits all
passwords as plaintext over http). If PHP has decryption libraries
available it would load additional javascript file. This would encrypt
the password with the public key, store it in a hidden encrypted
password field and erase the plaintext password. Then on the backend
if a encrypted password string is set, it would decrypt with the
private keyand login would run as normal. If Joomla has not got access
to decryption libraries, login would proceed as normal (no added
javascript loaded). The JCrypt class I started working on also takes
care of private/public key generation, encrypt/decrypt, etc. I stopped
work on it, because it would not be enabled on 100% of Joomla installs
by default (which used to be a deal breaker regardless). But it seems
from the new minimum requirements for the latest Joomla version that
this is becomming less of an issue.

Of course I am picking the worst time to bring this up again, as the
boat has departed for new features in Joomla 2.5 and time is required
by everybody to ensure a smooth release.

Thanks, Marius

[Marius van Rijnsoever]

Also I am not ignoring your detailed last post :)

Just need a bit of time to pull up some old posts and will reply in
detail later today.

Thanks, Marius

[Marius van Rijnsoever]

Also I am not ignoring your detailed last post Stefano :)

[Nicholas K. Dionysopoulos]

Marius,

Regarding false positives, you seem to assume that no harm is done if you modify the input data. It depends on what the input data is. If it's a forum post, it just completely changes the meaning of your words and may lead to misunderstandings. If it's an e-commerce system, it can have impact on your business. You should never sanitise input data you had no idea where and how it's going to be used unless you would like to bet your head that your sanitisation will not throw any false positives whatsoever. And you should always provide a way to work around the sanitisation if so desired by the developer. For instance, if I'm writing a forum software I know that the post may contain what looks like (or is!) SQL code, but I escape things properly before sending them to the db, so just give me the raw data.

Which brings us to the next point, false negatives. Obviously, having a trivial filter which can be tripped by camel casing is as good as having no filter at all. You need something which, at the very least, tries to be thorough, does not throw false negatives and does not throw false positives. Good news, I have already made it. It took me two days and it's the following beast (part of my for-a-fee software, distributed under the terms of the GNU General Public License, version 3 of the license or –at your option– any later version published by the Free Software Foundation, in case you want to use it in any of your projects):

#[^\s]*([\s]|/\*(.*)\*/|;|\'|"|%22){1,}(union([\s]{1,}|/\*(.*)\*/){1,}select|select(([\s]{1,}|/\*(.*)\*/|`){1,}([\w]|_|-|\.|\*){1,}([\s]{1,}|/\*(.*)\*/|`){1,}(,){0,})*from([\s]{1,}|/\*(.*)\//){1,}[a-z0-9]{1,}_|(insert|replace)(([\s]{1,}|/\*(.*)\*/){1,})((low_priority|delayed|high_priority|ignore)([\s]{1,}|/\*(.*)\*/){1,}){0,}into|drop([\s]{1,}|/\*(.*)\*/){1,}(database|schema|event|procedure|function|trigger|view|index|server|(temporary([\s]{1,}|/\*(.*)\*/){1,}){0,1}table){1,1}([\s]{1,}|/\*(.*)\*/){1,}|update([\s]{1,}|/\*[^\w]*\/){1,}(low_priority([\s]{1,}|/\*[^\w]*\/){1,}|ignore([\s]{1,}|/\*[^\w]*\/){1,})?`?[\w]*_.*set|delete([\s]{1,}|/\*(.*)\*/){1,}((low_priority|quick|ignore)([\s]{1,}|/\*(.*)\*/){1,}){0,}from|benchmark([\s]{1,}|/\*(.*)\*/){0,}\(([\s]{1,}|/\*(.*)\*/){0,}[0-9]{1,}){1}#i

Mind you, that regex can only be used to detect SQL injections. If you try to sanitise data with it… well, try it and you'll see for yourself :)

I can only see two problems with that:

a. it's humongous, therefore dead slow. More so when you have to run it for each COOKIES, POST, GET and REQUEST variable. Now you think that I'm an idiot. REQUEST includes POST and GET, right? Wrong. Try doing a PUT or a DELETE request, for example, and then we can talk about what REQUEST includes or not. We can also talk about input array precedence and how, because of it, a value in a cookie or a get variable could mask a post variable or vice versa. We can also talk about how JRequest allows the developer to choose the input array, leading to the need to scan all input arrays to prevent under-the-radar attacks.

b. It only works with MySQL's dialect of SQL. We'd have to invent one such regex for each supported database, meaning one regex for SQL server, one regex for PostgreSQL and so on. And we'd have to maintain them and sort out any false positives thrown. That's a might task. It took me two months and feedback from dozens of users to tweak my regex.

Ergo, achieving our quadruple goal (security, no false positives, no false negatives, performance) is not practically achievable. We'd have to throw in a compromise solution. With a world-class piece of software like Joomla!, this would mean that we'd ultimately like to err on the side of caution, allowing false negatives in order to have a more performant solution which doesn't hinder people with false negatives. This will give a false sense of security to our users. Now, that would be a perfectly valid reason to bash Joomla!.

In so many words I do agree that we're better off educating developers and throwing developers who never learn out of the JED. Any developer using an abomination like 'SELECT * FROM #__stupiddev_table WHERE id = '.$_REQUEST['id'] in his code should be lashed, tarred, feathered and kept out of the JED. OK, maybe not lashed, tarred and feathered, but definitely kept out of the JED!

Cheers,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Andrew Eddie]

Thanks for the replies Marius.

On 17 December 2011 12:58, Marius van Rijnsoever <mari...@gmail.com> wrote:
> Thanks for the reply Andrew. I have contributed code and lots of time
> to the Joomla project in the past. But moved onto other projects as it
> wasn't the best timing for Joomla to accept my help for various
> reasons. I am happy to help out again, but want to discuss ideas first
> avoid wasting everybody time (including mine) with additions that are
> not required/wanted.

Sounds like a plan.

> 1. Performance.
> Sanitation of variables with 2 regex' would make an insignificant
> change to server load.

See Nic's reply for holes in the theory. The problem I see is the
hackers will crack the regex, so you have to add another, and then
close another hole, and fix a crack, and it spirals out of control.
Maybe I've got blinkers on but I can't get past the fact that you
aren't dealing installing bad code on your server as a preventable
event.

> 2. False positives

> Not to insult anybody but with
> the new release cycle every joomla release breaks backward
> compatibility. This is actually a good thing, as this allows the core
> to improve much faster and prevents massive changes in a single
> release like Joomla 1.6.

That's not correct. 1.7 didn't break backward compatibility (ok,
there was one case with the query class where developers didn't head
out instructions), nor will 2.5. Every third release (18 months of
time) allows for the potential to break backward compatibility but
that does not necessarily mean it will happen (the next window for
this is 3.0 in July-ish 2012 should the community wish to take
advantage of it). Also note that breaking backward compatibility is
different from a deprecation strategy which you can find in both the
CMS and the Platform. I'm not sure where you got the idea that every
release under the new system breaks backward compatibility.

> Joomla third party developers have had a lot
> of curve balls thrown at them recently and if properly implemented
> this will only be a very minor issues.

Recently as in the release of 1.6 (over 11 months ago now) or are you
thinking of something else?

> For instance during an install
> a component that needs to be excluded from global var sanitation would
> just add its name to the sanitiser plugin exclusion parameter.

I can't help but think we are really starting to add complexity that
outweighs the alleged benefit.

> 3. False negatives
> This is really the sticking point of a proposal to do this. There is
> no point implementing a regex filter, if hackers can bypass it by
> changing UNION SELECT to UnIoN SeLeCt. There has been lots of work
> done by other people on good hacking detection regex's. I would be
> more than happy to go into more detail. But that would be irrelevant
> if the Joomla Core team are not going to consider adding new security
> features regardless.

The PLT (there has been no such thing as a core team for many years
now) are the people that "approve" features that are submitted (and
most reasonable contributions are accepted nowadays). I say this at
every Joomla Day or event I speak at that you are looking at the
Joomla development team right now (especially when you stand in a
mirror). Your peers are ultimately the people who make or break
contributions, not the PLT.

> I wish it was as simple as blaming a few bad coders, as the lists
> shows it can happen to experienced developers. Even if only a dozen of
> sites run a dodgy component, google will show up exactly who they are.
> And joomla gets a bad reputation with those users, despite Joomla
> itself having nothing to do with it. (they just say "I installed
> Joomla and get hacked every time, Joomla sucks")

I appreciate the intent behind your statement, and understand that
notion that the mud "sticks" despite our best efforts, but I still
maintain this is a "latex barrier" (keeping it G-rated) for
fundamentally fertile code problems. Ok, let's imagine we do get a
"fire wall" solution that everyone agrees on. That cannot be the only
thing we do to enhance security and should be just one part of a wider
strategy that **must** include developer education as the first line
of defense. It should also include a review of automated test
resources that could be used freely by developers and/or added to the
JED (something like an automated report card), and also a review of
how we can make alerting web masters about urgent upgrades quicker.

Personally I'd start with the IP range blocker part and get that rock
solid before adding any trip wires.

> What is your opinion on a JCrypt class Andrew?

We need it. Raise it on the Joomla Platform list - there are already
people working on it.

> Of course I am picking the worst time to bring this up again, as the
> boat has departed for new features in Joomla 2.5 and time is required
> by everybody to ensure a smooth release.

It's never too late for the Plaftorm because we are on a shorter
release cycle, which some of this work would cover. I'll just warn
you now, get up to speed with PHP Unit and PHP Code Sniffer first. We
are unashamedly pedantic about our code quality :) Maybe we should
make it a requirement that every developer that wants to list on the
JED must have already submitted at least 500 lines to the platform,
because then we then know they've been through the code-quality
wringer :)

[Lloyd A.Shepherd]

I have tried at least 20 times to be removed from this group.  Would someone remove me from the group manually?

[Nick Savov]

haha, funny pun :)

[G. D. Speer]

"Maybe we should
make it a requirement that every developer that wants to list on the
JED must have already submitted at least 500 lines to the platform,
because then we then know they've been through the code-quality
wringer :)"

While I know you were facetious about this, I would love to see Unit/Sniffer
compliance as one of several requirements for a JED 'Certified' rating! One
can dream.

----- Original Message -----
From: "Andrew Eddie" <mamb...@gmail.com>
To: <joomla-...@googlegroups.com>
Sent: Saturday, December 17, 2011 3:36 AM
Subject: Re: [jcms] Salted MD5 login to prevent sniffing in non https

[Marius van Rijnsoever]

That is a cracker of a regex Nicholas and should pick up almost all
SQL injection attempts, but like your pointed out the higher the
pickup rate the higher the false positive rate. A Joomla firewall
would not be a "black box" that developers have no control over.
However since a "compromise solution" of a firewall to prevent attacks
seems unlikely to be implemented we should then focus on minimising
the impact of vulnerabilities.

There has been some great work done on a "joomla version check on
admin login" to highlight to a user that they should upgrade Joomla.
The same can be done to notify users of vulnerable components, as the
JED already has an entry in the "joomla core update" table. Once a
vulnerability is known, it can be added to this JED XML and
administrator of that site will then receive alert/email about the
vulnerability through the Joomla backend. This will minimise the
impact of vulnerabilities by alerting users fast.

Since your brought up a medical comparison and I am a Doctor by day
(geek at night), I will also make a medical comparison. When an
overweight type II diabetic person comes to see me for treatment,
loosing weight will likely cure the diabetes (yes I have seen this
happen many times) and is the ideal solution. If I send the patient
home with the message "loose weight and you will not have a problem",
likely the next time we will see him is when his vision is affected,
had a heart attack or his kidneys have been damaged. The same goes for
your suggestion of only using SSL to prevent plaintext passwords
transmission. Its the ideal solution, but 99% of people will not
implement it and the next time we will hear from them is when their
site is hacked.

Implementing plain password transmission for non-SSL users would not
be a half baked solution, but a realistic basic protection for the 99%
of Joomla (millions of them) sites that do not have SSL. I don't agree
that this would induce complacency and therefore stop people
implementing SSL, as people that care about security will implement
SSL regardless. Also many people are unable to install SSL for many
reasons. Therefore the advice "SSL or no password protection" would
equal saying to a patient "Yes you can't loose weight easily because
you can't exercise with your bad knee, but I am not going to give you
diabetic medications as this is not perfect".

http://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_1.7_and_Joomla_Platform_11.2
I did not bring up the backward compatibility issue as a negative
comment. I rather have 99% compatibility (see above link for minor
incompatibilies between 1.6/1.7) and advancement of the core. Than 80%
compatibility with every 3 year release and slower progression. I
brought this up to highlight that current developers for Joomla 1.7
and later are involved due to the advancement of the Joomla core.

OK I also managed to find the previous proposed solution that hashes
the Joomla password that requires no updates of the Joomla database at
all. This would avoid users having to reset their passwords:
http://groups.google.com/group/joomla-dev-general/msg/f91741e9406035dc
(lots more discussion on Joomla security on that thread when I offered
to create some new Joomla 1.7 features back in February).

With regards to brute force password protection suggestion, there is
already a basic patch on the Joomla tracker (created by someone else).
But that had the problem of being easily bypassed. A new Joomla table
would likely be required for such a solution and IP based blocks can
also be bypassed by attackers (either spoofed or these bot nets have
access to thousands of IPs).

Better screening of code from JED components would be nice, but
sniffers would not work and the poor JED staff are already working
extremely hard and would not likely have time to properly implement
code screening.

Thanks again for everybodies input, hope I did not offend anybody with
this post. Thanks Marius

[Nicholas K. Dionysopoulos]

Hi Marius,

On Monday, 19 December 2011 at 06:06, Marius van Rijnsoever wrote:

However since a "compromise solution" of a firewall to prevent attacks

seems unlikely to be implemented we should then focus on minimising

the impact of vulnerabilities.

That's why there are only a handful of firewall component out there. And the reason we get rave reviews about them is because we do a LOT of support and receive massive amounts of feedback. This is not something we can do very efficiently with the core (there is always a huge gap between the users and the developer, bridged by multiple layers of volunteers) . So, yeah, we'd better fix the cause of the problem instead of treating the symptoms.

There has been some great work done on a "joomla version check on

admin login" to highlight to a user that they should upgrade Joomla.

The same can be done to notify users of vulnerable components, as the

JED already has an entry in the "joomla core update" table. Once a

vulnerability is known, it can be added to this JED XML and

administrator of that site will then receive alert/email about the

vulnerability through the Joomla backend. This will minimise the

impact of vulnerabilities by alerting users fast.

The same patch which notifies users on core updates also notifies them on extension updates. I would argue AGAINST having VEL (I had to correct you: JED has nothing to do with marking vulnerable extensions, it's VEL that does that) produce an XML feed. Most of the times VEL authors are not sure what is the component's installation name (e.g. com_foobar), if it name-conflicts with another extension, or even which versions the attack affects. I would hate to see, let's say, Akeeba Backup 3.3.10 being uninstalled or blocked from a user's site because there is a known low-priority vulnerability in 3.0.a2 which can't even be used to compromise a site. That would be stupid on the project's part, a disservice for the users and a disaster for me. It's easy to screw up when an "Authority" notifies users that their software is insecure. Even in the event of a false alarm, it completely destroys the implicit trust between developers and users. It would eventually widen the divide between the project and developers, causing worse cases of "us against them" than we've ever seen in the past. You have to be VERY cautious with those things, Marius.

Just to give you an example. There is no Operating System vendor whatsoever who'd cause one of their user's computers to display a warning with a wording in the likes of "Software X you have installed on your computer is insecure; please uninstall it immediately". Have you ever wondered why? Exactly.

Implementing plain password transmission for non-SSL users would not

be a half baked solution, but a realistic basic protection for the 99%

of Joomla (millions of them) sites that do not have SSL. I don't agree

that this would induce complacency and therefore stop people

implementing SSL, as people that care about security will implement

SSL regardless. Also many people are unable to install SSL for many

reasons. Therefore the advice "SSL or no password protection" would

equal saying to a patient "Yes you can't loose weight easily because

you can't exercise with your bad knee, but I am not going to give you

diabetic medications as this is not perfect".

You have never published an extension and done support, right? No, I don't mean that as a derogatory remark! I will tell you what my experience is. For years, my backup software supported automation via CRON jobs using the front-end backup method. I also added another two CRON-compatible CLI scripts for my paid users. However, many users complained that they didn't have CRON and they wanted a workaround. I gave them the option to use webcron.org. It wasn't enough for them. So, I created a plugin which has 13 very grave known issues on most sites, but does work fine on a handful of other sites. I published it with a big fat warning cautioning users to NOT reply on it, being upfront that it is NOT supported and I can NOT fix the known issues (which I linked to). Result: Nobody read the warnings. They demanded support. And they asked me to fix the known issues. Aaaaaaargh!

Would you give your patient a drug which cures the diabetes symptoms and allow them to consume truckloads of sugar every day? I don't think so. Would you give him the drug and pass him a 678-pages book which says "do not eat sugar" in a footnote in page 436 and expect the patient to figure it out yourself? Because that's what you're doing when you disseminate Joomla!. Assuming that users will (or even can) read instructions and warnings and understand the minute difference between SSL and partial login form encryption is a naive leap of faith. What users will understand is "you don't need SSL, use this encryption thingie, it's using the same encryption algorithm". A half-baked solution which gives a false sense of security is never substitute for proper user education.

OK I also managed to find the previous proposed solution that hashes

the Joomla password that requires no updates of the Joomla database at

all. This would avoid users having to reset their passwords:

http://groups.google.com/group/joomla-dev-general/msg/f91741e9406035dc

(lots more discussion on Joomla security on that thread when I offered

to create some new Joomla 1.7 features back in February).

Have you tried implementing it? I can see a few practical problems, the most obvious of which are a. having PHP generate PK pairs on the fly (ergo, need of a SECURE random number generator) b. making sure JS and PHP can encrypt/decrypt each other's messages (not that simple!) c. making sure that the PHP side of the algorithm does not depend on mcrypt, because it's not available on all platforms and hosts and d. making sure that using PK cryptography does not violate local laws pertaining to the use of cryptographic algorithms around the world. Especially regarding the latter, there's not a cat's chance in hell of achieving it. If you include source code for PK cryptography, you can no longer re-import the source to US, effectively disallowing the use of Joomla! in the US. There are also an array of issues with EU countries' legislation regarding cryptography. Essentially, we'd have to host all of the project's infrastructure in somewhere like crypto-neutral Switzerland, but we'd still have a problem with legally using Joomla! in the US. It's a non-solution to boot.

Better screening of code from JED components would be nice, but

sniffers would not work and the poor JED staff are already working

extremely hard and would not likely have time to properly implement

code screening.

It's funny that you suggest that, because SQL injection prevention is a sniffer, too. It tries to figure out if some piece of data it doesn't know how it's going to be used looks like a SQLi attack, is a SQLi attack and try to figure out what to do with it. So, I'd suppose you blindly trust any sniffer. But you don't. See my point about why SQLi detection is a bad idea? The same heavy burden you'd have to deal with in JED would be offloaded to the shoulders of each and every Joomla! user. And I can bet that they're much less tech-savvy than our JEDis.

[Andrew Eddie]

On 19 December 2011 18:03, Nicholas K. Dionysopoulos

<niko...@gmail.com> wrote:
>
>> Better screening of code from JED components would be nice, but
>> sniffers would not work and the poor JED staff are already working
>> extremely hard and would not likely have time to properly implement
>> code screening.
>
> It's funny that you suggest that, because SQL injection prevention is a
> sniffer, too.

^^^ What he said. We have lots of "sniffers" already working
extremely well on the platform doing some pretty crazy things with
automated code review. Nothing is impossible.

There are also ways around the JED staffing issues - but for the sake
of this argument, just imagine there is no barrier to resource the
coding of sniffers and enough people to maintain the volume of work to
support automated (just as you are assuming there are enough people on
the JBS to handle the incoming glitches of an on-the-fly solution).

[Nicholas K. Dionysopoulos]

Andrew,

The unit testing is not a contextless sniffer. A human has gone into the trouble of understanding how the unit works and wrote a test for it, providing the context. What Marius was implying is a generic sniffer, which can evaluate if a piece of arbitrary PHP code is potentially vulnerable. Can you really write a sniffer for that? I mean, generally, using eval(base64_decode($var)) is mostly used in hacking scripts, but I can think of a valid use for it: allowing administrators to create custom reusable snippets for use in the front-end. Depending on the implementation, it can range from very secure to an open invitation to crackers. I seriously doubt a sniffer could discern between the two cases and I strongly doubt that JED would do either.

I mean, come on, they have rejected an extension of mine because I did not have index.html files in a directory where all PHP files would only give a blank page when accessed directly over the web. JEDis treat sniffer results like a holy scripture (and, frankly, I don't think they can do otherwise). Developers could end up working around the sniffer, producing less secure code in the process. I know that a sniffer raising a flag for base64_encode/_decode would flag my extensions. I use that when encrypting configuration data before storing them to the database or a PHP file. The easy workaround for such a sniffer would be to not encrypt the data. Would that increase the security of my extensions or diminish it?

The other sniffers used in the Platform have to do with code style which doesn't have to do with how the code works, but how it looks like.

Let me reiterate: you can not expect a contextless, generic sniffer to work without a human evaluating the results. In practical terms, this requires a few dozens of experienced developers doing peer review every time an automated sniffer raises a flag. This is impractical. It will cause false positives with serious impact for developers and developers will have every right to then complain that the JED process is broken.

PS: I have written a PHP code sniffer which tries to figure out if an arbitrary block of PHP code is potentially malicious or not. It works brilliantly against malicious scripts (95% detection), but has a 3% false positive rate. I can lower the false positive rate, but the detection rate falls below acceptable levels. There's no way we can create a sniffer so good as to substitute manual code auditing. That's the Holy Grail of software engineering, isn't it?

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Marius van Rijnsoever]

>You have never published an extension and done support, right?

You did not read my last email on how I have been developing and
supporting (for free) an extremely complex Joomla component for the
last 5 years? I know from lots of painful first hand experience that
users will screw up and disregard all instructions no matter how
clear. No need to try and strengthen your argument by belittling my
understanding.

What I find interesting is that on one hand you say "people will never
follow instructions" and on the other hand believe that they will
follow your security advice about SSL.

Yes I do give life saving drugs to patient even if they contribute to
the issue themselves (you would not expect me to do otherwise huh?),
while educating them how to improve their health! I even give drugs to
people that will unfortunately will prove fatal for some. I deal with
very complicated risk assessments on a daily basis and if I screw up,
someone can die because of my decision. For instance when I prescribe
warferin (rat poison) to someone with a stroke risk, I will cause a
possible fatal brain bleed in 1-in-300 patients, but prevent strokes
1-in-25 patients and prevented death in 1-in-40 patients. The overall
benefit far outweighs the risk.

Lets do a risk benefit analysis for implementing a method to prevent
plaintext password transmission. There are at least 1,651,338 Joomla
websites on the web (http://trends.builtwith.com/cms/Joomla!). My
guess is that 99% of Joomla installations do not run SSL (none of the
top 10 websites do http://trends.builtwith.com/topsites/Joomla! and
even joomla.org does not run SSL). Therefore there are at least
1,634,824 joomla websites that transmit plaintext passwords across the
internet. That means that Joomla is indirectly responsible for tens-
if not hundreds-of- millions of plain passwords being transmitted
through the internet every day. Therefore there is clearly a large
impact we as Joomla developers can have on fixing this.

Your main concern is the "risk" that people will not implement SSL if
some basic protection is added to the login form. First point to make
is that currently people do rarely use SSL (see above). Second like
you pointed out, people will ignore instructions anyway (including
advice to use SSL). People that do implement SSL won't stop doing this
because of a login form password encryption. Therefore the risk of
causing harm by implementing this feature (by making people
complacent) is very low.

The next point of discussion would then be the actual impact of an
added security feature (no point giving someone a pill if it does not
do anything). Like you pointed out without SSL it would still be
possible to hijack the cookie/session. Lets take a real life scenario:

Editor of a joomla site gets a cup of coffee from a local shop and
quickly checks his website through an unsecured wifi connection.
1: No SSL, No plain password connection
Hacker gets plain password. Creates itself a new administrator
back-end session, get access to file system and does lots of damage.
Then because most people share passwords between sites, the editors
email gets hacked and the hacker gets some more passwords from his
email account.

2: No SSL, Password is encrypted
Hacker gets access to the front-end session and defaces the website
with lots of hacker messages. Administrator sees this takes the
website offline. Hacker can't repeat the attack as the session will
then have expired.

3. Webmaster has installed SSL
No problems what so ever as password and session cookies are
protected. Yum, editor finished coffee and everybody is happy :)

Option 3 definitely preferred. But there is a huge difference in
damage between option 1 and 2. Also to consider in this equation is
the end-users of each individual sites. Their plaintext passwords are
exposed because of millions of Joomla websites without SSL (not just
an issue that affects the webmasters) and can compromise their other
accounts..

Lastly to consider is the costs of the implementation. It is 100%
backward compatible, some extra javascipt and processing required at
the browsers end. However login will still work when javascript is
disabled (but password won;t be encrypted), Also to consider is the
positive effect of having a JCrypt library in Joomla and a working
example that developers can see. This will allow Joomla developers to
have 128 bit encryption available even if the site does not have SSL.

Just to summarise. Plaintext password transmission on Joomla site are
extremely common, accounts for millions of plaintext passwords being
transmitted every day and a solution is simple to implement without
any costs, but does not protect for the separate issue of session
hijacks. If you ask me this is as good as a risk-benefit assessment as
you can get, But maybe people other than yourself and me can comment
on this?

With regards to notifying users of vulnerable extensions, I never said
anything about blocking and disabling extensions automatically.
Extensions are already "named and shamed" through google and there is
a list on the joomla.org website that lists. Identification of
components can be done very accurately as there are more identifiers
that "com_example". I FULLY agree with you that extreme caution must
be taken with the approach and implentation, but this can be managed
very well and has the potential to prevent a large amount of Joomla
hacks.

Thanks, Marius

[Andrew Eddie]

Nic, I'm thinking start small, not go for the Taj Mahal in the first iteration. A sniff to detect the absence of the use of any database quote method would be a good start. Missing define or die, another. Using global is generally considered sloppy, and so on.  Code style is not a bad thing either because neat code is easier to debug.

Regarding how the JEDi's bedside manner and how they should react to such reports, that's another topic for another day (my blood pressure is happy at the moment and I'd like to keep it that way). Suffice to say, the results should at first generate a score which is public. If it was out of 100 you'd try and make it so anything above 75 was a high level of confidence sufficient to overcome any false negatives. You then just let that score naturally encourage developers to improve their work. Over time you might get some reliable sniffs that can be used to bounce code, but that's definitely not where you'd start. Baby steps.

Regards
Andrew Eddie

[brian teeman]

Just to point out that the majority of joomla sites (and as you brought up numbers thats what matters) are running on shared hosts and the majority of shared hosts do not have the ability for you to run a domain specific ssl. If every web site in the world that required a login used ssl and joomla sites did not then this would be a bad omission by joomla. But that's not the case. Feel free to recommend that people install ssl certificates etc but this is definitely not something that should be forced upon them by joomla itself as that would prevent the majority of users from installing joomla.

[Nicholas K. Dionysopoulos]

@Andrew Please do take a look at Akeeba Backup. Since the backup engine is cross-CMS it uses its own database class with a slightly different naming convention than Joomla!. Of course I quote everything before sending it to the database (or cast to an integer type, where applicable). My code is secure, but the sniffer would report it as insecure. Essentially, such a set of sniffs would report my perfectly secure extension as a piece of crap. You can guess what I would do :)

@Marius I will make two points:

1. Up until a few months ago, Facebook, Google, Twitter did not use SSL at all. There are thousands of smaller sites not using SSL at all, either. As Brian said, it's not a problem unique to Joomla! and should not be treated as such.

2. You forgot the major issue. Implementing public key cryptography bears legal implications. The laws pertaining public key cryptography vary widely among countries. Including PK in Joomla!'s core may cause use of Joomla! illegal in some jurisdictions. It's best to ask a lawyer before doing so. Symmetric cryptography of low strength seems to, however, be legal in most parts of the world but, again, I am not a lawyer.

Cheers,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

On Monday, 19 December 2011 at 14:50, brian teeman wrote:

Just to point out that the majority of joomla sites (and as you brought up numbers thats what matters) are running on shared hosts and the majority of shared hosts do not have the ability for you to run a domain specific ssl. If every web site in the world that required a login used ssl and joomla sites did not then this would be a bad omission by joomla. But that's not the case. Feel free to recommend that people install ssl certificates etc but this is definitely not something that should be forced upon them by joomla itself as that would prevent the majority of users from installing joomla.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/UJ-NoyGUHx4J.

[Ian]

Back in my Perl days I remember running into an issue with taint mode.  I didn't really understand it at the time but sometimes I think it would be really neat if somebody developed it for PHP.

Would provide some useful metrics.

Care must be taken though - I remember when I was on JSST it would not be unusual to receive an email saying an automated penetration testing tool had found an issue that didn't exist.  The problem is there are a lot of crappy security tools out there.

Ian

[Ian]

I meant to provide a link to information on taint mode.

http://gunther.web66.com/FAQS/taintmode.html 

Ian

[Herman Peeren]

Just read this thread now. I don't want to hook into the whole discussion about SSL etcetera, that is all fine, but want to add something that is related to the title and the original posting. Shortly after JAB10 (where I showed in a talk how shockingly easily passwords on a conference like that can be sniffed with WireShark... that program had been running during that whole event. BTW the video of my talk was edited on my request to leave that part out) Niels and I worked something out to work in Joomla without altering the db, without private/public key and with a password hash. That principle is what Niels is pointing at in http://groups.google.com/group/joomla-dev-general/msg/f91741e9406035dc (the link Marius refers to too). It has nothing to do with private/public key encrypting (what I read in Nic's reply).

The key of what we did and which I actually implemented (very simple!): the salt, with which the password is hashed in the db, is being retrieved from the db (using Ajax) as soon as the username-field is left (if that username is not found a "fake" salt is sent to the client). After that it is easy to hash the password with it (and with the token, so it is double hashed). The switch in my thinking about this was: the salt in the db is not something that must be kept secret! First retrieving the salt and then double-hashing the password is an easy way to avoid plain text passwords and still use hashed passwords in the db.

Didn't check it lately, but back in 2010, when we were working on this, Drupal and Wordpress also sent their passwords in plain text. Maybe we should project all those easily retrievable passwords on the main screen on some major conferences to get everybody aware of how stupid it is to send plain text passswords (and of course: tell everybody how easy it is to avoid it). Personally I use Ratmil's Encryption Configuration plugin (which uses RSA) on every Joomla-site I build if SSL is not possible or a bit of an overkill. Firstly because the default login can be used and secondly because the plugin can be used for any field you want to be encrypted in this way. So I left that piece of code with the double hash in the lab.

I'll dig up the "double hash"-code and publish it. Maybe it is still usefull.

[Marius van Rijnsoever]

@ nicholas
I am well aware that certain countries restrict the use of encryption
(Iran for example) or even the export of encryption code. However some
countries like the US mandate (at least some states) that personal
information (which includes passwords) is transmitted through the
internet in a secure fashion. Therefore there are legal implications
for not implementing this as well. But since we both are not lawyers,
we should ask people with the required legal expertise to give their
opinions. Preventing plaintext password transmission through non-SSL
protocols is not new and many other softwares do this (and I am
unaware of any legal ramification by implementing this).

Yes Herman your solution works as well, that why I had to post a link
to your previous post.

I do not have a personal preference on the method of adding basic
protection to passwords (either encryption or hashing) and will rely
on the Joomla core developers to make up their mind on what solution
is good enough for the core. But with 10,000,000's of Joomla plaintext
passwords going through the internet each day (which are easy to
intercept like Herman mentioned), we have a moral obligation to
improve on the current situation.

Thanks, Marius

[Andrew Eddie]

On 20 December 2011 11:36, Marius van Rijnsoever <mari...@gmail.com> wrote:
> I do not have a personal preference on the method of adding basic
> protection to passwords (either encryption or hashing) and will rely
> on the Joomla core developers to make up their mind on what solution
> is good enough for the core.

What did I tell you about looking in the mirror for the Joomla core
developers? ;) Seriously though, I think the best way forward is to
break this whole conversation into parts. Cryptography and SQLi are
completely different fish so I think it's best to separate them.
Marius, I suggest you start a thread on the platform list about crypt
support in both PHP and JavaScript sides of the platform. I know
Louis is tinkering with a new PHP crypt package. Rouven would
probably be interested in the Javscript side. Once there is a rock
solid API it's then it simply becomes a matter of implementation.
That's where I'd start anyway.

[84.le0n]

Hi all,
this mail doesn't want to start security discussion again, it's only
to tell you that some days before this discussion starts I've talked
with Elin about trying to merge that plugin inside CMS or platform,
studying if there's a real improvement doing this.
After some days you've started this interesting discussion, I'm
interested in it so don't hesitate contacting me when you'll start
working on JCrypto or other interesting things resulted from this
discussion.

Thank you,
Eng. Gabriele Pongelli.

[Herman Peeren]

A big advantage of client-side hashing of the password is also, that no administrator of a site can intercept the plain-text password. At the moment, anyone who has rights enough to install extensions on the administrator-side can easily see all passwords during the login (just make an authentication-plugin e.g.). As mentioned before: a lot of people use the same password for different sites. Such a passwords sniffing can be done by someone who breaks into a site, but a site could also easily be created specially for this purpose... And SSL doesn't help anything against exploits like this (the contrary: a certificate would make the site more trustworthy. But you still don't know what could be done with your "bare" password server-side). If I know my password is hashed before sending, then the risk of it being intercepted server-side is more of the theoretical kind.

Anyway: in the attachment some codesnippets I have sent June 9, 2010 to Chris Davenport, Niels Braczek and Ratmil Torres. It is some raw code, sent privately not published, not production-ready (!). It was just to see if the general principle works; and it does. MD5-password encryption of the login, with the salt retrieved from the server with an Ajax-call. Maybe I'd work it out to a more general safer Joomla-login this week, for it would be an easy way to get a lot more safety in Joomla soon; what do you think?

In the attached code snippets (code and these remarks are unchanged since June 2010; was for J! 1.5.x):

1. modifications in administrator/modules/mod_login/mod_login.php:
   a) changed onclick="login.submit();" in onclick="encryptpw();"
   b) added a reference to the md5-function.
   c) md5-encrypt the password before submission; uses Ajax-call to get the salt

2. MD5-routine downloaded from http://pajhome.org.uk/crypt/md5/instructions.html

3. com_salt: gives back the salt (in JSON-format). Not done in MVC now (as is not uncommon for a simple Ajax-routine).

4. plgPwencrypt: authentication-plugin to verify the encrypted password

Some remarks, things I learned:

• the Ajax-handling component cannot be in the administrator-part if you want to use it to log in into the backend (for you can only use a backend component if you are allready logged in).
• I used Mootools for the Ajax-call. It is standard in the standard administrative templates.
• I was a bit surprised to find that MD5 is not standard in Javascript. I used the routine from pajhome.org.uk (and it works). There seems to be a Mootools plugin too.
• originally we had planned to also use a token with the Ajax-call. I left it out, as it also appeared to need another token than the one in the form. Of course I'm keen on keeping the Ajax-call safe too. The username should probably be filtered further in a production environment.
  
• during the login you have a token and during the session, once logged in, another.
• there is a session-token and a form-token (derived from the session-token and combined with the config.secret and the userid)
• don't forget to activate the authentication-plugin after installing.

[Ian]

On Wednesday, 21 December 2011 01:30:07 UTC-5, Herman Peeren wrote:

A big advantage of client-side hashing of the password is also, that no administrator of a site can intercept the plain-text password. At the moment, anyone who has rights enough to install extensions on the administrator-side can easily see all passwords during the login (just make an authentication-plugin e.g.). As mentioned before: a lot of people use the same password for different sites. Such a passwords sniffing can be done by someone who breaks into a site, but a site could also easily be created specially for this purpose... And SSL doesn't help anything against exploits like this (the contrary: a certificate would make the site more trustworthy. But you still don't know what could be done with your "bare" password server-side). If I know my password is hashed before sending, then the risk of it being intercepted server-side is more of the theoretical kind.

Let's be clear though that this only changes that problem and doesn't solve it.  If I can install extensions I can just as easily install an extension that sends passwords cleartext in addition to or instead of the hashed password.  Also note that with hashing alone you still have to send the password in plain text at some point.

Ian

[Nicholas K. Dionysopoulos]

Not to mention that requiring the password to be hashed has some grave drawbacks:

- Login without Javascript activated on the client side is no longer possible (say goodbye to 10% of your visitors)

- Any extension implementing its own login form is now broken

- All existing code dealing with user authorisation breaks

- All existing code modifying directly the users table (e.g. password reset forms offered by hosts, backup restoration scripts, etc) not only stops working, it actually breaks the site

Moreover, if someone can install an extension on your site, he might just as well do whatever he wants on that site. Finally, if I were a terribly evil site owner, I would simply have the user registration email message (the one with the password in cleartext) be forwarded to my inbox.

Can we please all move on to some realistic problem which needs a solution instead of wasting our brainpower on a witch hunt? Thanks.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/yo1NvmCizAEJ.

[Stefano Gargiulo]

Sending emails with cleartext password is so unfrofessional please  just remove almost this feature and replace it with a reset link (no mainstream website still sends cleartext password via mail this is a privacy and security issue)

Is this feature useful? i don't think.

javascript is disabled on 10% of user browsers? i don't think in the facebook and html5 era.

Best regards,
Stefano

[Nicholas K. Dionysopoulos]

Stefano,

You'd be surprised! Depending on your site's niche, it is possible that the majority of your users have IE6 with JavaScript turned off (enterprise visitors). Also, many people DO have JS enabled for FaceBook, but turned off for every other site. You've heard about the Firefox plugin called NoScript, right? Many people do use it. If you ask them to turn on Javascript so that they can log in in order to leave a comment on an article, subscribe to your site or something like that, the chances are these people will simply navigate away to another site. Oh, BTW, the 10% is not a random figure; it's a rounded value of what I observe on my sites (8.5-9.6%). Anyway, don't assume anything about the capabilities of the visitor's browser.

Regarding the emails, as of Joomla! 1.6 you can simply override the language strings of the emails to not include the password. But, no, it's not unprofessional, unless you assume that thousands upon thousands of non-Joomla! websites doing the same thing are all unprofessional.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Herman Peeren]

Not true:

• "still have to send the password in plain text at some point" (you can first hash it clientside, also the first time and then send it)
• "all existing code dealing with user authorisation breaks" (no, the Joomla authentication is cascading: if one fails the next is tried, so non-hashed login would still be possible)

When I wrote the code, I had the administrator-backend in mind: it is not useful to login there without JS. I suspect, that the 10% non-JS is more a figure for visitors in general  (including all kinds of bots) then people who need to login.  I don't need customers without JS and neither do my customers. More: read the posting from Niels referred to above: he also gives an option how to handle when no JS is available. You can use the next authentication in the plugin-cascade. 

Why is the password in the db hashed? Because if someone would get those data (s)he could easily retrieve the password. BUT: if someone can sniff around in your db, is it not probable that (s)he could then also install things on your site? As you say: then they can do anything they want. Ergo: the whole hashing of the passwords is a bit of a  fake security. You must first of all avoid that someone who is not allowed to get those data, would ever get them.Still I think hashing the password in the db can add a little bit to security. And along the same line of thinking I think the hashing of passwords over the line can add even more to security, I think.

When I was studying the authentication-methods in various webservices, it was very obvious and general accepted that a plain-password login (or equivalent to that like base64 in Basic authentication) should never be done on a public available network without SSL. That is why Digest authentication etc. was invented. When I learned about those CMSs throwing around passwords in plain text I first couldn't believe it. This is not some theoretical point, this is a major security issue. You can wait for the disasters to come (or take action).

What is important? Some people think security for Joomla has increased by using other prefixes in the db. I think most Joomla SQL-injection in Joomla-extensions will use the general #_ prefix. Still Nicholas called changing the prefix "one step closer to fending off attacks by potential hackers". Trying to find some good solutions for plain passwords over the line on the other hand by him is called an unrealistic problem which wouldn't need a solution,  a waste of our brainpower and a witch hunt. Sorry dear friend, I like you very much and it is nothing personal, but I really think you are not seeing things in the right proportions. But I won't waste my time on arguing in this way anymore. Let's code something useful. If you don't want to use that: don't.

[Nicholas K. Dionysopoulos]

Hi Herman,

Please note that I called the attack unrealistic not because it's not possible, but because it's improbable. Man in the middle attacks require stalking (being on the same network) or advanced techniques (DNS poisoning) to succeed. I strongly doubt that anyone would go through all that trouble unless he's a security researcher or expects to make tons of cash. Regarding the latter person, he'd only attack high value targets. If someone has such a site and is not already using SSL he's a bloody moron, fair and square.

I would also like to point out two assumptions you made:

• SQLi attacks using #__ are far more common than those using jos_. This is contrary to every single log file I've seen from real world sites.
• Man in the middle attacks are at least as common as other hacking methods (otherwise I would be right in saying it is an unrealistic attack). Again, experience shows the exact opposite.

Finally, I will tell AGAIN that even if you'd like to ignore all of my points and I were just a bitching schmuck, you still have one MAJOR problem in including something like that in Joomla!: cryptography laws. Everybody seems to be oblivious to the fact that this would make Joomla! illegal in many countries all over the world. People, that's a MAJOR concern and none of you even gave it half a sentence in your replies.

Now, I've got more important things to do and I bet you do as well. Happy coding!

[brian teeman]

Completely offtopic but I'm still to see my first realworld sqli attempt using #__ 

[Niels Braczek]

Am 21.12.2011 18:49, schrieb Nicholas K. Dionysopoulos:
> Hi Herman,
>
> Please note that I called the attack unrealistic not because it's not
> possible, but because it's improbable.

Ever used WireShark on a barcamp? I demonstrated the issue lately by
excluding half a dozen Joomla admins from their sites. No efford, every
child (with a laptop) can do this.

> Man in the middle attacks
> require stalking (being on the same network) or advanced techniques
> (DNS poisoning) to succeed. I strongly doubt that anyone would go
> through all that trouble unless he's a security researcher or expects
> to make tons of cash. Regarding the latter person, he'd only attack
> high value targets. If someone has such a site and is not already
> using SSL he's a bloody moron, fair and square.

Unfortunately, SSL is not always an option. Joomla targets at
installation on cheep shared hosts.

> I would also like to point out two assumptions you made: SQLi attacks
> using #__ are far more common than those using jos_. This is contrary
> to every single log file I've seen from real world sites. Man in the
> middle attacks are at least as common as other hacking methods
> (otherwise I would be right in saying it is an unrealistic attack).
> Again, experience shows the exact opposite.

That was just a side step example to understand your focus. The issue is
using plain text passwords in daily business.

> Finally, I will tell AGAIN that even if you'd like to ignore all of
> my points and I were just a bitching schmuck, you still have one
> MAJOR problem in including something like that in Joomla!:
> cryptography laws.

Honestly, I don't believe that password hashing using md5 can be
illegal. If it were, SSL were illegal as well.

> Everybody seems to be oblivious to the fact that
> this would make Joomla! illegal in many countries all over the world.
> People, that's a MAJOR concern and none of you even gave it half a
> sentence in your replies.

Its just because it can't be true - at least in the context of password
hashing.

Regards,
Niels

--
| http://barcamp-wk.de · 1. Barcamp Westküste 2./3. März 2012 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Nicholas K. Dionysopoulos]

Oh, boy… I'm under the impression that several people on this list are very happy to find the tree and miss the forest. Or, at least, type before they think things through. Here we go, and this time please pay attention to what I'm writing.

Ever used WireShark on a barcamp? I demonstrated the issue lately by

excluding half a dozen Joomla admins from their sites. No efford, every

child (with a laptop) can do this.

Of course I have. You too. Herman too. A lot of us did. It's fun! We're geeks! We are the researcher guys. The thing is, have you seen any serious hacker walking around with his laptop like that and attacking random targets?

Put in another way: Buying a weapon is very easy in the US. Walking into a crowded bar and killing random people is very easy. But is it common? Nah, not even in the ghettos, where you might be accidentally killed for no reason by some gangster going through his initiation ritual. Would you suggest that all buildings should install metal detector gates, or X-ray machines and armed security guards? Obviously, the high security buildings do have those things and they do have those things because they are coveted targets. Same goes with sites. Joe Nobody's blog is unlikely to be deliberately targeted by a hacker who would go into all of this trouble. Even if said hacker ran accidentally into Joe's login information, he'd hardly bother. Just because it's possible, it doesn't mean it's probable. Possible means that the probability is greater than zero. An asteroid hitting Earth and killing all of us is possible (and there are many asteroids which could do that). Probable means that the probability is adequately high as to worry us. I don't know about you, but I don't wake up every morning shaking out of fear that the next minute an asteroid will squash me like a cockroach. Just sayin'...

Unfortunately, SSL is not always an option. Joomla targets at

installation on cheep shared hosts.

The kind of sites that nobody will ever bother cracking because they are USELESS. The only people who might attack those sites are script kiddies so that they can boast to their buddies that they're "133t h4x0r5". But, yeah, let's assume that you want to protect those sites from a completely improbable (=unrealistic) attack.

That was just a side step example to understand your focus. The issue is

using plain text passwords in daily business.

Ah, a nice interlude to your arguments. I suppose I could also refer to something completely unrelated to your point, imply that it's related to what I'm going to say next and you'd happily ignore it and go on reading my post, unbiased. OK, I'll give it a go: "It was raining yesterday. Yet you say that this kind of attack is common. Sorry, but I disagree". Oh, look, a verbal firework!

Honestly, I don't believe that password hashing using md5 can be

illegal. If it were, SSL were illegal as well.

No, MD5 is not illegal, but it's a totally stupid idea to implement, if your goal is to even marginally increase the security of the site. Here's why. Let's assume the way Joomla! is currently storing the password. Joomla! sends the salt to the browser. A JS implementation of MD5 takes the user's password, appends the salt and produces the MD5 hash, then sends it to the server, unencrypted, complete with the username. If I were said kid with a WireShark-enabled laptop I now know:

- Your site's URL

- Your username

- Your salted password

Therefore, I can login to your back-end. Your site is pwned and I'm 133t h4x0r5. Apparently, this solution added no security whatsoever and is as meaningful as digging your backyard in hopes of finding a gold streak. Attacker vs half-baked solutions: 1-0.

Next implementation. Using a symmetric encryption algorithm which may be legal in most jurisdictions. The server sends the encryption key over an unencrypted connection. A JS implementation takes the user's password, encrypts it (you can add salt if you want to), then sends it to the server, complete with the username. If I were said kid with a WireShark-enabled laptop I now know:

- Your site's URL

- Your username

- The encrypted password

- The encryption key

Apply encryption key to encrypted password, get unencrypted password, pwned your site. Attacker vs half-baked solutions: 2-0.

Let's up the ante. Asymmetric (public key) cryptography. Now that would be secure. Sorry, I lied. It would be half-secure. It would absolutely make it impossible for said laptop-wrangling kid to fetch your password. Yet, he's using WireShark. Man! It's pure awesomeness! Steal your cookie, deface your site for the lulz, walk out of the barcamp/whatever. Woot! Attacker vs half-baked solutions: 3-0.

Even as such, Houston, we have a problem here. Most jurisdictions consider the dissemination of source code for PK cryptography to be illegal and, in fact, punishable with pretty much the same severity as trafficking weapons. This would mean that we either can not include it in Joomla! or we'd have to compile (encrypt it) with something like Zend Guard (ideally by a guy in a cryptographically neutral country). But that solution also has some issues, as this would violate Joomla!'s own license.

Therefore, the attacker beats the half-baked solutions with a staggering 3-0. What an one-sided match, ladies and gentlement!

Or, we could use SSL if we care so much. What could the attacker do? Nada. Unless, of course, he goes about to do some DNS poisoning on the network, install his own self-signed SSL certificate and the site owner is a complete moron and doesn't notice the HUGE RED PAGE on his browser. Practically, it would be an easy win for the site owner. Ah, the simple things...

Its just because it can't be true - at least in the context of password

hashing.

Very true, as far as the legality goes. But you were trying to increase security and hashing really doesn't. Unless, of course, you store the password unencrypted in the database and create a random, one-time salt per login. However, storing the password unencrypted would actually diminish the security of your site. Should there be a simple SQLi vulnerability, the attacker would have all password right in front of him. Should I count an extra goal for the attacker? Yes. 4-0.

Right now, with the use of salted MD5 sums, an attacker would have a hard time cracking all but the easiest of password (but, then again, easy password can be hacked easily no matter how strong your hashing method is, see my earlier replies from a few days ago).

And, now, using something like AES-256 or any other symmetric or asymmetric encryption algorithm to encrypt the passwords in the DB table with a per site (or, worse, per user) key is also a non-solution. An attacker could still obtain the encrypted passwords and the key and crack all passwords in a matter of seconds. That would be 5-0 for the attacker.

You can continue proposing workarounds and more half-baked solutions, but they will all be variations of the above. The only (inapplicable) solution would be the use of TAN, iTAN or –better yet– mTAN. Especially in the latter case, the transmission of the TAN is done over a different communication medium, making it very hard to fake a login. However, it's damn hard and expensive to implement, especially on the shared sites. Another good approach would be transmitting a short-lived (1-2 minutes) TAN over email, assuming that the email is accessed over a secure connection (GMail maybe) and the attacker does not perform a real-time MITM attack between the site's mail server and the recipient's mail server.

Can we now stop the time wasting on this stupid witch hunt and deal with real issues? kthxbye

[Hannes Papenberg]

Just wanted to say that Nicholas is right. Joomla is doing what it can
in terms of security for the password, maybe using a different hashing
algorithm instead of MD5, like it was already proposed some time ago.

Regarding the legal issues: Simply looking at wikipedia
(http://en.wikipedia.org/wiki/Cryptography) will show you a range of
countries that have serious restrictions: China, Belarus, Kazakhstan,
Mongolia, Pakistan, Singapore, Tunisia and Vietnam. That makes at least
1.5 billion people, about a fifth of the earth population. And that is
just a quick check. So every fifth person on this planet does not have
unrestricted access to cryptography and you can bet your ass that
countries like China or North Korea have their thumb on every and any
crypto software out there.

Hannes

Am 21.12.2011 20:11, schrieb Nicholas K. Dionysopoulos:
> Oh, boy� I'm under the impression that several people on this list are

> /may/ be legal in most jurisdictions. The server sends the encryption

> key over an unencrypted connection. A JS implementation takes the
> user's password, encrypts it (you can add salt if you want to), then
> sends it to the server, complete with the username. If I were said kid
> with a WireShark-enabled laptop I now know:
> - Your site's URL
> - Your username
> - The encrypted password
> - The encryption key
> Apply encryption key to encrypted password, get unencrypted password,
> pwned your site. Attacker vs half-baked solutions: 2-0.
>

> Let's up the ante. Asymmetric (public key) cryptography. Now /that/

> solution would be the use of TAN, iTAN or �better yet� mTAN
> <http://en.wikipedia.org/wiki/Transaction_authentication_number>.

> Especially in the latter case, the transmission of the TAN is done
> over a different communication medium, making it very hard to fake a
> login. However, it's damn hard and expensive to implement, especially
> on the shared sites. Another good approach would be transmitting a
> short-lived (1-2 minutes) TAN over email, assuming that the email is
> accessed over a secure connection (GMail maybe) and the attacker does
> not perform a real-time MITM attack between the site's mail server and
> the recipient's mail server.
>
> Can we now stop the time wasting on this stupid witch hunt and deal
> with real issues? kthxbye
>

[Herman Peeren]

"type before they think things through"... oh you allready said that yourself.

• hex_md5(hex_md5(plainpasswd+salt)+token) is not the same as hex_md5(plainpasswd+salt). The more because the intention is to use another token with every new login-attempt (and limit the number of attempts in a session).
  
• with public/private key encoding only the public key is sent in public and that can only be used to encode the password, not to decode it. That was the main principle.Or do you have a new decryption algorithm?
  

I see a real problem. Most of it is still in it's infancy, because the large scale use of public Wifi is not so old yet. Once the script kiddies (and serious hackers) are on this it will be a huge problem, I think. I want to put some energy in avoiding that (solid, using simple MD5). Not in rethorica. It is clear that for Nicholas there is no problem to be solved here, so thank you and goodbye; don't waste your energy on it then.

This was a special year in The Netherlands: most of the certificates that were used by any governmental body in our country were compromised! If anyone had pointed out last year that it was possible, the answer would probably have been the same as yours. But now there was a real problem....

[Nicholas K. Dionysopoulos]

Herman,

You are actually wrong in assuming that I don't care. If I didn't care I would not have replied.

Regarding the first approach, the password is not transmitted in cleartext (and it would be hard to crack it, unless of course you consider md5 an easy to crack algorithm which is a different issue), but please tell me how said kid with laptop can not still compromise your account, since your cookie is still unencrypted. Because, honestly, that's the realistic attack that can be performed. I raised that issue in my virtually all of my previous posts, it's still left unanswered. Unless, of course, you don't care about securing the site, but just the password. In this case we are talking about solving different problems. But also in this case the "snake oil security" factor would be accented by an order of magnitude because users would understand that encrypting their login information secures the site, not their password. I don't expect users to understand the fine print or why despite their password being "secured" they should still not log in using an open Wi-Fi over plain HTTP.

Regarding the second approach, did you read my reply? Honestly. It's not very positive for you if you did read it and still ask me the question in your second point, so I'll assume you skimmed through it and missed the big picture regarding PK cryptography. So, let me copy & paste it here for you to read it:

Let's up the ante. Asymmetric (public key) cryptography. Now that would be secure. Sorry, I lied. It would be half-secure. It would absolutely make it impossible for said laptop-wrangling kid to fetch your password. Yet, he's using WireShark. Man! It's pure awesomeness! Steal your cookie, deface your site for the lulz, walk out of the barcamp/whatever. Woot!

(yeah, it's the same point as I made above; the one you still do not answer and the key to real security). But it doesn't stop here. Here's the next paragraph of my reply (emphasis added):

Even as such, Houston, we have a problem here. Most jurisdictions consider the dissemination of source code for PK cryptography to be illegal and, in fact, punishable with pretty much the same severity as trafficking weapons. This would mean that we either can not include it in Joomla! or we'd have to compile (encrypt it) with something like Zend Guard (ideally by a guy in a cryptographically neutral country). But that solution also has some issues, as this would violate Joomla!'s own license.

In retrospect, I meant to to write "Many jurisdictions", not "Most jurisdictions", but that's irrelevant to the core point being made.

 

And since you might also missed/ignored Hannes' reply, let me copy & paste it here for you so that you can read it too:

Regarding the legal issues: Simply looking at wikipedia

(http://en.wikipedia.org/wiki/Cryptography) will show you a range of

countries that have serious restrictions: China, Belarus, Kazakhstan,

Mongolia, Pakistan, Singapore, Tunisia and Vietnam. That makes at least

1.5 billion people, about a fifth of the earth population. And that is

just a quick check. So every fifth person on this planet does not have

unrestricted access to cryptography and you can bet your ass that

countries like China or North Korea have their thumb on every and any

crypto software out there.

Same as what I said, with a link. Oh, I also remembered one of my bookmarks: http://rechten.uvt.nl/koops/cryptolaw/ It's an awesome roundup of cryptography-related laws around the world. Do I need to spell it out? Using public key cryptography would render Joomla! ILLEGAL in many jurisdictions. And it still doesn't solve the cookie theft issue.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/16NL5sK7qEgJ.

[Niels Braczek]

Am 21.12.2011 20:11, schrieb Nicholas K. Dionysopoulos:

> Oh, boy… I'm under the impression that several people on this list
> are very happy to find the tree and miss the forest.

Well, timbering is done one tree after another.

> Or, at least, type before they think things through.

Do you want to attack me personally? I don't hope so -

> Here we go, and this time
> please pay attention to what I'm writing.

I did, and I do.

>> Ever used WireShark on a barcamp? I demonstrated the issue lately
>> by excluding half a dozen Joomla admins from their sites. No
>> efford, every child (with a laptop) can do this.
>
> Of course I have. You too. Herman too. A lot of us did. It's fun!
> We're geeks! We are the researcher guys. The thing is, have you seen
> any serious hacker walking around with his laptop like that and
> attacking random targets?

No, but I also never saw people being shot or an asteroid impact. And I
*know*, at least the latter two happen from time to time.

> Put in another way: Buying a weapon is very easy in the US. Walking
> into a crowded bar and killing random people is very easy. But is it
> common? Nah, not even in the ghettos, where you might be accidentally
> killed for no reason by some gangster going through his initiation
> ritual. Would you suggest that all buildings should install metal
> detector gates, or X-ray machines and armed security guards?

That is the common solution. One example:

"Long-term protective measures should include physical enhancements to
school buildings. Among the measures schools should consider are the
following:
• Install secure locks for all external and internal doors and windows.
• Install window and external door protections with quick-release
capability.
• Consider establishing a safe area (or safe areas) within the school
for assembly and shelter during emergencies.
• Apply protective coating on windows in facilities that face traffic.
That and other helpful information on school facilities can be found at
www.edfacilities.org/." (UNITED STATES DEPARTMENT OF EDUCATION, 2004)

> Obviously, the high security buildings do have those things and they
> do have those things because they are coveted targets. Same goes with
> sites. Joe Nobody's blog is unlikely to be deliberately targeted by a
> hacker who would go into all of this trouble. Even if said hacker ran
> accidentally into Joe's login information, he'd hardly bother.

Gaining access to Joe Nobody's webspace means getting another cheap spam
relay.

> Just
> because it's possible, it doesn't mean it's probable. Possible means
> that the probability is greater than zero. An asteroid hitting Earth
> and killing all of us is possible (and there are many asteroids which
> could do that). Probable means that the probability is adequately
> high as to worry us. I don't know about you, but I don't wake up
> every morning shaking out of fear that the next minute an asteroid
> will squash me like a cockroach. Just sayin'...

Well, a lot of money is spent on this issue, so I don't have to take
care of it.
http://en.wikipedia.org/wiki/Asteroid-impact_avoidance

>> Unfortunately, SSL is not always an option. Joomla targets at
>> installation on cheep shared hosts.

> The kind of sites that nobody will ever bother cracking because they
> are USELESS.

Sorry, but that is bullshit. Of course these sites are under attack -
constantly. Bot nets are eger to get hands on them to distribute their
spam and malware.

> The only people who might attack those sites are script
> kiddies so that they can boast to their buddies that they're "133t
> h4x0r5". But, yeah, let's assume that you want to protect those sites
> from a completely improbable (=unrealistic) attack.

If that was true, we wouldn't see any "My site got hacked" message on
the forums. Indeed, we see a lot of them.

>> That was just a side step example to understand your focus. The
>> issue is using plain text passwords in daily business.

> Ah, a nice interlude to your arguments. I suppose I could also refer
> to something completely unrelated to your point, imply that it's
> related to what I'm going to say next and you'd happily ignore it and
> go on reading my post, unbiased.

You are constantly getting back to encryption. I never proposed a
solution using encryption. So I 'm forced to believe, that you either
did not read my proposal or did not understand it (I daon't believe the
latter, because I know you).

> OK, I'll give it a go: "It was
> raining yesterday. Yet you say that this kind of attack is common.
> Sorry, but I disagree". Oh, look, a verbal firework!

You're getting offending again...

>> Honestly, I don't believe that password hashing using md5 can be
>> illegal. If it were, SSL were illegal as well.

> No, MD5 is not illegal, but it's a totally stupid idea to implement,
> if your goal is to even marginally increase the security of the site.

It is not. Read my proposed solution.

> Here's why. Let's assume the way Joomla! is currently storing the
> password. Joomla! sends the salt to the browser. A JS implementation
> of MD5 takes the user's password, appends the salt and produces the
> MD5 hash, then sends it to the server, unencrypted, complete with the
> username. If I were said kid with a WireShark-enabled laptop I now
> know: - Your site's URL - Your username - Your salted password
> Therefore, I can login to your back-end.

You can't because of the session token, which is used to salt the
password hash. So you don't get the salted password as it is stored in
the database. And the combination of url-username-hash is only useable
within the exactly same session.

> Your site is pwned and I'm
> 133t h4x0r5. Apparently, this solution added no security whatsoever
> and is as meaningful as digging your backyard in hopes of finding a
> gold streak. Attacker vs half-baked solutions: 1-0.

Only because you're completely ignoring the proposed solution. The
efford for an attacker to get access is significantly higher, so it
definitely is *not* a half baked solution. It is the best you can get
without SSL.

> Next implementation. Using a symmetric encryption algorithm [...]

I'm totally unimpressed of your constructs, which are made to fail and
support your attitude. My proposal works.

> Even as such, Houston, we have a problem here. Most jurisdictions
> consider the dissemination of source code for PK cryptography to be
> illegal and, in fact, punishable with pretty much the same severity
> as trafficking weapons.

My solution does not use any encryption, and md5 hashing is already used
to store passwords. So no harm here.

> Therefore, the attacker beats the half-baked solutions with a
> staggering 3-0. What an one-sided match, ladies and gentlement!

Just because of your bias, which I - honestly - can't understand,
although I tried.

> Or, we could use SSL if we care so much. What could the attacker do?

Of course SSL is the better solution - but we already constated that it
is not always possible to use it.

>> Its just because it can't be true - at least in the context of
>> password hashing.

> Very true, as far as the legality goes.

Nothing more to say about that. No legal issues.

> But you were trying to
> increase security and hashing really doesn't. Unless, of course, you
> store the password unencrypted in the database and create a random,
> one-time salt per login.

Again: Read my proposed solution. It uses one-time salt together with
hashed passwords from the database.

> Right now, with the use of salted MD5 sums, an attacker would have a
> hard time cracking all but the easiest of password (but, then again,
> easy password can be hacked easily no matter how strong your hashing
> method is, see my earlier replies from a few days ago).

Exactly. There is nothing like absolute security. *Any* hurden can be
taken. But it is our obligation to make it as expensive as possible.
*That* shows our responsibility.

> You can continue proposing workarounds and more half-baked solutions,

Read my proposed solution. It works.

> Can we now stop the time wasting on this stupid witch hunt and deal
> with real issues?

Discussing a solution for this issue (you see, I don't say "problem") is
not waste of time. Being forced to defend oneself against your
non-constructive and subjective attacks is. I'm a bit of disappointed,
because I know you as a smart and friendly guy.

[Herman Peeren]

The title of this discussion is "Salted MD5 login to prevent sniffing in non https". I didn't start any discussion about private/public key encrypting. That is not the subject. I only corrected some false statements about it (like decrypting with the public key).

So, all very interesting and I had read the legal stuff you refer to allready quite some time ago, but it is not the subject of this thread. Let's separate the different subjects and solve problems instead of creating them. If other subjects bother you, then start a thread for it.

I think a password in plain text is a broader problem than an attack by hitchhiking a cookie: intercepting the password is much easier done and the password can also be used after the session. It is a simple problem with simple solutions. Those solutions are broadly used in computerized authentication. Nothing new. Only Joomla (and others) is a bit late with it.

[Stefano Gargiulo]

2011/12/21 Nicholas K. Dionysopoulos <niko...@gmail.com>

Stefano,

You'd be surprised! Depending on your site's niche, it is possible that the majority of your users have IE6 with JavaScript turned off (enterprise visitors). Also, many people DO have JS enabled for FaceBook, but turned off for every other site. You've heard about the Firefox plugin called NoScript, right? Many people do use it. If you ask them to turn on Javascript so that they can log in in order to leave a comment on an article, subscribe to your site or something like that, the chances are these people will simply navigate away to another site. Oh, BTW, the 10% is not a random figure; it's a rounded value of what I observe on my sites (8.5-9.6%). Anyway, don't assume anything about the capabilities of the visitor's browser.

So google analytics, the most reliable free analytics service is wrong by 10%!!!

Here their tracking code:
<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXXXXX']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

pure javascript only!! i think your webalizer is confusing bots with humans.

Things evolves and sincerly i think using noscript nowadays is stupid and unuseful , html5 is strongly based on javascript, web is strongly based on javascript, nowadays.
 

Regarding the emails, as of Joomla! 1.6 you can simply override the language strings of the emails to not include the password. But, no, it's not unprofessional, unless you assume that thousands upon thousands of non-Joomla! websites doing the same thing are all unprofessional.

Yes i think they are unprofessional. Tell me this site names, i don't think is a mainstream site.

Why? Maybe you can read emails in presense of other persons and is not nice to have your password shown, maybe you don't want it stored on your mail server (so your sysadmin can read it) or in your desktop email files, and last but not latter this feature is absolutely unuseful, the right technique is to give a short expiring secret link (say 5 days/first use) to reset the password, but why show me my password if i know it or i can reset it?
 

[brian teeman]

From Oct 2010 Yahoo reported between 1 and 2% of users browsing with JS disabled

http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/

[Nicholas K. Dionysopoulos]

Stefano,

If I took bots into account, the difference would be close to 20%. Thank you, I am not an idiot. Google Analytics is using Javascript to analyse your site because most visitors will have JS turned on and it's the only way to fetch all the information they need without having access to your server.

Also just because you, me and pretty much everyone reading this wishes that all users would magically switch to a modern HTML 5-capable browser with Javascript enabled it does not mean that it is feasible. If you read my reply to the browser support thread, you have a good idea why.

Regarding the email being sent out, I don't like that feature either. But some sites do that and some of them belong to multi-billion-dollar corporations:

- iStockPhoto

- SourceForge

- Mandriva Linux

- Freehostia

- Secure Tunnel (they sell SSH tunnelling access!)

- RocketTheme

- All phpBB3-based forums

- Sony Ericsson

- WordPress.com

I could go on, but I am too bored to go through my entire list of sites I have registered to.

And this the last email I'm sending on this list. I've wasted 3 hours of my life today debating with people who don't read and don't think. I've got much better uses of my time. So long.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Stefano Gargiulo]

Hey.

MD5(One time token+password) is a secure way to send the password  and i proposed this way at the start of this thread!!

BUT ATTENTION THIS REQUIRES THAT THE BACKAND DB STORES NON SALTED HASH, not a drama in my opition.

but hex_md5(hex_md5(plainpasswd+salt)+token) like Herman proposed is very good to keep retrocompatibility (but sending real salt over ajax is like to have no salt on the backend).

Anyway if you sniff these md5 strings you cannot use them to login. So is secure.

Anyway Nicholas you are right with the cookie hijacking point, but i talked about this issue at start of this thread also. I know this problem, and i proposed also to add a check for the user IP in JSession class (So to hijack session you should be able to take the user IP, and this is not so easy like it sounds, and not so "untraceable" like a sniffing)

Other things that add difficulty to the hacker and a little bit of protection under NAT (but we're going to IPv6 so NAT will be deprecated) can be to

Check also USER AGENT on JSession http://www.redteamsecure.com/labs/post/12/simple-anti-session-hijacking
(User agent is spoofable, we all know, but this adds complexity and time to hacker work  )

In addittion to this you can be creative and for instance use a second cookie with a random token that can be periodically renewed by the server to limit the attacker time window.

Anyway this is not 100% secure we all know that the only way to secure a session is HTTPS.

But stealing session is different form stealing login password because we know also that many users uses the same password in more than one site, and also  and if password or email change is made possible ONLY with a confirmation email when user logs-out attacker can not access to the session anymore because the session is erased server side, so using this technique in combination with  a notification system for last operation you executed on the site can detect an attack ad logout immediatley to preserve your site (i'm talking about administrators).


Anyway to complex to be implemented, so maybe Nicholas is right: don't waste time coding this and switch to SSL (but he is not right when he say that this discussion is a waste of time, because it's offensive for the intelligence of anyone here and because now anyone know the huge risk of non using ssl and tried to use his brain to resolve it, so maybe, putting ssl as a "suggested system configuration" for joomla may be a nice "single line of code" conclusion)

Best Regards,
Stefano.

2011/12/21 Niels Braczek <nbra...@bsds.de>

[Stefano Gargiulo]

2011/12/21 Nicholas K. Dionysopoulos <niko...@gmail.com>

Stefano,

If I took bots into account, the difference would be close to 20%. Thank you, I am not an idiot. Google Analytics is using Javascript to analyse your site because most visitors will have JS turned on and it's the only way to fetch all the information they need without having access to your server.

Are you sure?

What do you think about this?

<noscript><a href="http://www.histats.com" target="_blank"><img  src="http://sstatic1.histats.com/0.gif?xxxxx&101" alt="contatore free" border="0"></a></noscript>

<script type="text/javascript">document.write(unescape("%3Cscript src=%27http://s10.histats.com/js15.js%27 type=%27text/javascript%27%3E%3C/script%3E"));</script>
<a href="http://www.histats.com" target="_blank" title="contatore free" ><script  type="text/javascript" >
try {Histats.start(1,xxxxxx,4,0,0,0,"");
Histats.track_hits();} catch(err){};
</script></a>


Why google don't add a noscript session to track almost the visit (but also user agent and all basic information they needs)? Maybe because 10% of noscript users is unrealisting




 

Also just because you, me and pretty much everyone reading this wishes that all users would magically switch to a modern HTML 5-capable browser with Javascript enabled it does not mean that it is feasible. If you read my reply to the browser support thread, you have a good idea why.

Regarding the email being sent out, I don't like that feature either. But some sites do that and some of them belong to multi-billion-dollar corporations:

- iStockPhoto

- SourceForge

- Mandriva Linux

- Freehostia

- Secure Tunnel (they sell SSH tunnelling access!)

- RocketTheme

- All phpBB3-based forums

- Sony Ericsson

- WordPress.com

the only billion dollars company  here (IMHO) is sony but we all know how they take into account security with the recent story of sony playstation network hacked with thousands of credit card numbers hacked.

Wordpress and bb also have the problem of this CMS (i'm not saying that joomla is less secure of other opensource alternatives)
 

I could go on, but I am too bored to go through my entire list of sites I have registered to.

So i hope you encrypt your mailbox, your harddisk, and you have a BIOS level protected computer.

Why facebook, google and linkedin don't? let's evolve.

And this the last email I'm sending on this list. I've wasted 3 hours of my life today debating with people who don't read and don't think. I've got much better uses of my time. So long.

Opensource means also openminded. We are all tring to give a contribute and spending our precious time.

Best regards,
Stefano

[Andrew Eddie]

I think we are starting to lose the plot here. Let's take it down a
notch and talk code.

Bottom line: base PHP and JS crypt API would be useful generically
useful to the platform for purposes that include, but are by no means
exclusively limited to login scenarios. When done, everyone can
choose how to, or not to use them for their own particular cases.
Fair?

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.7 developers

[Marius van Rijnsoever]

Thank you for being a voice of reason Andrew.

The list of "illegal" softwares that handle SSL type encryption is
very long. IE, Firefox, chrome safari, outlook, PHP, apache, all linux
distributions, etc, etc (i can list a few more dozens if you wish).
Hundreds of common softwares handle public-private key encryption and
have managed to be distributed in a legal manner. That does not mean
that there are very complex legal issues with encryption and the many
different countries that have different standards. But these complex
issues are managed by the experts and since we have lawyers working
for Joomla we should get their professional opinion. However the
"dooms day" scenario that Joomla will be come illegal in many
countries is wrong. It just needs to be implemented with planning.

Stefano, storing unsalted md5 hashes is the backend database is not an
option, as due to rainbow tables nobody should store unsalted
passwords.

>Anyway Nicholas you are right with the cookie hijacking point, but i talked about this issue at start of this thread also. I know this
> problem, and i proposed also to add a check for the user IP in JSession class (So to hijack session you should be able to take
>the user IP, and this is not so easy like it sounds, and not so "untraceable" like a sniffing)

Search this list for "IP blocking" and you will find that this is
impossible to implement and has been discussed before. The problem is
that many people have rotating IP addresses (all AOL users for
instance) who would randomly loose their Joomla sessions. In addition
many people share IP addresses behind proxies and IP addresses can be
falsified. Although the thought of IP validation of sessions is
appealing, it is not possible in practise.

I had some more thoughts on a system that can handle encryption of any
data (not just passwords) and is as simple as modifying the form
submit button. And is just as Andrew suggested in his last posy. I
will create a separate thread with my detailed plan on the platform
list, as the current topic is exploding a bit.

Thanks, Marius

[Marius van Rijnsoever]

oops, almost forgot to say thank you to Herman for sharing that code.
I fully agree with your arguments.

[Herman Peeren]

I did misread "symmetric" (I answered as if Nicholas had written "asymmetric"), but well, considering symmetric encryption in that example is too absurd to be taken seriously. I'd almost say: a sidestep to be ignored. Sorry for misreading it though.

For who missed it, this blogpost from one-and-a-half year ago about the same subject: http://brian.teeman.net/joomla-gps/protect-joomla-passwords-on-public-wifi-networks.html. We planned to make that md5-hash of passwords a more general plugin, but because the PPK-encryption of Ratmil (from Cuba BTW) works so well and easily I've just put that in my default Joomla-distribution (which I make with Akeeba Backup, of course). Maybe we should still make the original planned double-hash-plugin, as it is easier to discuss with actually working code and real life use cases than in some theoretical swamp.

@Stefano: sending real salt over ajax is NOT like to have no salt on the backend. The salt is no secret and is stored together with the hashed password in the db. Hashing is, in principle, a one way code-generation. If a client can generate the same code as the server, then both know the secret (the password); without actually sending the password in a decodable way.

@Marius: I look forwards to your "detailed plan on the platform list". I am not unfamiliar with cryptography, so maybe I can help. If the plan is detailed, then there probably will be some legal investigation planned too.

About bots: when I make a bot I don't always want to show it is actually a bot. I know that is not "nettiquette", but I have good reasons for it. I then spoof the User Agent string, to pretend it is a common browser. Of course all bots with malicious intentions will have a spoofed User Agent. They are never called "HeyIAmTryingToFindSomeVulnarabilitiesToHackYourSiteBot". Just a suggestion to keep in mind when looking at User Agent statistics and the use of JS.

I have one more issue with cookies, that is a little bit related to this discussion, but I'm still investigating it and providing a solution. Then I'll first report it to the JSST.

I hope you'll all be inspired by peaceful Christmas-thoughts the coming time. Joomla would not exist without cooperation and giving each other a safe place to fail. Fortunately I met Nicholas in person, otherwise I would have felt a bit intimidated and unwelcome on this list.

[xavip]

I don't like that joomla uses plain text passwords to register &
login. A lot of people is using the same password in all the websites
they login in, as an 'evil' administrator could collect all those
passwords. I think there's still the gmail plugin in the CMS...
I think this shold be considered seriously in joomla, protect users
passwords, and implementation on Oauth methods.
I think to set a token in the client side it's a better approach than
sending plain text passwords to the server. At this moment even a
lamer like me can collect site user's passwords with a single php
line.
I'm not talking about protect the server or joomla installation over
hackers, because the current method I guess it's enough. I'm talking
about the users privacy.
cheers

[Herman Peeren]

The GMail authentication plugin is still in Joomla 1.7, but I think that is even worse: it sends your GMail password in plain text over the line, fully interceptable by any administrator server-side... Just get $credentials['username'] and $credentials['password'] in that plugin and you can login into someones GMail-account.

I could hardly believe it when I saw that code for the first time and am surprised it is still there. Or am I misreading the code?

[Ian]

I don't think that plugin was ever meant for production use and should be removed.

The plugin was created years ago as a proof of concept on a bet.  I don't even know that it still works.

Ian

[xavip]

In my opinion the current login system has the same problem as GMail
authentification, just because a lot of users use the same password.
I agree serious websites must use SSL, but a simple encription of the
password wolud be appreciated. I don't know if ajax is needed to get
session, etc. Maybe a simple md5(password) wolud be enough to protect
users privacy from 'evil' admins and network sniffers.
I don't know the reason why the plain text password is a need on the
server side, as it's actually encrypted there too...

[xavip]

I forgot joomla is currently emailing users with thir own password, if
this is the reason, I agree it's not needed anymore

[Herman Peeren]

Thank you for your reply, Ian! That would be good. But maybe it should be removed then. In 2.5?

However, here has been a clean-up round for 1.6. From the authentication plugins the openid en the example-plugin were removed then. But this one stayed in. Maybe Sam knows some more about it. Also see  https://groups.google.com/forum/#!searchin/joomla-dev-cms/gmail$20plugin/joomla-dev-cms/NUnslFZ6nak/QVouCPcFKkIJ

[Ian]

Some interesting research I did:

http://golubev.com/gpuest.htm 

That link shows estimates of how many md5 hash attempts you can make in a second with various video cards.

Near the bottom, you see that the Radeon HD 6950 can compute about 4500 million md5 hashes per second.  Also note: http://www.newegg.ca/Product/Product.aspx?Item=N82E16814125372.

If you assume a password contains uppercase or lowercase letters or numbers, then you have your set of passwords that are 8 characters or less as:

62^8 + 62^7 + 62^6 + 62^5 + 62^4 + 62^3 + 62^2 + 62^1 ~ 2.219 x 10^14

That means that for a given salt you can try all those passwords in 49315 seconds which is roughly 14 hours.

If you limit it to lowercase letters (which probably isn't that rare), you can try all the passwords in 48.26 seconds.

For lowercase and uppercase letters, you can try all the passwords in 12 113 seconds, which is roughly 3 1/2 hours.

Obviously with a distributed system you can do this faster and the trend is going to be towards more speed.

I think the question really should be in any case how we can make Joomla more flexible so that one might be able to change authentication schemes with a plugin or something similar.

Regards

[brian teeman]

Ian, The ability of computers being able to crack passwords has been the subject of Nicholas' security presentations for about a year now. At least one of those presentations is on people.joomla.org as a video

I do not believe that Joomla can do anything to prevent someone using the same password on more than one site and imho the oauth type authentications are worse because you get your password exposed on one site and now all the sites that you used that auth method on are accessible.

I have nothing at all against increasing security, I love it and that's one of the things I've always spoken about in my presentations and here on the bug trackers and forums. My concern is that we must do this in a way that is compatible on all servers in all countries which the original proposals were definitely not.

I look forward to seeing real concrete proposals that will enhance the security of Joomla whilst at the same time remembering that Joomla is a mass market product.

[joo...@bobbykjack.me]

> If you assume a password contains uppercase or lowercase letters or
> numbers, then you have your set of passwords that are 8 characters or less
> as:
> 62^8 + 62^7 + 62^6 + 62^5 + 62^4 + 62^3 + 62^2 + 62^1 ~ 2.219 x 10^14
> That means that for a given salt you can try all those passwords in 49315
> seconds which is roughly 14 hours.

Exactly the reason why there should not be a limit on password length. Any
site that imposes one, IMO, is suspect. Passwords should always be hashed
and, therefore, password length is irrelevant.

On the general matter of client-side hashing, I agree that this would be
an excellent step. Regardless of other server-side security
considerations, *as a user*, all I care about is that providing a password
isn't opening me up to all sorts of potential problems. Currently, when I
sign up to a site, I have no idea whether someone at the other end is
recording my login details, selling them on, or storing them for later
use.

Of course, one personal solution would be to use a different password for
every single site I ever register with. That's completely unrealistic,
though, given that I probably have accounts on hundreds of sites. And any
software-based solution (some kind of keychain-type affair) for managing
passwords is not ideal because it's not available everywhere.

So, as a user, I need to be sure that no-one will ever see the password I
type in. Hashing the password in my browser is the only way to achieve
this, as far as I can tell, and this also requires browsers to report that
this is taking place. But a common approach by sites would be a nice
start.

As others have pointed out, even *with* SSL, this would still add a layer
of extra security.

[Ian]

I agree with pretty much everything you said.

I think my concluding sentence was:

"I think the question really should be in any case how we can make Joomla more flexible so that one might be able to change authentication schemes with a plugin or something similar."

Which I think addresses most concerns.

Ian

[Mark Dexter]

This is a very interesting discussion, but it would be even better if
we could come up with some consensus on near-term and medium-term
proposals to improve our authentication. For example, would one
near-term proposal be to add better password checking in core to make
it easy for site admins to require strong passwords? Are there any
other examples of "low-hanging fruit" that would be easy to implement
in the near term?

Maybe it would be good to start an Joomla authentication group and
they could try to come up with some concrete proposals on moving
forward?

Thanks. Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/gp4RrrJA29kJ.

[Andrew Eddie]

https://github.com/joomla/joomla-platform/pull/909

Baby steps.

Regards,

Andrew Eddie

[Marius van Rijnsoever]

One small step from Louis, one giant leap for joomla.

Awesome thanks for the update.

Sent from my galaxy S2

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/2wL6d6EnOUoJ.

[84.le0n]

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/2wL6d6EnOUoJ.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Really good job!

Just a question: what will happen if someone buy webspace without mcrypt module enabled? This package will be useless, right?

Buying space without mcrypt could be strange, but I've seen that mcrypt module is often enabled with "ecommerce" hoster subscription that is usually more expensive than basic subscription.

Is it possible to add same crypt algorithm in this package without using mcrypt module?

Thanks,

Eng. Gabriele Pongelli

AVVERTENZE AI SENSI DEL D.LGS. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e negli eventuali files allegati, sono da considerarsi strettamente riservati. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceveste per errore questo messaggio, Vi preghiamo cortesemente di darcene notizia all'indirizzo e-mail di cui sopra e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema; costituisce comportamento contrario ai principi dettati dal D.lgs. 196/2003 il trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse.

This electronic transmission is strictly confidential and intended solely for the addresses. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this transmission. If you have received this transmission in error, please notify us and delete the received data as soon as possible.

[Andrew Eddie]

> Really good job!
> Just a question: what will happen if someone buy webspace without mcrypt
> module enabled? This package will be useless, right?

Change host.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[elin]

@Gabrielle

I think in general there is always room for people to do work to try to find alternative ways of doing things. 

In the meantime, we see this kind of dependency all the time, for example the iconv issue, the snowball issue and issues with the updater and the way the ftp layer was created to get around some server configuration issues. There are all kinds of hosting environments and we want to support as many as possible in the CMS but there are also limits.  So we probably need some research on how common that would be. I would expect that the CMS would keep JSimpleCrypt in its libraries after it leaves the platform if there seems to be enough need for it. It has worked well enough for most people for all these years and it can continue to.

I also suspect that most hosts have enough Joomla sites that the application puts pressure on the hosts to set up an appropriate environment. 

Elin

[Rouven Weßling]

On 22.02.2012, at 13:33, elin wrote:

I would expect that the CMS would keep JSimpleCrypt in its libraries after it leaves the platform if there seems to be enough need for it. It has worked well enough for most people for all these years and it can continue to.

I haven't looked at it yet but from what Louis said I understood the "Simple" crypt type to be the same algorithm as JSimpleCrypt so I don't know why we would keep JSimpleCrypt around beyond the time necessary for backwards compatability. (If the classes are really compatible, we'd need to test that of course)

Rouven

[elin]

Then why would Andrew agree that the package would be useless without mcrypt?

Elin

[Rouven Weßling]

On 24.02.2012, at 00:27, elin wrote:

> Then why would Andrew agree that the package would be useless without mcrypt?

I'd guess because without mcrypt you gain nothing over JSimpleCrypt, but I can't look into his head. ;) From the pull requests description:

"It should be noted that besides the weak encryption carried over from JSimpleCrypt all of the other ciphers use the PHP mcrypt extension for cryptography." https://github.com/joomla/joomla-platform/pull/909

Rouven

[Andrew Eddie]

I didn't.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/xbsz2IP8r9gJ.

[elin]

Gabriele:

Really good job!

Just a question: what will happen if someone buy webspace without mcrypt module enabled? This package will be useless, right?

Andrew:

Change host.