Root > Solving bugs in your code > Managing bug reports in issue tracker > Security Considerations

Security Considerations

Previous pageReturn to chapter overviewNext page   

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 (e.g. 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 configuration.


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:

1. Enable two-factor auth for your account. This will block access to attacker, who retrieved password from your application - since attacker would have access to password, but not the second key.
2. Create application-specific password. This will allow EurekaLog to send reports. Application-specific password allows using service, but does not allow logging in.


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.



See also:

Send feedback... Build date: 2021-02-14
Last edited: 2018-06-14
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: