Here are a couple of issues that my students and I have identified. What do you think? In March I might have the chance to have students work on some of those issues.
Which are the most important ones for you? Would they become part of the standard Moodle system (if we document the changes well)?
Cheers,
Edgar.
Proposal to improve security:
1. Login
2. IP Restriction
3. History Delete
4. Anonymous User
5. Restrict Email-based Authentication
1. Login
To avoid replay attacks the user is first prompted for the user name.
Then a random value is generated and sent to the client (and stored in an
additional field in the user table). The client enters the
password, it is hashed to MD5. Now the random value is appended and it is
again hashed (MD5) and returned to the server. The server retrieves the random
value and the password (hashed) from the user table and performs the same
operations to verify the login process.
It is important that the concatenation and hashing on the client side really
is performed by the client browser (client side scripting).
The advantage of this process is that the password cannot be replayed even if
no encrypted connection is used. This is useful because many ISP do not allow
(cheap) accounts to use SSL.
2. IP Restriction
Restricting user accounts (or all students of a course) to certain IP
addresses (e.g. campus only) add an additional layer of security preventing
unauthorized users from logging onto the server.
Again, this could be achieved on a Web server level but since Moodle is often
hosted by "standard" Web site providers, an application level restriction is
far easier to handle and can be used on a finer level of granularity.
For instance, if the admin user always works from 2 IP addresses only one can
restrict that admin logons are only possible from these IP addresses
3. Deleting a history
The user has the option to delete his/her log entries that identify him/her by
name and IP address. Clicking the "delete log" button changes the IP address
to "unknown" and replaces the user name with "anonymous user".
4. Anonymous user
Courses that do not allow guests track each users moves. To allow open
discussions on controversial topics (without the fear of having one's opinions
backup to tape and revealed years later) it is useful to allow an "anonymous
mode".
In this mode the user still has to log on (allowing only course participants
to join) but in the log file the user name "anonymous user" is logged and no
IP address is stored.
In addition, the username is not stored and displayed for forum posts.
Clearly, a posting can no longer be edited by the user because the user is not
stored.
Obviously user tracking can still be done on a Web server level but logs are
not that detailed as in Moodle.
5. Restrict Email-based Authentication
Allow only certain email addresses to register when one trusts the provider
(e.g. only own university accounts).