Skip to content

Remove sensitive password logging #931

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

steven166
Copy link

Describe in detail the problem you had and how this PR fixes it

  • Passwords of failed login attempt are logged, these can still contains sensitive information.
  • Add external ip address to generated certificate, although it is self signed, the host verification will succeed when you trust the certificate.
  • Add basic auth in order to authenticate without session

Is there an open issue you can link to?

No

@sr229
Copy link
Contributor

sr229 commented Aug 27, 2019

Blocked by GH-857. This will render this CL obsolete by 857. You can retarget against v2 instead once we have merged v2 to master.

@sr229 sr229 added the blocked This issue cannot proceed due to external factors label Sep 12, 2019
@@ -94,7 +96,6 @@ export const createApp = async (options: CreateAppOptions): Promise<{
userAgent = userAgent.join(", ");
}
logger.info("Failed login attempt",
field("password", cookies.password),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be ok to log the hash of the password versus the expected hash. See #952

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is ok, but it wouldn't add any information other than "it doesn't match". Therefor it will only make the logs unreadable.

const certs = await new Promise<pem.CertificateCreationResult>((res, rej): void => {
pem.createCertificate({
selfSigned: true,
altNames: altNames
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should be automatic. Since the certificate is self signed, your computer won't trust alt names anyway.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you decide to trust the self-sigend certificate, the hostname/ip of the certificate still has to match in order to pass for a secure TLS connection.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you positive? We've been using this for a while now without any alt names and no issues have been reported.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm running this behind a proxy (on a different server) which reëncrypts the connection to code-server. The proxy trusts the self-signed certificate of code-server. But it is failing on the hostname verification, because the external ip of code-server is not matching the "localhost" which is in the certificate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's dangerous imo as you can get MITMed easily with a self signed certificate. It's best you generate the certificate yourself and add it as a trusted certificate to the proxy or use HTTP and move code-server onto the proxy server.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess my same reasoning applies in general to code-server generating self signed certificates. 🤔

@sr229
Copy link
Contributor

sr229 commented Oct 28, 2019

No activity since PR was opened. Closing to keep the PR queue clean.

@sr229 sr229 closed this Oct 28, 2019
@sr229 sr229 reopened this Oct 28, 2019
@sr229
Copy link
Contributor

sr229 commented Oct 28, 2019

Reopening to take over.

@sr229 sr229 self-assigned this Oct 28, 2019
@sr229
Copy link
Contributor

sr229 commented Nov 1, 2019

I think this got deprecated by #835 so I'll just close this off.

@sr229 sr229 closed this Nov 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked This issue cannot proceed due to external factors
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants