Login module and passwords

[Michael Reach]

At least while we're in the development phase of our new qewd application, I want to keep the logging on

$(document).ready(function(){

EWD.log = true;

EWD.on("ewd-registered", function() {

console.log("event: ewd-registered");

etc.

Problem is, when we do that everybody's login passwords end up in the log. I have a separate module security.js on the back-end (as Rob describes in the docs), but (also as he describes) making a completely separate module on the front-end is harder, and the logging is set on the front-end.

Is there an easy way to protect users' passwords, say by turning logging off just for the login call?

Thanks,

Michael Reach

[Rob Tweed]

I'm not sure what you mean by everybody's login passwords ending up in the log - what you're referring to is the browser-side logging into the browser's console.  If EWD.log is set to true, then anyone running the application in their browser can open their JavaScript console and yes, they'll see the traffic sent from their browser and returned to their browser - and so yes they'll see their passwords etc in the messages their browser sends to the back-end.  But they won't see anyone else's information, and nobody else will see their login info unless they go to someone's browser and opens the JavaScript console.  EWD.log = true affects ONLY the browser-side code for the application that sets it - and won't affect any other application's browser-side code.

Are you actually referring to the QEWD back-end logging?  If so, that's nothing to do with what you set in ewd-client via EWD.log

Rob

[Michael Reach]

Ah, my mistake. I was referring to the back-end logging. That is what I would like to make more selective. How do I do that?

Michael Reach

[Michael Reach]

Since you're here, Rob, let me throw in another question: Is there documentation for qewd besides the list of screencasts? They are really excellent, but something where I can search for things. Thanks!

[Rob Tweed]

The logging to std_output by QEWD is fixed.  You can add your own, but you can't remove/reduce what QEWD itself decides to log.

What I'd suggest is that if you are wanting the logging for development and have other applications in production that you don't want logged for security reasons is:

- Have 2 instances of QEWD listening on different ports (or better still running on two different servers), one for development, one for production

- When starting the production instance of QEWD, pipe its std_output to the null device

- Point your applications that are under development at the development instance of QEWD, and you'll be able to see all its activity being logged.  However all the production logging will disappear into thin air

Rob

[Rob Tweed]

No, for now, the presentation slide decks are the primary source of documentation for in-depth info.  If you use the QEWD-Up methodology then it is documented in detail in the README files in the QEWD Github repository.

There's quite a lot of QEWD-related info that you can search for in this Google Group.

If anyone is willing to fund my time, then I can create documentation that is written and therefore searchable.  As it's very time-consuming, it's not something I'll be doing as a priority over the rest of the development work I do.

Rob

--
You received this message because you are subscribed to the Google Groups "Enterprise Web Developer Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise-web-develope...@googlegroups.com.
To post to this group, send email to enterprise-web-de...@googlegroups.com.
Visit this group at https://groups.google.com/group/enterprise-web-developer-community.
To view this discussion on the web, visit https://groups.google.com/d/msgid/enterprise-web-developer-community/78a94ea4-2911-4f25-b296-767869c2e497%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rob Tweed
Director, M/Gateway Developments Ltd
http://www.mgateway.com

[K.S. Bhaskar]

Unencrypted passwords should never be stored in a database, and hence should never be logged even when database updates are logged. What should be stored in databases is salted hashes of passwords.

Also, I am not sure what M implementation you are using, but if it is YottaDB/GT.M, you can add an additional layer of protection of data at rest by using encrypted databases.

Regards

– Bhaskar

On Wednesday, July 17, 2019 at 8:20:53 AM UTC-4, Michael Reach wrote:

[Michael Reach]

They are not being stored, we are passing them to a hospital-wide app that checks passwords for us. What is being logged are the messages from the front-end to the back-end.

Michael

[Rob Tweed]

Bhaskar

QEWD's logging is to the std_output console, not the attached database.  The log is for diagnostic purposes and will show all messages passing through QEWD at various stages of the message life-cycle.  QEWD doesn't know what each message means - that's an application issue.  So QEWD doesn't know if a message contains sensitive information.

If a password is stored in the YottaDB/Cache database, then that is an application issue and nothing to do with QEWD.

Rob

[K.S. Bhaskar]

The passwords should not be in the messages either. The protocol should be something like this for authentication (assuming the client does not need to authenticate the server):

• Server stores hashed password salted with the userid in database (or flat file).
• Server generates random number and sends to client.
• Based on user input, client generates hashed password salted with userid, salts this hash with the random number, rehashes and sends the rehash to the server.
• Server salts stored hashed password with random number and generates hash, authenticating by comparing this hash with the hash sent by the client.
• Server discards random number.

I don't know what the authentication protocol is for the hospital-wide authentication app, but that should be worked into the above so that all that is logged in the message logs is a hash that is of no use to anyone.

Regards

– Bhaskar

[Rob Tweed]

The best approach is probably to use OpenId Connect (OIDC)

I have a QEWD-based OIDC client, and indeed also an OIDC provider which people can use for such purposes

Rob

[Michael Reach]

Aside from other solutions suggested here, I'm wondering if one approach is to use the session token for encoding/decoding. Can someone remind me; is there front-end access to the session token (is that the right random thing to use?). Then one could use something like CryptoJS.AES to encode the password on the front-end and decode it on the back-end (again, can someone remind me where to get the token?) and the password wouldn't appear in the clear in the logs.

Would this work?

Michael

[rtweed]

I've realised there is actually a mechanism available within the lower-level ewd-qoper8 module which allows you to control what message types get logged in the console.  I'd forgotten about it as it was primarily designed for internal use, but with a bit of trickery you can make use of it.

If you're using the QEWD-Up development pattern, it's pretty straightforward.

First create an onStarted.js file (https://github.com/robtweed/qewd/blob/master/up/docs/Life_Cycle_Events.md#onstarted)

In it you should define an array within the this.userDefined object, defining any message types that you don't want to appear in the log, eg:

    module.exports = function() {

      this.userDefined.dontLog = [

        "login",

        "getUsers"

      ];

    };

Then create an onLoad.js file in the qewd-apps application sub-folder (https://github.com/robtweed/qewd/blob/master/up/docs/InteractiveApps.md#onload)

This should invoke the special worker function that suppresses logging - we pass it that userDefined array, eg:

    module.exports = function() {

      this.dontLog(this.userDefined.dontLog);

    };

and that's it.  Restart the QEWD-Up process and you should no longer see those message types in the console log.

If you're using the older-style way of using QEWD, it's a bit more difficult.  You need to define that userDefined array in your master process startup logic.  The trick is then ensuring that each worker invokes the dontLog() function - you can do that in the init() section of your application's message handler module.

Let me know how you get on

Rob

[Michael Reach]

Looks neat. Could this be made to work from a vue-js framework? - that's what we've been using so far and it's going well.

Thanks,

Michael

[Rob Tweed]

What I’ve described is all back-end stuff so independent of whatever front-end framework you use. 

Rob 

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "Enterprise Web Developer Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise-web-develope...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/enterprise-web-developer-community/38277ab2-3328-4f24-b6ef-b7345ea50a42%40googlegroups.com.

[Michael Reach]

Great, thanks. I'll try it!

To unsubscribe from this group and stop receiving emails from it, send an email to enterprise-web-developer-community+unsubscribe@googlegroups.com.

[Michael Reach]

Rob, I've gotten to try this, but I'm still getting the pwd in the log:

Session Garbage Collector has started in worker 956
Fri, 31 Jul 2020 14:01:32 GMT; master process received response from worker 956: {"type":"workerProcessStarted","ok":956}
new worker 956 started and ready so process queue again
Fri, 31 Jul 2020 14:01:32 GMT; worker 956 received message: {"type":"ewd-reregister","token":"3a82674a-b48a-495e-b2e2-339bf7036da0","socketId":"rFkHBmbNWyG2AERrAAAA","ipAddress":"::ffff:10.249.18.171"}
re-register token 3a82674a-b48a-495e-b2e2-339bf7036da0
Fri, 31 Jul 2020 14:01:32 GMT; master process received response from worker 956: {"type":"ewd-reregister","finished":true,"message":{"ok":true}}
socket rFkHBmbNWyG2AERrAAAA disconnected
Fri, 31 Jul 2020 14:02:02 GMT; worker 956 received message: {"type":"ewd-register","application":"smile","jwt":false,"socketId":"LjeBbAI03UtGEcVLAAAB","ipAddress":"::ffff:10.249.18.171"}
Fri, 31 Jul 2020 14:02:02 GMT; master process received response from worker 956: {"type":"ewd-register","finished":true,"message":{"token":"d08c0c6a-66ac-4a26-9495-5eb888a115f3"}}
Fri, 31 Jul 2020 14:02:10 GMT; worker 956 received message: {"service":"security","type":"login","params":{"jhed":"mreach1","password":"XXXXXXXXX"},"token":"d08c0c6a-66ac-4a26-9495-5eb888a115f3"}
loadModule: handler module loaded for application smile; module: d:\qewd\qewd-up/qewd-apps/smile
running up/qewdAppHandler.js in process 956
onResponsePath = d:\qewd\qewd-up\qewd-apps\security/ASlogin/onResponse.js
onResponsePath = d:\qewd\qewd-up\qewd-apps\security/encryption/onResponse.js
onResponsePath = d:\qewd\qewd-up\qewd-apps\security/login/onResponse.js
onLoadPath = d:\qewd\qewd-up\qewd-apps\security/onLoad.js
beforeHandlerPath = d:\qewd\qewd-up\qewd-apps\security/beforeHandler.js
servicesAllowedPath = d:\qewd\qewd-up\qewd-apps\security/servicesAllowed.json
loadModule: handler module loaded for application security; module: d:\qewd\qewd-up/qewd-apps/security
running up/qewdAppHandler.js in process 5584
...

I believe that this is only happening when I just restarted qewd-up. If I repeat the login right after, I get

socket LjeBbAI03UtGEcVLAAAB disconnected
Fri, 31 Jul 2020 14:05:30 GMT; worker 956 received message: {"type":"ewd-register","application":"smile","jwt":false,"socketId":"lYN36uqaCS9JsVmzAAAC","ipAddress":"::ffff:10.249.18.171"}
Fri, 31 Jul 2020 14:05:30 GMT; master process received response from worker 956: {"type":"ewd-register","finished":true,"message":{"token":"12ede2b3-c6ae-44dc-a8f2-271347826403"}}
956: Checking for expired sessions in CacheTempEWDSession
Finished checking sessions
Fri, 31 Jul 2020 14:05:38 GMT; worker 956 received message: {"type":"getIRlist","params":{"psmileid":"888","otype":"SMILE Employees","usrlvl":0},"token":"12ede2b3-c6ae-44dc-a8f2-271347826403"}
Fri, 31 Jul 2020 14:05:38 GMT; master process received response from worker 956: {"type":"getIRlist","finished":true,"message":{"ok":1,"data":{"ok":1,"IRsObj":{"labIRlist":{"1":{"1":{"PNL":"HPTN","fullnm":"Asociacion Civil Selva 

...

which is the data lookup that happens after the user has logged in.

So here it's working.

Another question: is there a way to tell the onStarted module that the module type 'login' is for the application 'security'? Doesn't matter in this case, but just asking.

Thanks!

On Thursday, August 15, 2019 at 1:38:40 PM UTC-4, rtweed wrote:

[rtweed]

 Already worked with Michael on the solution to this, and his most recent issue related to defining environment variables.

I've pushed out a new version of QEWD (plus some updates to dependent modules) which adds a new Event Hook: onWorkerStarted.  This can be used for both scenarios raised by Michael

See:

https://github.com/robtweed/qewd/blob/master/up/docs/InteractiveApps.md#life-cycle-event-hooks

and

https://github.com/robtweed/qewd/blob/master/up/docs/Life_Cycle_Events.md

[Michael Reach]

Thanks much, Rob!