the fun part is (captured from his post)
I spent 10 years in the 1980’s as a teletype/crypto maintenance technician
and hes not allowing comments on his blog or youtube and all are pending! so nobody can share his opinion!
Well there is nothing funny in what he says.
The main message is that if you allow your teachers to take backups, your teachers get usernames and passwords with backup files and can crack those hashes to get all your site usernames and passwords - including admin username and password.
The guide to prevent teachers (and course creators) from taking those backup files (from role settings or files before moodle 1.7) and deleting of all old backup files is a perfectly good one.
At least all demo sites allowing teacher access should prevent backups immediately - or for example if you trust your students and give them teacher access to one course you might want to do it for those sites as well - or you may soon notice that some student is the admin of your site.
Components and languages may have changed from 1980's but human nature does not change so quickly.
For example last january when phpBB.com was cracked the attacker got details for more than 400,000 accounts, including names, email addresses and hashed passwords and had created a script that was able to break more than 28,000 passwords which were hashed using an unsalted MD5 algorithm.
So basicly if cracker get's one teacher username and password he/she may be able to get full access to your site in a couple of minutes - with default settings of moodle and backup feature. But most sites do trust their teachers and want to give teachers ability to backup and restore courses with full user data.
See also http://en.wikipedia.org/wiki/MD5 - maybe moodle should change current hashing method...
Amr,
see also http://moodle.org/mod/forum/discuss.php?d=137569
The fact that phpBB cracker managed to find out and publish 28000 passwords out of 400000 possible passwords means only 7% success rate (as a number 28000 stolen passwords is huge!) but if we suppose that administrators are wiser than normal users they have selected also stronger passwords than normal users. Hopefully...
Pardon my ignorance, but happen to notice the gentleman was using an XAMPP (Windows) Moodle.
Is this issue the same for "other flavors" ... like Ubuntu or RedHat Enterprise or CentOS ?
Thanks, in advance,
Ken
Is this issue the same for "other flavors" ... like Ubuntu or RedHat Enterprise or CentOS ?
Thanks, in advance,
Ken
It is - operating system does not have any influence.
In a way this "critical vulnerability" tells how world changes. Normal MD5 hashing can not be trusted anymore. The forms that this video demonstrates can crack typical a-z & 0-9 password MD5 hash used in english names but fail with simple characters like å,ä or ö. But it's only because that code is written for english passwords. So if password is strong enough cracking method fails to break MD5 hash.
To mitigate against the vulnerabilities mentioned above, one can add a salt to the passwords before hashing them or use key strengthening where hashing is applyed more than once http://en.wikipedia.org/wiki/Key_strengthening . It makes password cracking more difficult untill crackers create again more powerful tools to break hashes and hashes of hashes.
Most teachers use most likely passwords that are easy to remember unless they are forced to check password strength so most teacher passwords (or admin passwords) of moodle may be crackable - if attacker has/gets teacher access to moodle and teachers are allowed to take course backups (in role settings). Or if attacker gets access to database with some other method like some old vulnerability of phpMyAdmin...
Like Colin said in another post there are still many "ifs" but I don't think this is nonsense at all - current MD5 hashing is not secure enough to protect user passwords but on most sites teachers want to take course backups with user data and passwords. In that case we just need to trust our teachers (and never give teacher access to students), tell teachers to use as strong passwords as they can (with other characters than a-z and 0-9) and wait until moodle gets a better hashing algoritm than MD5 - like http://en.wikipedia.org/wiki/SHA_hash_functions
The point perhaps is not so much moodle vulnerabilities but the failure of some to acknowledge some weaknesses. While MK appreciates some of the significant issues raised (and there are foreign language dicts with millions of entries), what disturbs me is that a few days earlier when I pointed out in another thread that moodle is no more secure than the least trustworthy teacher and that this was insufficiently addressed, the response was nominal....
The path forward is not through denial. The fact that a teacher cannot do a course backup without potentially putting an installation at risk argues for additional attention to backup acls and defaults, attention to default mysql setups in packaged distros and as MK suggests, alternatives to MD5, as with dozens of passwords to remember, it is unlikely that teachers will use passwords of 128 random characters.
In the meantime, I think a thank you is in order for this demonstration....
The path forward is not through denial. The fact that a teacher cannot do a course backup without potentially putting an installation at risk argues for additional attention to backup acls and defaults, attention to default mysql setups in packaged distros and as MK suggests, alternatives to MD5, as with dozens of passwords to remember, it is unlikely that teachers will use passwords of 128 random characters.
In the meantime, I think a thank you is in order for this demonstration....
It's probably not the last demonstration that Figaro alias Steve is going to show us...
For those who can wait until a new hashing algorithm is included in Moodle (and all the passwords are rehashed as users log in again), you can salt your passwords if you are using 1.7, 1.8 or 1.9 (or anything newer than 2006.04.30)
You just need to add something like:
$CFG->passwordsaltmain = 'very-long-as-random-as-possible-string-with-lots-of-symbols-digits-lower-upper-case-letters';
and your passwords will be salted with that string. In fact, while new passwords will be salted with that string, you can define up to 20 salt strings (called $CFG->passwordsaltalt1, called $CFG->passwordsaltalt2, called $CFG->passwordsaltalt3, ...) and Moodle will try to validate user passwords with those alternative salt strings too, in addition to the main salt value. This allows you to rotate your salt string from time to time as long as you keep your old salts in those 20 values.
And I agree with Marc Grober: we should thank Steve from bringing this up and making us developers (even if I don't work for Moodle HQ or a MP) take care of it.
Saludos, Iñaki.
Iñaki,
why is it not enabled by default (salting)?
Ah - but the same issue is in tracker http://tracker.moodle.org/browse/MDL-18807 with priority "Blocker" so I guess Eloy, Petr and other core developers are going to do something for these settings pretty soon...
+ another Blocker http://tracker.moodle.org/browse/MDL-20834 together with http://moodle.org/mod/forum/discuss.php?d=137569 and older posts about topic...
Looks much better now...
+ another Blocker http://tracker.moodle.org/browse/MDL-20834 together with http://moodle.org/mod/forum/discuss.php?d=137569 and older posts about topic...
Looks much better now...
Just so you know, we're going through the various issues related to backup features and problems and working on solutions.
There will be some announcements to registered Moodle admins via the security mailing list about fixes and workarounds very soon (and shortly afterwards, announcements in other more public places).
There will be some announcements to registered Moodle admins via the security mailing list about fixes and workarounds very soon (and shortly afterwards, announcements in other more public places).
Where should the code be applied? Which file?
Thanks,
Miguel Guhlin
Thanks,
Miguel Guhlin
It can be added to site config.php but if that setting actually causes problems for taking course backups and particularly restoring backup files with salted passwords (said Petr in http://tracker.moodle.org/browse/MDL-18807 ) - because salting should be moved with backup/restore process - it might be easier to change just Password Policy - see http://moodle.org/mod/forum/discuss.php?d=137569#p601941
Thanks for Iñaki for the note - it works pretty well at least against current cracker scripts. I suppose the most important thing is to use at least one non-alphanumeric character (other than a-z & 0-9) in passwords and make sure that all current users change their old weak passwords to new strengthened ones. None of the 10 strengthened passwords (after change of Password Policy setting) that I tested with hash seek script could be cracked. (Now - but it is possible that in the near future those scripts can break all MD5 hashes)
Steve? You mean the reprobate banned from this community identified in the parallel thread as being a "troll" who should be ignored? Nahhhhh....
Jane Goodall suggested in a recent interview that fundamentalism, all fundamentalism, presents a threat to the Earth's survival. While I don't think she had moodle evangelistas specifically in mind the underlying analysis applies.
Oh, and global warming is not the end of the world....
In any event, I appreciate Maunos and Inakis (sorry but have yet to figure out how to do the ~n on this darn phone) open mindedness.
Jane Goodall suggested in a recent interview that fundamentalism, all fundamentalism, presents a threat to the Earth's survival. While I don't think she had moodle evangelistas specifically in mind the underlying analysis applies.
Oh, and global warming is not the end of the world....
In any event, I appreciate Maunos and Inakis (sorry but have yet to figure out how to do the ~n on this darn phone) open mindedness.
I use always clipboard copy-paste with "hard names" ...
I don't know if it is a small mishap or something else but if you check carefully the long demonstration by Figaro ( Steve has just grown a beard... ) you should notice that there are no strong passwords - all passwords are weak, lowercase letters and numbers. Hopefully Figaro can create a 3rd demonstration about same user data with some passwords that are combinations of uppercase and lowercase letters, numbers, and non-alphanumeric symbols ( 8 characters should be long enough ) - and check if hash seek script can break any of these. Something as simple as "1Steve#H"
Microsoft suggests that passwords should be 14 characters or longer http://www.microsoft.com/protect/fraud/passwords/create.aspx but it looks like at least this particular hash seek crack script is using only alphanumeric characters and can't handle even short passwords with non-alphanumeric characters. At least my test cases failed.
Still this can be called a critical vulnerability and should be fixed ASAP because most teachers may use only alphanumeric characters.
If one encouraged one's users to think pass phrase as opposed to password (though we may agree there may be no diff) and to play with the phrase through random replacement, so this:
"Whan7that7Apri11e7with7his7sh8res7s8te"
becomes easy for the English teacher to remember
but again I think one misses the point if one focuses on the particulars ....
"Whan7that7Apri11e7with7his7sh8res7s8te"
becomes easy for the English teacher to remember
but again I think one misses the point if one focuses on the particulars ....
"Trolls" can be nice as well if they want to - see for example http://davidleeshort.com/wordpress/?p=243
Steve? He's no more a mythical creature than either of us..... Demons are historically fabricated for socio-political purposes.
Btw, stottmeister.com has a somewhat unique analysis of some of the larger tables available, including some with rather more extensive foreign language than that employed in the video....
Thanks for the link - I will check it...
Marc,
I tested 10 different MD5 online crack scripts found from your link and they all failed with simple MD5 hashed password "1Steve#H" - 4367b1a05d4734b15efff3881f10966d
http://www.hashchecker.com/ was not available - site expains on front page that it is only for Security Professionals to check password reliability - according to charlist it might have succeeded but I did not want to pay for trial and I did not try local software ( RainbowCrack, Cain & Abel, MD5 GPU Crack or John the Ripper ) - I may be eager to test things but not so crazy I would touch local cracker programs in home PC.
Anyway at least this tiny test shows that password does not need to be long and yet none of the online MD5 cracking tools was able to break as simple password as
"1Steve#H" - and it does not even have any scandinavian letters like å, ä or ö 
Yes, such exploitation depends on the admin and user being largely oblivious.... and the question is who is responsible for edification of moodle admin and user as to such possibilities?
Marc,
I guess we are all responsible:
- Martin is responsible for edification of registered sites and public announcements...
- All developers are responsible for trying to write such code that is not vulnerable...
- All administrators are responsible for reading announcements and documentation - and upgrading their sites and settings...
- All teachers are responsible for teaching, following the advice given by administrators, following Privacy Policy of each site and user data and not giving teacher access for students...
Crackers may think that they are not responsible for anything but if police catches on to what they were doing each country has some laws for this kind of issues. 
PS. I don't believe that any personal data has been compromised this way - anywhere - before the demonstration by Steve. Yet it is very likely that somebody somewhere will try this kind of attack now - if he/she just has/gets teacher access. And hopefully all teachers all over the world have some moral, trust and occupational attitude to keep moodle sites up and running also in the future
Frankly, as I think you are suggesting, if Moodle installations had appropriate security practices otherwise in place, this weakness would present concerns but arguably would not likely be exploitable as in such a regiment passwords would not be in the rainbow tables.... Moreover, it is unlikely that a cadre of evil trolls insinuated itself into the halls of academe for the purpose of placing student learning at risk globally (though I suppose that is a possibility......)
But the question was rhetorical in that as I read the history, this was considered a design feature, if you will, in the same sense as was discussed with registration and profile spam.....
But the question was rhetorical in that as I read the history, this was considered a design feature, if you will, in the same sense as was discussed with registration and profile spam.....
It's much easier to change the future than to change history - all old backup files can't be deleted (people may have downloaded them to local harddisks etc) but passwords can be changed, roles & capabilities (to take backups and restore old backups with or without passwords can be changed and so on.
Profile spam has not vanished in a couple of years - but is it a big surprise after all:
http://technet.microsoft.com/en-us/magazine/2008.11.securitywatch.aspx?=blog#id0080024
I updated my installation this morning (MOODLE19_STABLE) and received the new code that recommends adding the salt in the config.php file. I added it, logged-in, and it forced me to change my admin password. That worked fine, but when I went to the security report (Reports -> Security Overview) it said my salt was too weak. I changed the salt to a much stronger value and then tried to login and I cannot login anymore. How can I fix this?
Sounds like a saturated liquid (too much salt in Chemistry...) 
I might try to take away salt from config.php - open phpmyadmin and try the old trick to edit table mdl_user and your password field, enter the new password ('oldpasswordhere' in this image) and select from drop down list MD5 hashing - and press Go.
With sql the command without salt might look something like this (supposing that your user id is 3):
UPDATE `nameofyourdatabase`.`mdl_user` SET `password` = MD5( 'oldpasswordhere' ) WHERE `mdl_user`.`id` =3 LIMIT 1 ;
I haven't seen the new code and haven't tested how it works but I suppose developers will soon give some more info... have you reported to tracker?
PS. Note that password does not need to be 'oldpasswordhere' - it's just an example...
PS2. If this does not work the other trial could be to create a new accaount and copy the new salted password to your troublesome field - and delete the new account.
As you found out, Moodle must know what salt you used when you created your password, in order to verify the password. You may specify up to 20 alternate salts for checking passwords by setting $CFG->passwordsaltalt1 up to $CFG->passwordsaltalt20.
If you still remember the old salt, put it in $CFG->passwordsaltalt1 in config.php and Moodle will use it.
And if Ryan does not remember the old salt...or uses wrong salt... 
"Moodle must know what salt you used when you created your password..."
I don't get this - salt should be optional spice in passwords and people should be able to use strong passwords also without salt - or has it changed ???
If you forget password and ask new password does moodle use now automatically first salt $CFG->passwordsaltalt1 together with new password ?
I don't get this - salt should be optional spice in passwords and people should be able to use strong passwords also without salt - or has it changed ???
You are able to use strong passwords without salt. Most people simply don't. That's why salting will be enabled by default from 1.9.7 (or so I've heard).
In fact, Moodle tries to verify your password with all the configured salts and without any salting at all.
It has to do it as it isn't storing the salt with the password (to make it even more difficult to crack it). So it doesn't know if your password is salted or not, and which salt was used to salt it.
That's why everytime you change your main salt value, you have to store all the previous ones in $CFG->passwordsaltaltXX (where XX is in 1..20).
If you forget password and ask new password does moodle use now automatically first salt $CFG->passwordsaltalt1 together with new password ?
It always salts new passwords with your main salt ($CFG->passwordsaltmain).
Saludos, Iñaki.
Thanks, Iñaki!
Thanks for the help, everybody. I put my original salt (yes I saved it!):
$CFG->passwordsaltalt1 = 'original_salt';
and I can now login again. Is there a SQL command I can run to re-salt all of my user account passwords based on my new complex salt? That way I don't need the alternate salt listed in my config file anymore. Right now, normal user accounts cannot login without the alternate salt listed.
I agree with Mauno, this is becoming quite the Chemistry experiment.
$CFG->passwordsaltalt1 = 'original_salt';
and I can now login again. Is there a SQL command I can run to re-salt all of my user account passwords based on my new complex salt? That way I don't need the alternate salt listed in my config file anymore. Right now, normal user accounts cannot login without the alternate salt listed.
I agree with Mauno, this is becoming quite the Chemistry experiment.
This is no experiment, password salt is just a new concept for our users 
Is it possible to convert all old password hashes in DB to use new salt?
No, it is not possible, because we need to know old password in plain text - we only have md5 hashes now. We have to wait until user logs in and then use the new salt and password in plaintext and create a md5 hash from salt+password.
If system does not know the original salt the password can not be verified/cracked - that is the actual security improvement
Petr
Is it possible to convert all old password hashes in DB to use new salt?
No, it is not possible, because we need to know old password in plain text - we only have md5 hashes now. We have to wait until user logs in and then use the new salt and password in plaintext and create a md5 hash from salt+password.
If system does not know the original salt the password can not be verified/cracked - that is the actual security improvement
Petr
Not only do we not know the original password in plain text, but we also don't know which passwords are salted or not, since they all just MD5 hashes. So there's no way of telling which records need to be (re-)salted in the first place.
By the way, the password can still be cracked if the salt is too weak (or, more precisely, if the password plus the salt is weak), by trying various substrings. So you need to pick a strong salt!
By the way, the password can still be cracked if the salt is too weak (or, more precisely, if the password plus the salt is weak), by trying various substrings. So you need to pick a strong salt!
It was just a salty joke - this current solution is already super saturated solution 
Just for fun I counted how long would it take to count and crack all possible combinations of passwords and salts for current super computers (or cracker networks) - for 3 example values (using brute force for all possible strings like Hubert suggested)
If they can count about 1 quadrillion calculations per second (one petaflop) calculating all MD5 hashed passwords lasts for unsalted passwords that Steve presented (only lowercase letters & numbers) about 0.003 seconds. If crackers want to find out all possible MD5 hashed combinations of 28 printable ascii characters from 95 possible characters (for example 8 characters in password and 20 characters in salt, 14 characters in password and salt (both) or 20 characters in password and 8 characters in salt) it might take 753 627 922 450 796 000 000 000 000 000 000 years but we are no more alive to see that happen
In reality it won't take so long because computers get better and better all the time but I think this solution is good enough to protect passwords even with MD5 hashing.
| Password+Salt | Ascii | Combinations | sec | ||||
| 8 | 36 | 2.82111E+12 | 0.00282111 | ||||
| 8 | 62 | 2.1834E+14 | 0.218340106 | ||||
| 8 | 95 | 6.6342E+15 | 6.634204313 | ||||
| Password+Salt | Ascii | Combinations | sec | min | hours | days | years |
| 14 | 36 | 6.14094E+21 | 6140942.214 | 102349.0369 | 1705.817282 | 71.07572007 | 0.194594716 |
| 14 | 62 | 1.24018E+25 | 12401769435 | 206696157.2 | 3444935.954 | 143538.9981 | 392.9883589 |
| 14 | 95 | 4.87675E+27 | 4.87675E+12 | 81279163186 | 1354652720 | 56443863.32 | 154534.8756 |
| Password+Salt | Ascii | Combinations | sec | min | hours | days | years |
| 28 | 36 | 3.77112E+43 | 3.77112E+28 | 6.2852E+26 | 1.04753E+25 | 4.36472E+23 | 1.19499E+21 |
| 28 | 62 | 1.53804E+50 | 1.53804E+35 | 2.5634E+33 | 4.27233E+31 | 1.78014E+30 | 4.87375E+27 |
| 28 | 95 | 2.37827E+55 | 2.37827E+40 | 3.96378E+38 | 6.6063E+36 | 2.75263E+35 | 7.53628E+32 |
Hi all
Are you considering substituting md5? MD5 is no longer recommended for new applications in cryptographic standards (PKCS#1).
Why don't you change the hash function (SHA-1 for instance)?
Thanks in advance.
Are you considering substituting md5? MD5 is no longer recommended for new applications in cryptographic standards (PKCS#1).
Why don't you change the hash function (SHA-1 for instance)?
Thanks in advance.
I don't think it would make any big difference anymore now that developers added strong salting to passwords. If you check http://en.wikipedia.org/wiki/SHA_hash_functions
"In 2005, security flaws were identified in SHA-1, namely that a possible mathematical weakness might exist, indicating that a stronger hash function would be desirable.Although no attacks have yet been reported on the SHA-2 variants, they are algorithmically similar to SHA-1 and so efforts are underway to develop improved alternatives.A new hash standard, SHA-3, is currently under development – the function will be selected via an open competition running between fall 2008 and 2012."
If you use 20-40 characters long and strong salt it is in practise impossible to break any MD5 hashed password in human lifetime even if the password might be a, b or c. Or if you use 20-40 characters long and strong password it is in practise impossible to crack any MD5 hashed password in human lifetime even if it is unsalted.
On the other hand it is possible to guess admin password if admin is using username 'admin' and password 'admin' - and that's the only reason why hopeless brute force bots are hammering servers with long lists of english names or number combinations like '123456'.
I made the same suggestion to change hashing method from MD5 to "something better" in some previous posts but it does not look necessary anymore - the current solution with MD5 and salt is just as strong as SHA-1 solution if users just select such passwords that are not "guessable" and salt is well selected.
Hi Mauno
Not knowing the precise details of the attacks against MD5, I remember a year or so that some folk were able to create rogue CA certificates based on MD5 collisions. This caused most of CAs migrating to SHA-1. This makes me think... Of course the application is different, but it would make any big difference to implement this using a stronger hash function... and SHA-1 seems to be at the moment.
Thanks for your comments Mauno
Not knowing the precise details of the attacks against MD5, I remember a year or so that some folk were able to create rogue CA certificates based on MD5 collisions. This caused most of CAs migrating to SHA-1. This makes me think... Of course the application is different, but it would make any big difference to implement this using a stronger hash function... and SHA-1 seems to be at the moment.
Thanks for your comments Mauno
Juan,
you are right, the reason why people started to change MD5 to SHA-1 was collisions - two distinct passwords can have the same hash and this way it is possible to get in with "wrong password". But SHA-1 and even SHA-2 have those collisions - see for example http://eprint.iacr.org/2008/270.pdf - "The success probability of our 22-step attack is 1 for both SHA-256 and SHA-512"
Another quote from previous wiki page: "Because progress in analyzing existing cryptographic hash algorithms is always possible, a hash which is effectively invulnerable today may become vulnerable tomorrow. Both MD5 and SHA-1, long thought secure, have been shown vulnerable to less than brute force efficiency attacks."
The best method of preventing password cracking is to ensure that attackers cannot never get access even to the hashed password.
Salting increases the difficulty of precomputation attacks, perhaps sufficiently to resist all attacks, but in theory any password can be cracked - by guessing, brute force...or with luck in finding a collision for correct password. For a well selected password or salt it may just last millions of years to find the correct password.
There are different types of attacks against hash functions. The main vulnerability that has been found in hash functions is a collision attack -- finding two texts that have the same hash value, without having a hash value specified. This is a much easier attack, and is not applicable to password security.
The main attack that affects password security is a preimage attack, in which the hash value is specified in advance. AFAIK, there are no known practical preimage attacks against any of the (cryptographic) hash functions.
By the way, all hash functions, by their nature, have collisions -- you are mapping a larger space (passwords can be arbitrary length, so the space of possible passwords is infinite) into a smaller space (hashes have fixed length, so the space of possible hashes is finite). But a good hash function makes it hard to start with a hash value, and find a matching plaintext value.
The main attack that affects password security is a preimage attack, in which the hash value is specified in advance. AFAIK, there are no known practical preimage attacks against any of the (cryptographic) hash functions.
By the way, all hash functions, by their nature, have collisions -- you are mapping a larger space (passwords can be arbitrary length, so the space of possible passwords is infinite) into a smaller space (hashes have fixed length, so the space of possible hashes is finite). But a good hash function makes it hard to start with a hash value, and find a matching plaintext value.
The main vulnerability that has been found in hash functions is a collision attack -- finding two texts that have the same hash value, without having a hash value specified. This is a much easier attack, and is not applicable to password security.
Ok that was the point Thanks to all for your comments
Regards ;)
Ok that was the point
Regards ;)
Just a side note...
AFAIK sha-1 is better for collisions agree, but only for that. Some time ago one security flaw was detected in the algorithm (mathematical stuff) that causes it to be less "secure" (easily reversible) than expected.
Since then I've seen various places pointing to SHA-192 as "good enough" to replace MD5/SHA-1.
In any case, as commented by Mauno, salted passwords + MD5 makes life tons harder for crackers, agree.
Finally, changing Moodle's hashing of passwords from MD5 to XXX, while possible, will have to wait a bit in any case, mainly because only PHP5 includes the necessary stuff to use alternative digests/hashes. And PHP5 won't be a must until Moodle 2.0.
Ciao
AFAIK sha-1 is better for collisions agree, but only for that. Some time ago one security flaw was detected in the algorithm (mathematical stuff) that causes it to be less "secure" (easily reversible) than expected.
Since then I've seen various places pointing to SHA-192 as "good enough" to replace MD5/SHA-1.
In any case, as commented by Mauno, salted passwords + MD5 makes life tons harder for crackers, agree.
Finally, changing Moodle's hashing of passwords from MD5 to XXX, while possible, will have to wait a bit in any case, mainly because only PHP5 includes the necessary stuff to use alternative digests/hashes. And PHP5 won't be a must until Moodle 2.0.
Ciao
First, thank all of you for your efforts in this and everything Moodle. Moodle is a great app - esp. for small K12 schools whose total technology alotment for a year might be $2500.00 (Texas).
Just had a thought which I've not seen mentioned in this thread and think it's related. This exploit began with the Teacher ability to enroll students in their course. The listing of potential users list all users ... including users that have a higher level of access.
Why should that be allowed? Seems to me the only users a Teacher should see are accounts set to student level (maybe other teachers) but no higher. Those users would have access to courses anyway, is that correct?
Or is there a reason for this of which am not aware?
Forever a student ... yours,
Ken
Just had a thought which I've not seen mentioned in this thread and think it's related. This exploit began with the Teacher ability to enroll students in their course. The listing of potential users list all users ... including users that have a higher level of access.
Why should that be allowed? Seems to me the only users a Teacher should see are accounts set to student level (maybe other teachers) but no higher. Those users would have access to courses anyway, is that correct?
Or is there a reason for this of which am not aware?
Forever a student ... yours,
Ken
As mentioned elsewhere, tweaking backup is perhaps a more sensible response than salting passwords. Perhaps that will be included in the next build as it is in my opinion the question of the week ;)
Defence in depth: both should be done.
Quick question: can I safely salt if I use Active Directory as a authentication method? Better yet, do I need it then? I do not think my paswords are actually stored in the database (value = 'not cached'), so how can they be stored in the back-ups?
If you use an authentication plugin that does not store the passwords in the Moodle database, then you don't need to worry about salting in Moodle.
caching should be default off