Question about authentication security

[rickbatka]

Hi! Thanks for the standard and the interoperability it brings. I'm implementing an LMS and LRS that will need to support cmi5 and I don't understand how the current authentication mechanism is sufficiently secure to prevent cheating.

Everything I read about cmi5 courses indicates they can be packaged as zipped html/js, or hosted on external systems. However, if they are packaged as fully client-side content (html/js), it seems like it's impossible to prevent users "spoofing" xAPI statements to look like they came from the AU.

Consider the following:

1. My LMS redirects the current tab (or iframe, or a popup) to the AU entrypoint with "fetchUrl" populated.
   a. A sufficiently advanced user could easily intercept that redirect or iframe with a bit of JS in the browser's developer tools, and obtain the one-time-use "fetch" url.
   b. Even if the users doesn't intercept the fetch URL, they can easily sniff the basic auth token from subsequent xAPI ajax requests or by inspecting the cookies / local storage.
2. The user can fully spoof the AU and publish any valid xAPI statements for this user (though I agree the attack surface is limited to only cheating for this user within this AU, since the auth token is limited to the specific user session).

Additionally, if an attacker can successfully phish (or otherwise exfiltrate) the basic auth token, they are will also be able to issue xAPI requests on the behalf of that user for that AU.

It seems to me the only way to truly prevent cheating would be to require the AU to have a server-side component to do server-to-server communication for xAPI statements and sign them with a private key. Then, the LMS could verify the auth token and public key of the sender and be sure this isn't coming from an attacker's machine, but only from the server that knows the private key for the AU. I can't think of a way to do this client-side, since that would involve exposing the private key to the client.

Does cmi5 / xAPI offer any protection against cheating beyond the easily defated basic auth token? Is there something I'm missing?

Thanks so much!!!

[brianjmiller]

This is what we (at Rustici Software) affectionately refer to as the Pizza Problem (I even mentioned it on the last WG call). Original reference that is still accurate and can really be applied to any interoperability standard: https://scorm.com/blog/scorm-security-some-perspective/

Essentially the answer is, it isn't sufficiently secure to prevent cheating.

Requiring the AU to have a server side component isn't sufficient either, particularly when you start from the premise of "a sufficiently advanced user" because they could still craft requests to the server to have it trigger the mechanism that is used to trigger the statements that fulfill the requirements of the spec.

In fact, you can do cmi5 100% server side, there is nothing to stop you from proxying the launch URL request to a different application endpoint and have the application handle all interaction with the end user and perform the session elements server side, the application just won't be directly interoperable as cmi5. This is where cmi5 truly differs from SCORM in that there is no requirement for there to be a JS (really ECMAScript) runtime available. As the article suggests there are ways to improve the detection of cheating, particularly if the AU is already known to the detecting system, and statement signatures would certainly help with trusting the data is unaltered from the original source (and could be leveraged on either or both the LMS and AU statements (you'd want different private keys)).

Does cmi5 / xAPI offer any protection against cheating beyond the easily defated basic auth token? Is there something I'm missing?

Directly, no. Does it provide a path to something better than SCORM did, IMO yes. Have we seen much uptake or even concern over it, not really (yet).

[rickbatka]

Thanks for taking the time to respond! I agree that delivering packaged, interactive content without a server-side component is always going to necessitate sacrificing control. Indeed, the online games industry has struggled with this for years and the answer hasn't changed in decades: adjudicate everything server-side, trust as little as possible from the client, and only trust the client to report inputs, not the results of their actions.

Requiring the AU to have a server side component isn't sufficient either, particularly when you start from the premise of "a sufficiently advanced user" because they could still craft requests to the server to have it trigger the mechanism that is used to trigger the statements that fulfill the requirements of the spec.

This is a bit disingenuous. Sure, a user could click through the pages of an AU without reading them, just as easily as they could craft a JSON request saying they clicked through the pages. But the real problem is when the user reports a 100% result on taking a quiz. At least with a server-side grading component, the user would have to do the work of finding the right answers and submitting them to the server for grading.

Still, I broadly agree with your assessment, that client-only packaged content will always involve trust and can't effectively prevent cheating.

I also agree that cmi5 courses could be implemented server-side and use a shared secret to communicate server-to-server with the LMS / LRS. This seems like the only surefire way to protect against cheating. But at that point, cmi5 wouldn't be necessary - actually, you'd just be working around it anyway. This is really just a regular OAuth implementation between two server-side systems based on a shared secret - something that happens all the time these days and doesn't necessitate a new standard.

There is a so-called "nuclear" option here: streaming. Hear me out.

If I trust the courseware authors (and do an audit of the AU code and deem it safe), I can host a server-side headless browser and stream the course content to the user, essentially as video (although it could be streamed as rendered HTML - there are some products out there that do this), and have the client's input streamed back to the server. This would let us use fully packaged cmi5 content from trusted providers without also opening the door to cheaters and abusers. The LMS / LRS could only accept statements from the server-side cmi5 player, refusing to accept xAPI statements from end users.

Has anyone done that before - streamed cmi5 courses from a server-running browser? It would be an interesting exercise for sure!

[MrBillMcDonald]

Reviewed in cmi5 working group meeting 6/17/2022.

There is no practical way to guarantee cheating cannot take place with an interoperability standard (like cmi5).
There are multiple methods to reduce the risks of cheating, but that requires control of the learning environment (which is something outside of the scope of cmi5).