Security, username and password client-side

adlnet / xAPIWrapper

Wrapper to simplify communication to an LRS

https://adlnet.gov/projects/xapi/

Apache License 2.0

219 stars 114 forks source link

Security, username and password client-side #66

Closed lastmjs closed 7 years ago

lastmjs commented 8 years ago

Isn't it a security risk to have the password to your LRS be sent client-side to be used with this library? I'm in the process of using this library to connect to our LRSs, but I'm a little confused at the security. Any insight would be greatly appreciated, thanks!

creighton commented 8 years ago

Yes, putting your credentials client-side is a security risk. There's an assumption with this wrapper that you are ok with those credentials being public. This might be ok in cases like very informal tracking, or where client access is in the hands of trusted users.

For other cases you will likely need to apply other techniques.

you could move the xapi stuff out of the client-side content and send your xapi data via some server
you could use a launch technique like cmi5 or xapi-launch (note: these don't fully remove security issues, but they do keep the credential from needing to be hardcoded in the client-side code)

Full disclosure, I'm not a security guy. These are things I've seen since working with xAPI. I would be very interested in hearing other techniques for securing client-side content.

lastmjs commented 8 years ago

Great, that makes sense. I'm working on a unique solution that I'm hoping will open a lot of doors, I'll post back here in the future with what I've got. I think the security issues should be explained in the documentation. The production system that we're switching from uses this library and our credentials are exposed. We didn't know that, and I'm wondering if maybe they didn't know that either. Or perhaps they didn't know it was a problem.

lastmjs commented 8 years ago

So, here's my solution. I used Scram.js and Express web components to just use the library on my server without modification to the library. It's been working so far!

creighton commented 8 years ago

Very cool. Thanks for letting me know.

liveaspankaj commented 8 years ago

Alternatively, we have a way to generate "short lived", "one time" auth tokens with limited permissions, that we call Secure Tokens. Though, it might currently only work with GrassBlade LRS http://www.nextsoftwaresolutions.com/grassblade-lrs-experience-api/

This article explains the feature and what it does: https://nextsoftwaresolutions.zendesk.com/hc/en-us/articles/207000556-Secure-Tokens-A-critical-Data-Safety-feature

Regards,

Pankaj Agrawal

On Tue, May 10, 2016 at 2:47 PM, tom creighton notifications@github.com wrote:

Very cool. Thanks for letting me know.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/adlnet/xAPIWrapper/issues/66#issuecomment-218103220

creighton commented 8 years ago

We just updated the wrapper to support xAPI Launch. It is another way to keep from adding credentials in your client side code https://github.com/adlnet/xapi-launch