Best way to hide/encrypt sensitive POST json in javascript console log

I have a simple web server (in python) with some API endpoints, and an HTML page with a form. When a user submits the form, the form data is sent to the web server via an ajax POST call via jquery. The API endpoint is HTTPs.

For one of the API endpoints, one of the parameters it takes is a password. I suppose the data transfer itself (from browser --> server) is secure as the POST is being done over https (and all the validation is being done on the server). However, I'd like to be able to obfuscate the password such that it will not show up in console logs. (Example - the javascript function which actually makes the api call, is a general function which can post to any endpoint. In a debug mode this function will dump the post json it's about to send. So in the case you're calling the endpoint which takes the password, the password would show up in plaintext in the log.)

I was just curious if there is a best practices way to achieve this? Something not overly complicated? Is it best to encrypt in the browser then decrypt in the server? Or a way to just make the logs show *** ? Note - I'm not concerned about the data being intercepted between browser and server, this is just about preventing anything showing up in the console logs in plaintext.

asked Nov 20 '18 at 3:10

ffConundrums

19519

Might want to look into JWT (JSON Web Tokens).

– charlietfl
Nov 20 '18 at 3:24

add a comment |

asked Nov 20 '18 at 3:10

ffConundrums

19519

Might want to look into JWT (JSON Web Tokens).

– charlietfl
Nov 20 '18 at 3:24

add a comment |

asked Nov 20 '18 at 3:10

ffConundrums

19519

javascript passwords console.log password-encryption

asked Nov 20 '18 at 3:10

ffConundrums

19519

asked Nov 20 '18 at 3:10

ffConundrums

19519

asked Nov 20 '18 at 3:10

ffConundrums

19519

asked Nov 20 '18 at 3:10

ffConundrums

19519

asked Nov 20 '18 at 3:10

ffConundrums

19519

Might want to look into JWT (JSON Web Tokens).

– charlietfl
Nov 20 '18 at 3:24

add a comment |

Might want to look into JWT (JSON Web Tokens).

– charlietfl
Nov 20 '18 at 3:24

Might want to look into JWT (JSON Web Tokens).

– charlietfl
Nov 20 '18 at 3:24

add a comment |

2 Answers
2

active

oldest

votes

Don't log it.

As you said, the data is safe in the transport. If the issue is just with the logs, simply fix the logs so you're not logging sensitive data.

It's also important that your log files are kept as secure as the rest of your system. A great deal of security-related information can be derived from raw log files.

answered Nov 20 '18 at 3:39

Brad

115k27232393

I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.

– ffConundrums
Nov 20 '18 at 16:12

1

side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.

– ffConundrums
Nov 20 '18 at 16:13

@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.

– Brad
Nov 20 '18 at 16:13

thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.

– ffConundrums
Nov 20 '18 at 16:16

add a comment |

-1

If the communication is already HTTPS and you are not worried about the data being intercepted, then you can probably use something like serialization:

$(your_password_field).serialize();

Another idea is, if you are using some framework with your Python Server, check their documentation. This post, for example, shows how to use serialization with Django:

https://simpleisbetterthancomplex.com/tutorial/2016/08/29/how-to-work-with-ajax-request-with-django.html

There is also an interesting discussion here:

SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt

answered Nov 20 '18 at 3:32

Bruno Monteiro

519

Can I please have a feedback on why this answer was not useful?

– Bruno Monteiro
Nov 21 '18 at 19:41

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53385660%2fbest-way-to-hide-encrypt-sensitive-post-json-in-javascript-console-log%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

Don't log it.

As you said, the data is safe in the transport. If the issue is just with the logs, simply fix the logs so you're not logging sensitive data.

It's also important that your log files are kept as secure as the rest of your system. A great deal of security-related information can be derived from raw log files.

answered Nov 20 '18 at 3:39

Brad

115k27232393

I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.

– ffConundrums
Nov 20 '18 at 16:12

1

side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.

– ffConundrums
Nov 20 '18 at 16:13

@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.

– Brad
Nov 20 '18 at 16:13

thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.

– ffConundrums
Nov 20 '18 at 16:16

add a comment |

Don't log it.

As you said, the data is safe in the transport. If the issue is just with the logs, simply fix the logs so you're not logging sensitive data.

It's also important that your log files are kept as secure as the rest of your system. A great deal of security-related information can be derived from raw log files.

answered Nov 20 '18 at 3:39

Brad

115k27232393

I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.

– ffConundrums
Nov 20 '18 at 16:12

1

side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.

– ffConundrums
Nov 20 '18 at 16:13

@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.

– Brad
Nov 20 '18 at 16:13

thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.

– ffConundrums
Nov 20 '18 at 16:16

add a comment |

Don't log it.

As you said, the data is safe in the transport. If the issue is just with the logs, simply fix the logs so you're not logging sensitive data.

It's also important that your log files are kept as secure as the rest of your system. A great deal of security-related information can be derived from raw log files.

answered Nov 20 '18 at 3:39

Brad

115k27232393

Don't log it.

As you said, the data is safe in the transport. If the issue is just with the logs, simply fix the logs so you're not logging sensitive data.

It's also important that your log files are kept as secure as the rest of your system. A great deal of security-related information can be derived from raw log files.

answered Nov 20 '18 at 3:39

Brad

115k27232393

answered Nov 20 '18 at 3:39

Brad

115k27232393

answered Nov 20 '18 at 3:39

Brad

115k27232393

answered Nov 20 '18 at 3:39

Brad

115k27232393

I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.

– ffConundrums
Nov 20 '18 at 16:12

1

side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.

– ffConundrums
Nov 20 '18 at 16:13

@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.

– Brad
Nov 20 '18 at 16:13

thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.

– ffConundrums
Nov 20 '18 at 16:16

add a comment |

I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.

– ffConundrums
Nov 20 '18 at 16:12

1

side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.

– ffConundrums
Nov 20 '18 at 16:13

@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.

– Brad
Nov 20 '18 at 16:13

thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.

– ffConundrums
Nov 20 '18 at 16:16

I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.

– ffConundrums
Nov 20 '18 at 16:12

side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.

– ffConundrums
Nov 20 '18 at 16:13

@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.

– Brad
Nov 20 '18 at 16:13

thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.

– ffConundrums
Nov 20 '18 at 16:16

add a comment |

-1

If the communication is already HTTPS and you are not worried about the data being intercepted, then you can probably use something like serialization:

$(your_password_field).serialize();

Another idea is, if you are using some framework with your Python Server, check their documentation. This post, for example, shows how to use serialization with Django:

https://simpleisbetterthancomplex.com/tutorial/2016/08/29/how-to-work-with-ajax-request-with-django.html

There is also an interesting discussion here:

SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt

answered Nov 20 '18 at 3:32

Bruno Monteiro

519

Can I please have a feedback on why this answer was not useful?

– Bruno Monteiro
Nov 21 '18 at 19:41

add a comment |

-1

If the communication is already HTTPS and you are not worried about the data being intercepted, then you can probably use something like serialization:

$(your_password_field).serialize();

Another idea is, if you are using some framework with your Python Server, check their documentation. This post, for example, shows how to use serialization with Django:

https://simpleisbetterthancomplex.com/tutorial/2016/08/29/how-to-work-with-ajax-request-with-django.html

There is also an interesting discussion here:

SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt

answered Nov 20 '18 at 3:32

Bruno Monteiro

519

Can I please have a feedback on why this answer was not useful?

– Bruno Monteiro
Nov 21 '18 at 19:41

add a comment |

-1

If the communication is already HTTPS and you are not worried about the data being intercepted, then you can probably use something like serialization:

$(your_password_field).serialize();

Another idea is, if you are using some framework with your Python Server, check their documentation. This post, for example, shows how to use serialization with Django:

https://simpleisbetterthancomplex.com/tutorial/2016/08/29/how-to-work-with-ajax-request-with-django.html

There is also an interesting discussion here:

SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt

answered Nov 20 '18 at 3:32

Bruno Monteiro

519

If the communication is already HTTPS and you are not worried about the data being intercepted, then you can probably use something like serialization:

$(your_password_field).serialize();

Another idea is, if you are using some framework with your Python Server, check their documentation. This post, for example, shows how to use serialization with Django:

https://simpleisbetterthancomplex.com/tutorial/2016/08/29/how-to-work-with-ajax-request-with-django.html

There is also an interesting discussion here:

SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt

answered Nov 20 '18 at 3:32

Bruno Monteiro

519

answered Nov 20 '18 at 3:32

Bruno Monteiro

519

answered Nov 20 '18 at 3:32

Bruno Monteiro

519

answered Nov 20 '18 at 3:32

Bruno Monteiro

519

Can I please have a feedback on why this answer was not useful?

– Bruno Monteiro
Nov 21 '18 at 19:41

add a comment |

Can I please have a feedback on why this answer was not useful?

– Bruno Monteiro
Nov 21 '18 at 19:41

Can I please have a feedback on why this answer was not useful?

– Bruno Monteiro
Nov 21 '18 at 19:41

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Agfdhyk