--
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/-/-t8BMIoIsygJ.
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.
--
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/-/1wy97FhXH8UJ.
Yes, unsalted MD5 is broken, but stating that salted MD5 is really
secure is a wrong assumption. If you say an 8 character password can
only be hacked by brute force in a year, you are assuming that the 8
password characters are in fact from the whole range of ASCII characters
available, maybe even from all UTF8 characters. However, a password does
not have to be a weak dictionary password to be susceptible to brute
force. Most people don't mix uppercase and lowercase characters and
quite a few also don't mix numbers in there. So in worst case, you have
to search a keyspace of about 30^8 combinations, which results in
actually just about a week of calculation time on a slow computer (one
million checks per second).
Yes, the issue is the same for almost every other hashing algorithm out
there, but the big difference is, that something like bcrypt does not
allow you a million or a billion iterations per second, but just maybe a
hundred thousand and it can be even made slower than that.
Regarding your questions:
about a): MD5 is a fast hashing algorithm and has some weaknesses that
make it easier to exploit in some cases, which is why MD5 (even if its
salted) is not considered to be the most secure way to store your
passwords. I wouldn't call myself a cryptologist, but I personally do
aim for the best and highest possible security in the area of cryptology.
about b): No, we are not trying to prevent someone from getting into a
site. The situation that we are trying to cover here is, when someone
already broke in and has a list of the users hashed passwords. We want
to prevent the unhashed passwords from getting into the hands of the
evil guy and that means that we are making it difficult for him to crack
them. That means that we are giving people a choice to use different
hashing algorithms on different websites in order to prevent
differential analysis and to make it possible to switch the algorithm in
case a serious weakness comes up that voids the currently used algorithm
without having to upgrade to a new major release. The proposed patch is
not so much about using a better algorithm from now on forward, but to
ease the pain of switching it when we have to. I wouldn't really care if
the option for the different methods is actually made available in the
GUI to the site admin. I just want to have the possibility for later.
Last but not least, Joomla already got bad press because we are not
taking every possible measure to secure our users passwords.
About moving hosts: AFAIK Joomla 2.5 already requires PHP 5.3 and 5.3
contains all the necessary code that we would need for this feature by
default.
Hannes
Am 14.12.2011 11:35, schrieb Nicholas K. Dionysopoulos:
> I actually tend to agree with Brian. Unsalted MD5 is broken, thanks to
> rainbow tables and known attacks to the algorithm itself. However,
> Joomla! is using salted MD5 passwords. The fastest MD5 brute force
> cracking machine is Whitepixel with a throughput of roughly 31 billion
> iterations per second. With an 8 character password, it would take
> about a year before the password was successfully brute-forced. I
> would assume that this is enough time for someone with a hacked site
> to take notice of the information leak and change his password. And
> I'd certainly bet that an attacker won't try to brute-force the
> password of all user accounts on the site, unless he has thousands of
> years or million of dollars to waste.
>
> Note: Please do not play the "weak password would be easy to guess"
> card. In this case, the hashing method would be indifferent as the
> attacker would try a dictionary attack and a list of possible password
> before trying brute force. The difference between MD5 and SHA512 would
> be cracking the weak password in 2 minutes or 5 minutes, i.e. so
> frivolous that's not even worth mentioning it.
>
> So, the real questions are: a. *why* do we consider MD5 to be broken
> as a password hashing scheme? Maybe because some cryptologists found a
> way to create "equivalent" strings which result in the same MD5 hash?
> That's true, but it does not apply to salted passwords, unless you're
> so damn lucky as to find an equivalent string whose later part matches
> the 32 character salt string (not a cat's chance in hell). b. *which
> problem* are we trying to solve with this patch? Did anyone report a
> successful hack because someone cracked his password from an MD5
> string (I seriously doubt it)? Or are we trying to protect an
> imaginary user with imaginary precious data against an imaginary
> adversary with infinite technology and money launching a continuous
> imaginary attack against him? That would make a good book or a
> blockbuster movie (wait, I think it /is/ a movie!) but, honestly, I
> would be more worried about other, easier to exploit, attack vectors
> than MD5 cracking. If I were a hacker and found an SQLi vulnerability,
> I'd create a Super Admin account for myself, block the legitimate SA,
> turn off known protection extensions and log in to the victim's site.
> I wouldn't give a dime about cracking MD5 salted hashes ;)
>
> *Nicholas K. Dionysopoulos*
> Web Development & IT Services
> http://www.dionysopoulos.me
> http://www.AkeebaBackup.com
>
>
>
> On Wed, Dec 14, 2011 at 12:07 PM, brian teeman
> <joom...@googlemail.com <mailto:joom...@googlemail.com>> wrote:
>
> This plugin is a great idea although I think it is trying to solve
> a problem that doesn't actually exist
>
> Even with a big fat warning I would expect most users do not
> predict that they will be moving hosts or that their new host
> would not offer the same feature that their current one does. And
> I'm yet to see a host that advertises, before purchase, which
> libraries they have installed etc
>
> If you flag something as "more secure" then the main usergroup
> that will select this will be those users on the least secure
> cheapest hosts. ie the usergroup that is more likely to have
> issues and more likely to be "moving" hosts at some time in the future
>
>
> --
> 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/-/1wy97FhXH8UJ.
>
> To post to this group, send an email to
> joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
1. Joomla 2.5 does not require php 5.32. Offering an option to changing the password algorithm is opening a minefield of issues as already outlined. Are you ready to support all the users who can no longer access their sites just because they moved host?
--
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/-/5prPzVIuvNQJ.
> If there is a proven way to convert the hashed password from one algorithm to another en masse then I will shut up about this. Until then this is perhaps .......
This is by definition only possible when the user logs-in or changes his password.
In general I wanna add I'm fine with changing the hashing algorithm we use, maybe for 2.5 only for new installations. This can circumvent the moving between hosts part since we'd just raise the minimum system dependencies accordingly.
However I don't see the need to give users a choice of a hashing algorithm. I think the is a perfectly fine decision to be made by the system.
Rouven
According to this page http://php.net/manual/en/function.crypt.php PHP
5.3 provides its own implementation of all the necessary hashing algorithms.
Hannes
Am 14.12.2011 15:32, schrieb brian teeman:
> If there is a proven way to convert the hashed password from one
> algorithm to another en masse then I will shut up about this. Until
> then this is perhaps ....... --
> 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/-/zSXDGOCLf_EJ.
--You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
Hannes,
The amount of hosts who have upgraded to PHP 5.3 is tiny. I can tell you what I see on a daily basis (thanks to the log files people send me when asking for support). The vast majority (~90%) is still on PHP 5.2. More specifically, PHP 5.2.17 and some (Debian-based, apparently) hosts are stuck with PHP 5.2.6. There are quite a few hosts still stuck on PHP 5.1.6, but these can't even run Joomla! 2.5, so I don't care.
Therefore, by making this kind of change, you are screwing a large percentage of this 90% of Joomla! installations still on PHP 5.2. Which is EXACTLY my point.
Given the upgrade pace of live hosts, I'd say that this situation won't change dramatically before the end of 2012, so such a change should better be done for Joomla! 3.5, not 2.5. At that point in time (mid-2013) there will be no excuse for hosts still stuck with PHP 5.2. In fact, I expect PHP 5.3 to be obsolete, 5.4 to be current and 6 to be in beta.--
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com
@Nicholas
I'm well aware of how awfully outdated hosts are most of the time. I
just recently had to upgrade a host from PHP 4 to PHP 5 and we exactly
had the situation that you are describing, that the software was PHP 5
and the host PHP 4. However I tend to take the same stance towards PHP
versions like I do for IE versions. If you are still on IE6/7/8, you
deserve to suffer. There are more than enough cheap and good
alternatives out there and with the Joomla market share, we could force
hosts to think about updating/configuring properly, if they get to many
support requests.
It would actually be a good thing to create a plugin and add it to the
default Joomla install which gives you a loud warning that your host is
crap and that the following x things are broken and/or misconfigured.
Hannes
Am 14.12.2011 18:14, schrieb Nicholas K. Dionysopoulos:
> Hannes,
>
> The amount of hosts who have upgraded to PHP 5.3 is tiny. I can tell
> you what I see on a daily basis (thanks to the log files people send
> me when asking for support). The vast majority (~90%) is still on PHP
> 5.2. More specifically, PHP 5.2.17 and some (Debian-based, apparently)
> hosts are stuck with PHP 5.2.6. There are quite a few hosts still
> stuck on PHP 5.1.6, but these can't even run Joomla! 2.5, so I don't care.
>
> Therefore, by making this kind of change, you are screwing a large
> percentage of this 90% of Joomla! installations still on PHP 5.2.
> Which is EXACTLY my point.
>
> Given the upgrade pace of live hosts, I'd say that this situation
> won't change dramatically before the end of 2012, so such a change
> should better be done for Joomla! 3.5, not 2.5. At that point in time
> (mid-2013) there will be no excuse for hosts still stuck with PHP 5.2.
> In fact, I expect PHP 5.3 to be obsolete, 5.4 to be current and 6 to
> be in beta.
>
> --
> *Nicholas K. Dionysopoulos*
> Lead Developer, AkeebaBackup.com
>
> On Wednesday, 14 December 2011 at 19:09, Hannes Papenberg wrote:
>
>> There is no way to convert the passwords. The only way is for the user
>> to log in and if his password is not stored in the current hashing
>> algorithm, to update the hash with the current clear text password.
>>
>> According to this page http://php.net/manual/en/function.crypt.php PHP
>> 5.3 provides its own implementation of all the necessary hashing
>> algorithms.
>>
>> Hannes
>>
>> Am 14.12.2011 15:32, schrieb brian teeman:
>>> If there is a proven way to convert the hashed password from one
>>> algorithm to another en masse then I will shut up about this. Until
>>> then this is perhaps ....... --
>>> 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/-/zSXDGOCLf_EJ.
>>> To post to this group, send an email to
>>> joomla-...@googlegroups.com
>>> <mailto:joomla-...@googlegroups.com>.
>>> To unsubscribe from this group, send email to
>>> joomla-dev-cm...@googlegroups.com
>>> <mailto:joomla-dev-cm...@googlegroups.com>.
>>> For more options, visit this group at
>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>
>> --
>> 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 <mailto:joomla-...@googlegroups.com>.
>> To unsubscribe from this group, send email to
>> joomla-dev-cm...@googlegroups.com
>> <mailto:joomla-dev-cm...@googlegroups.com>.
If someone needs a cutting-edge website using 3.0, they will need an
up-to-date host that supports 5.3. That's my take on this. 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/-/efhBr2hVjjwJ.
It would even make it less secure, since you could do theoretical differential analysis, since you have two hashes that are based on the same password.
Joomla Platform 11.3 (which is going to be bundled in Joomla 2.5) states requirement of PHP 5.3, I suppose that's faulty?
Is this consensus to go with the patch for 3.0 or is that also
unsatisfactory to those who have objected so far?
Would love for everyone to come to a consensus before making a decision
rather than have it split 50-50.
Kind regards,
Nick
> The point of e) is to include the ability to delete the compromisable passwords after enough accounts have converted for those seeking a higher protection level with associated risks. (And by default not delete/do nothing for everyone else on shared servers.)
Your idea would prefectly make sense, if the attack was made during the
login process - but that's not the case. During login, the password is
is transferred in plain text, if not SSL is used.
The hashing of the password is done to protect it in case of (free)
access to the database. And in this case, the two different hashes from
the same password (at least mathematically) decrease security.
Regards,
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Ingezonden door: Herman Peeren Toevoegen datum: 2012-01-08 22:33:32 The weakness of MD5 doesn't have any implications for the usefullness of MD5 to store a (salted) password. The weakness of MD5 (and SHA-1) is that it is possible, given the original string (!) to find another string with the same hash in less time than a brute force attack would cost. If you use a MD5-hash to authenticate a file (for instance to avoid that an infected computerprogram would be downloaded), then MD5 is not secure: it is possible to make another file, possibly malicious, with the same MD5. Still it will not be easy (no ready-made algorithms AFAIK) to make that fake file exactly as long as the first one and have all false information you want on board, so even with this we are not talking about a big risk in everyday practice. And the weakness is of no use for the reconstruction of passwords. For reconstruction of a password from the Joomla-db you only have 2 possibilities: compare the password with a list of possible passwords (dictionary attack) or else: brute force. A rainbow-table is just a precomputed dictionary attack, but that is only usefull if the same password for different users would be hashed in exactly the same way; the salt however prevents that, so it is not useful to produce a rainbow-table. But a "normal" dictionary attack is still possible. The same holds for all hashing algorithms. If a password is in the used dictionary, then a dictionary attack will succeed in a reasonable time, always, with any (!) hashing algorithm. So we are only dealing with brute force. The longer it takes to encrypt a string, the more a brute-force attack would be slowed down. This is very much a moving horizon: with ever faster computers (and the possibility to spread computations over several computers), any hash wil once be reverse-engineered using brute force. There are also limitations on the expensiveness of an algorithm: we want Joomla not only be used on the fastest servers and still be able to login within a reasonable amount of time. Now let's look at what we are securing with the hashed passwords. We want to avoid that, once someone has hacked your system (or has a copy of your db) can easily retrieve the passwords. The first (and real) problem is: that someone has intruded into your system! If they can read your db, then they might possibly also install extensions or other programs on your server... and read the plain text password that is server-side provided by users at every login. I think that discussions like this should be on the mailinglist and not on the tracker, but because the discussion is here now and because I want to react timely when someone proposes features that I think are not useful (as we learned from anotehr case lately), I have put it here too. |
Ingezonden door: Jason Williams Toevoegen datum: 2012-01-09 01:18:14 @hermen there is a diiscussion on the mailing list about this patch, you can find it here. https://groups.google.com/forum/#!topic/joomla-dev-cms/mzb0utUj0wg/discussion Secondly you haven't really told us anything we don't already know. You've just explained how hashing/cracking works then told us why the feature isnt useful. Maybe explain reasons why you don't think its useful or why moving off MD5 would be a bad idea in your view. I don't see how using a more secure algorithm is 'not useful' when its protecting thousands if not millions of user passwords. As for the expensive/slow argument, bcrypt can be tuned, and login times are no different than they were before. |
Ingezonden door: Herman Peeren Toevoegen datum: 2012-01-09 07:05:10 No, I just explained why other hashing algorithms are NOT more secure than MD5 when it concerns the hashing of the passwords in the db: the weakness of MD5 is only important when using an MD5 to authenticate a file (for you can make another file with the same MD5). Taking another hashing algorithm for the hashing of Joomla passwords won't give you more security: dictionary attacks will still be possible and there is only a small gain in slowing down a brute force (and tuning bcrypt down to the same login times as they were before speeds up the brute force so the gain is minimal). In the mailinglist, of which I'm well aware, are arguments why the change of this algorithm will give you a lot of trouble. So: the gain is nothing (or not worth it) and there are considerable costs. That is why I think this patch must not be applied. Moreover: we are securing the retrieval of passwords once someone has broken into your system. But at the same time anyone who logs in hands over her/his password to the system; that only takes a few lines of authentication-plugin to intercept. You are working on a better safe in a house (where you keep a copy of the keys of the house) for in case a burgler comes in and steals the safe. But at the same time, anyone entering the house, puts the key on the table. If I was the burglar I wouldn't take the trouble to break the safe, but grab the keys that are laying around. Security is better improved by not putting the keys on the table and in the first place: by keeping the burglar outside. Improving the code of the safe is just marginal (and gives more troubles than it solves). |
Taking another hashing algorithm for the hashing of Joomla passwords won't give you more security.
Unix and Linux vendors are moving to using 256- and 512-bit SHA-2 for secure password hashing.[8] NIST's directive that U.S. government agencies must stop uses of SHA-1 after 2010,[9] and the completion of SHA-3, may accelerate migration away from SHA-1.
In the mailinglist, of which I'm well aware, are arguments why the change ofthis algorithm will give you a lot of trouble.
Since SHA-512 will now always be included in the PHP minimum
requirement of Joomla 3.0, there is no issues when people would
migrate their sites.
SHA-512 does provide a bit more defence against brute force attacks,
as GPU's currently don't handle larger bit hashing at the moment. And
many corporations require this these days. For people that require
this for 2.5 use the following extension:
http://extensions.joomla.org/extensions/access-a-security/site-access/authentication-management/18225
I would suggest making 2 changes to the current patch
1: Make SHA-512 the default
2: Code needs to be cleaned up a bit (less code is required if the
hasing type is the last in the stored string and not the first)
Thanks, Marius
Hi allSo as the MD5 hashing algorithm Joomla! uses is getting old and weak. I've decided to create a patch which allows admins to set a new, more secure hashing algorithm.There is still some debate over whether users should choose the algorithm they want or whether we should just change it anyway in the background.The current choices are (MD5, SHA-1, SHA256, SHA-512, bcrypt)Here is the patch i created:Would love some feedback on this.ThanksJason
Technically seen, (I repeat) there is no gain in security when taking another
hashing algorithm for the hashing of Joomla passwords.
* the "weakness" of MD5 is of no use for the reconstruction of
passwords. There is no algorithm to "decrypt" a hash! Please look at
what the "flaw" in MD5 is all about and you'll understand that it has
nothing to do with the "decryption" of hashed salted passwords.
* the only difference in security for this kind of password storage
between the different hashing algorithms is the time it takes to use
brute force (and even that is not a real difference: you could as well
hash x-times with MD5 to slow down the brute force).
* the time it will take to produce the hash is the most important
factor determining the time it will take to use brute force. For
security, to avoid brute force you want to make that time as long as
possible. But there is an upper limit to the time it will take to
produce that hash: otherwise authorization would take too long; from a
usability point of view you want to have that time very limited. Given
the hardware, the security-requirements and the usability-requirements
you could calculate an optimum. Main point: there is always a limit to
the time you can spend on hashing.
* if the attacker's hardware is faster than the hardware used by the
Joomla-system, then slowing down the brute force is compensated by a
faster computer. A brute force can always be divided over several
computers (say, for instance, a few thousand in a botnet...). You
cannot always have a better system than the attacker, so brute force
can, in priciple, always be used successfully. It is a race you'll
allways lose.
I'd like to see this be more extendable then simply hard-coded choices.
HI Garyamort
BCrypt is a good candidate for password hashing for it's adjustable slowness. But it could generate some problems when just put into core Joomla: mainly because the cost-factor cannot be lowered without losing the stored passwords, thus giving some portability-problems earlier referred to.
Hi Mark,
Thank you for taking the trouble of answering my post. But I think your comment mainly illustrates what I wrote: the mentioned weaknesses of MD5 (collisions, preimage attacks, and susceptibility to birthday attacks) are only in play when the hash is used to authenticate a document . Could you please explain how those methods could be used to speed up a brute force attack to retrieve passwords? I am very interested in it.
Thank you for taking the trouble of answering my post. But I think your comment mainly illustrates what I wrote: the mentioned weaknesses of MD5 (collisions, preimage attacks, and susceptibility to birthday attacks) are only in play when the hash is used to authenticate a document . Could you please explain how those methods could be used to speed up a brute force attack to retrieve passwords? I am very interested in it.
As you know, when two different inputs generate the same hash, it's called a collision. Collisions happen in every hash, by definition. The weakness of MD5 (and SHA-1) is, that a collision can be constructed and that the source can be constructed in such a way that it is something meaningful (but not the original text). So, although the original text has been changed (to for instance malicious software of a false contract), it still has the same hash. But that is not relevant for password storage.
I agree that time is running out for MD5 for password storage as it will be surpassed by Moore's law (hardware will be faster and faster). That is exactly the same for the other hashes for they all can be generated too fast. Except BCrypt, which is the only one specially developed to be slow enough and can be adjustable slowed down in time. The bitlength of the hash (128 for MD5, 160 for SHA-1, 184 for BCrypt) only influences the chance to hit a collision earlier than the original password, but not the chance to retrieve the original password (which could possibly be used to break into another system, as is a much heard argument).
Except BCrypt all allgorithms need about the same time to find the original password with brute force.
The main factor making a difference is: the length of the password or passphrase, for the brute force time increases (almost) exponential with the length of the password/passphrase. So, the best advice to give to users now, is to make password/passphrase as long as possible.
BCrypt is a good candidate for password hashing for it's adjustable slowness. But it could generate some problems when just put into core Joomla: mainly because the cost-factor cannot be lowered without losing the stored passwords, thus giving some portability-problems earlier referred to. For turning the cost-factor higher, maybe we could write some adapter.
I would personally prefer to send a hash (with the salt and a nonce) instead of a cleartext password from the client as referred to earlier (stop sending passwords!), but at the moment there is no Javascript-implementation of BCrypt and the differences in speed of client-side hardware make it almost impossible to find an acceptable cost-factor. For client-side hashing, MD5 is a better option.
There were two arguments you gave, I disagree with: "When most experts say... etc.". Authority is no valid argument. Hence my citation of Galileo earlier.
The cost factor is currently fixed at 12 (you can change this in the
source and it (should) still work. Its an 'adaptive' hashing
algorithm, its designed to cope with cost changes.
Yes you're right each hash created will have the $2a$12$ at the start
so the function knows that hash was made with a cost factor of 12. You
simply change the cost factor and new hashes will have a different
number. When someone tries to log in with an old cost factor it will
still work because the 12 was in the hash so the function what cost to
use how many to use.
The factor itself isn't worked out automatically, its just picked by
me. There could be some research done into this to find a 'suits all'
factor to begin with.
In terms of maturity. BCrypt itself is already quite mature, its been
around, tried & tested for the past 10 years (bcrypt was the password
file format for OpenBSD); also integrated into FreeBSD, Solaris and
NetBSD. To this day its not been hacked. So I would say its quite safe
to use.
In terms of a patch. Yes I can add a cast factor change and have it
tested by various members not a problem.
The patch already works quite well, the only thing you can't do is
change the cost factor from the admin end. But you could even change
that in the code and it (should) still work.
My question now is, do we want our users controlling the cost? Or do
we want the cost hard-coded in Joomla?
Let me know if that's confusing, im just trying to answer all your questions.
My question now is, do we want our users controlling the cost? Or do
we want the cost hard-coded in Joomla?
Here's one example I was looking at recently: http://thepasswordproject.com/_media/performance-differences-pc2-plus007-plus008b40-lite009-lite010b11.png
--
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/-/8MFNrttZDs8J.
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.
I think the fact that LinkedIn got hacked last week using SHA-1 encrypted passwords with no salt (?) is another good example / reason why Joomla 3.0 should move on to a more robust / secure hashing algorithm.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.