This article is part of Managing bug report in issue tracker series.

1. Storing credentials inside your executable is not secure

EurekaLog requires valid credentials (login/password pair or API token) to send bug reports to your bug tracker software (or as e-mail via SMTP client). This means that login/password/API token must be stored in your executable. While EurekaLog never stores login/password/API token as plain text (passwords are always stored encrypted), but your executable still needs to run on client's machines. This means that your executable is under control of your clients. Someone may use network sniffer to extract password/API token. Or someone may attach a debugger to your executable and wait for EurekaLog to decrypt password/API token before sending bug report. While this is not a common thing - it can be done. Your password or API token may be retrieved, even though it is not a simple task.

Important Conclusion: storing passwords inside your executable is not secure!

2. You can avoid storing passwords in your executable

The most bullet-proof solution is just do not store any passwords in your executable. Of course, this would also means that you can not use any send method which requires you to know login/password pair. This leave us with the following send methods:

Shell and (S)MAPI methods use client's e-mail client to send e-mails. Therefore, EurekaLog will use client's account for sending, no need to provide your own account.

SMTP Server method does not require any credentials at all. The down side is that method is often blocked by firewalls and/or ISPs - as it is a great way to send spam. And even if you manage to send e-mail via SMTP Server method - it will most likely be marked as "spam"/"malware"/"fake" message by recipient's e-mail server. You will have to setup explicit rule to exclude such e-mails from spam filter.

HTTP method is a best choice here - as it does not require any credentials and usually safe with firewalls/ISPs, but it will require you to write code (script) to receive submitted bug reports.

While those are not exactly bug tracker send methods, but you still can use them to post bugs to your bug tracker. For example, you may set up your bug tracker to pick up e-mails from certain address and insert them as reports.

And HTTP script may use bug tracker's API to insert bugs. In some cases, your bug tracker may provide a ready-to-use HTTP facade. For example, FogBugz provide options for BugzScout and anonymous sending, Jira has Issue Collector.

Important Conclusion: you can hide your bug tracker (in other words, credentials) behind a facade (either e-mail of HTTP web-form).

3. Minimize impact of discovering your passwords

While the above mentioned send methods are resistant against password stealing, but often it is not a convenient way to submit reports. Those methods also have limitations: you may be not able to count duplicate reports and receive feedback. An exception to this is HTTP sending, which can act as facade to your bug tracker. You can hide actual login/password for bug tracker in your HTTP receiving script. See these examples.

Therefore, most EurekaLog's customers use a compromise way. The idea is that you store password in your executable, but you limit things that you can actually do with this password. Obviously, you should not use your administrator account for sending reports.

Important Conclusion: never use your administrator password in EurekaLog settings.

What you can do to reduce impact of a leaked password:

Create a separate account for automatic submission of bug reports

You should always create a new account, which you will use with EurekaLog. Limit this account as much as possible. Allow it to read issues, create issues and modify issues (restrict modification to "Count" field only - if such fine access restriction is supported). Limit it to one project only - the one which is used to receive bug reports.

This will prevent attacker from altering administrator settings of your bug tracker, alter other accounts, edit other projects, etc.

The most customizable bug tracker in this aspect is Mantis - as it allows you to create account, which will not be able to modify its own profile. Mantis have very rich access-limiting capabilities. The most non-customizable bug tracker is FogBugz - while it have very nice UI, but it have little customization abilities. Other bug trackers are in between. Please, refer to a specific guide for configuration of your bug tracker to learn more.

Protect your account used for automatic submission when possible

If your bug tracker or send method allows to disable changing account - use this opportunity. For example, Mantis allows you to mark account as "Protected", which means its settings and password can not be modified.

Use API tokens when possible

You can use API tokens instead of passwords (if your bug tracker allow that). While this does not remove threat completely, it will greatly reduce risks - because it is usually not possible to alter settings/password without entering account password (which will not be stored in executable when you are using API tokens). Additionally, you may create and revoke API tokens for single reporter account as you like.

Use two-factor auth when possible

Some systems allow you to use two-factor authentication to log in your account. Use this when possible. This is similar to API tokens. Usually you would need to do two things:

A good example is so-called "2-step verification" in Google (GMail). Once you enable it for your account - you won't be able to log in to your account from external application, as logging in would require to enter code from SMS sent to your phone (alternatively you can use application or hardware key). However, you can enter your account settings and create so-called "App Password". App Passwords are used to access accounts from applications which do not support two-factor auth. In other words, you can enter App Password to EurekaLog project settings for SMTP Client send method - and EurekaLog will be able to use your account to send e-mails. However, even if attacker extract App Password from your EurekaLog-enabled executable - he would not be able to log in to your GMail account, as this will require to know key from SMS, GAuth application or hardware token.

Create a separate project for automatic submission

You should create a new "project" specifically for receiving bug reports. In other words, you should create two "projects" in your bug tracker for each EurekaLog-enabled application: use one "project" to receive automated reports and use second "project" for manual managing (bugs, new features requests, etc.). You can either move issues between two projects or make references from one project to another.

This will prevent attacker from messing with your sensitive data. Since auto-reporter account will have access only to one "project" (the one which you use to receive bug reports) - the attacker will not be able to view/edit second project (which you use to work manually) or any other project on your bug tracker.

4. Using file attaches and supplying custom data

You can add arbitrary data to a bug report:

1. If you have data in memory - then you will insert it as values into "Custom" section of bug report;

2. If you have data on disk - then you will attach it as a file.

We understand that there may be cases when you may want to offload data from memory into file attaches. That is why OnAttach/OnZip events offer you a ATempFolder argument, which specifies a writable folder to create file attaches. You are supposed to create a new file in that folder and pass its file name out of event handler. Creating new file in the specified folder will always be successful (well, assuming there is enough disk space).

The reason why we offer creating real files instead of allowing to write data to a stream is because we are trying to minimize memory impact. For example, EurekaLog may be called for "out of memory" exception, and it has to create (and send) bug report under strict memory conditions. For this reason we prefer to unload as much data to files as we can. For example, if you enabled packing for debug information, then debug information will be unpacked into a temporal file, thus conserving memory usage. Another reason is that some send methods (like MAPI for example) accept only real files on disk.

Therefore, any additional files (such as screenshot, memory dumps, etc.) are also stored in this folder. The final .elp (ZIP) file attach is also assembled in that folder (if packing is enabled in options). The folder will be automatically deleted once sending is complete (or fails).

The folder is accessible only by current user account. In other words, both your process and the mentioned files lie within the same security boundary. You are not passing any data between two security zones.

The password for .elp (ZIP) is to protect the file during transfer and not to protect it locally. That is because the password for packing bug report is stored in your executable and can be retrieved by anyone having read access to your compiled binary.

EurekaLog also offers SecureFree function to free memory with wiping (to minimize chances of having sensitive information in various dumps).

5. Complying with GDPR

We can not comment on legal issues in various countries (and GDPR in particular). We can confirm that EurekaLog does contain a lot of options that go directly against GDPR (for example, you can hide dialog, or you can sent automatically without any consent, etc.). Violators of GDPR may be fined up to €20 million, or up to 4% of the annual worldwide turnover of the preceding financial year, whichever is greater. It is up to you to ensure that your application passes GDPR. We recommend to seek help from a local consulting company, which specializes in such tasks.

See also: