I had a closer look at the credentials module today.
You are warning to use this module for storing credentials for sites which do not include sensitive personal data.
I was thinking to use this module for the teacher to be able to help the student to get access to Gibbon, e.g. to check on his latest markbook results, etc.
I’m not sure if this is really one of the reasons you have created this module. The student’s Gibbon access does contain a few more sensitive personal data, right?
Do you recommend to use this module for this purpose or would you rather disapprove.
Good question. Gibbon does hold a lot personal information, but not all of it is shared with students. However, if I was sharing Markbook information with students, then I would most likely not use Credentials to store the Gibbon logins for students. It is intended more for games, coding apps, learning sites, etc. The risk is that the passwords are stored with two-way encryption, rather than one-way hashing, so anyone breaking into your database and looking at the code can easily reverse the encryption and get the plain text passwords.
Ross
PS, I’ve not forgotten your Timetable question…just short of time right now. Will try and look later on today.
To break into the database is a worst case scenario. I think, in this case the loss of credentials wouldn’t be my highest concern but rather unauthorized changes and the loss of sensitive data.
I consider the risk for this worst case scenario to happen as rather small. Therefore I’ll go for the credentials module for storage of student Gibbon logins.
The next question is, how to transfer the student passwords? These are one-way hashed in gibbonPerson and therefore not accessible. What do you suggest here?
Now that’s a good question. Are the students using the accounts already? If not, reset all the passwords (can be done using SQL and CSV) and then import those passwords from CSV into the Credentials module (there is an inbuild import tool). If the accounts are already in use, then you could try and brute attack your own password hashes, but this is not an area I am an expert in!
That looks like a great workflow…if/when you get it working, can you share the resulting files (anonymised) here?
When you use SQL to set the new passwords, set passwordStrong and passwordStrongSalt to empty, and then use the md5 function in MySQL to hash the password. Once the user logs in, their md5 sum password will be obliterated, and they will get a more strongly hashed/salted version of the password.
Nope, the procedure looks fine as is, so no suggestions to improve.
To create passwords, I generally use a bulk password generator online, and then paste them into my spreadsheet. This one will even do the MD5 for you, so you can insert as plain text, without any additional SQL work: http://manytools.org/network/password-generator/.
I’ll see how best to go about pasting files. I guess it would be better if you green light them before I paste files, right? I’ll get back to you on that.