search

cbluesprl / moodle-mod_hva

Designed and developed in partnership between Cblue and Hyperfiction, this plug-in allows you to connect any thick client application running on any type of device (PC, smartphone, virtual reality headset, etc.) to the Moodle platform via Web Services.
0 stars 0 forks source link

Pin number validation seems very insecure #8

Open danmarsden opened 2 years ago

danmarsden commented 2 years ago

I haven't looked closely but it looks like users have a 4 digit pin - and that's the only data you pass to the external service when requesting information about a user.

What happens when a site has more than 9999 users?

What happens when a user just randomly decides to send across other pin numbers instead of their own - accessing other users data.

This looks like it needs a rewrite to me.

danmarsden commented 2 years ago

no response here? - would be good for you to comment/give some feedback related to issues reported and how you are dealing with them.

Lhannecart commented 1 year ago

The pins have a lifespan of 2 hours and are then deleted. It is therefore possible to have 9999 users using a VR headset simultaneously with the application of "Hyperfiction VR Activity". The choice was made to use a pin code of only 4 digits because more seems superfluous.

Regarding the problem of verifying the pin code against the users, it is complicated to certify the pin code on the "Hyperfiction VR Activity" application because it is independent from the moodle. As the database is not shared, it is not possible to verify the pin code entered in the "Hyperfiction VR Activity" application and as it is the application that then contacts the moodle platform via the API in order to save the progress of the VR activity in moodle, it is not possible to rely on a user connected to moodle (e.g. via the global $USER).

The only verification we can do on the "Hyperfiction VR Activity" application is to check if the pin code exists via a webservice call and a confirmation request if the pin code is the user's before launching the VR activity.

danmarsden commented 1 year ago

thanks for the feedback - typically a "pin number" is used when you have 2 pieces or factors of known information - eg a userid/username AND a pin - eg a credit card + pin, or a known identity/usercode/usernumber and the pin number is used on top of that to match against the user id also being passed. Even in that case with 2 factors in the online world this is considered pretty bad practice to have a 4 digit "password" and if it's all happening (behind the scenes) and the user themselves isn't passing the id number accross you'd be better using some form of longer password/random hash.

Lhannecart commented 1 year ago

I appreciate your advice. However, this is a choice due to the constraint of the VR application of the company Hyperfiction VR Activity. Their application is designed to work like this and we have little room to manoeuvre. In addition, this choice is also due to the fact that users have to enter the code using a joystick on a virtual keyboard.

danmarsden commented 1 year ago

Thanks - I still think you can do better here - my concern is particularly with your externallib webservices implemented within the plugin code which appears to allow anonymous users to call an internal Moodle webservice.

a four digit pin means there are only 10,000 possible combinations, and someone could very easily hit the moodle webservice endpoint - if they try one per second that would be 7,200 different requests, and a valid pin would leak the Moodle user id, fullname, grading and zip files for any users it finds that match the pin numbers.

I'll have a conversation with our wider plugin review team to see if we think this can be approved in the current form or if we deem that the security and possible privacy risk here is too great to allow approval in the plugins db.

mudrd8mz commented 1 year ago

Can some additional authentication be put in place here? I agree with Dan here. The PIN itself is effectively zero protection here if a simply script (one line bash command really) could easily dump information regarding any user.

Lhannecart commented 1 year ago

Hi @mudrd8mz and @danmarsden ,

We have thought about the problem and we have come up with the following solutions:

we add a possibility to restrict calls from a specific IP address? and/or the webservice takes a fixed key as an additional parameter?

Thanks for your feedback.

danmarsden commented 1 year ago

@Lhannecart what you are describing there is a standard feature of Moodle's core webservices - if you only have a single end-point (eg HVA) calling Moodle to set this information, perhaps you should use moodle's web service implementation to authenticate the HVA system calling Moodle?

More info: https://moodledev.io/docs/apis/subsystems/external https://docs.moodle.org/401/en/Using_web_services