-
Bug
-
Resolution: Fixed
-
Low
-
2.2-OD-08, 3.2.0-OD-01, 3.1.2, 3.2.0-OD-11, 3.2.0-OD-12
-
Severity 3 - Minor
-
NOTE: This bug report is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding bug report.
Several customers have reported that their instances have recently been flooded with spam accounts that appear to be part of a systematic phishing attack, which suggests that the honeypot strategy we’ve been using since JSD 3.2 is no longer effective.
This is a slightly different issue to JSD-4324 and JSD-1316 as they were first reported, so to minimise any confusion, please head to JSDSERVER-5706 for more details, including two potential workarounds and a guide to cleaning up the spam.
On behalf of the JSD server team, we’re sorry for the inconvenience this has caused, and we’ll make a solution available as soon as we can.
Hi everyone,
We've fixed this issue. Instead of Captcha, we implemented the honeypot technique to prevent spam bots from creating accounts on the customer portal. Here's more information about it: https://confluence.atlassian.com/adminjiracloud/enabling-public-signup-780861551.html
In JIRA Cloud it is not possible to enable or disable Captcha.
Captcha is automatically enabled when JIRA public signup is enabled.
However when public signup is Service Desk Cloud is enabled, Captcha is not enabled/displayed.
- duplicates
-
-
- Closed
-
- has a regression in
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
JSDSERVER-4856 Update "Enabling public signup and CAPTCHA" documentation
- Closed
- was cloned as
-
DESK-4081 Loading...
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-1316] Service Desk Cloud - Enabling public signup does not display Captcha
When is this going to get fixed in Service Desk Server? I've just had another user getting blocked by being asked to fill out a Captcha that isn't being displayed.
Philip
Hi pch728661396, I think what you are describing is a separate problem. Captcha and the honeypot solution we implemented prevent spam bots from spamming the JIRA Service Desk system with fake accounts and they do not solve the problem of someone else signing you up with your email address.
My email address is llu@atlassian and I'm more than happy to chat with you about it more. We are aware of the potential problem the lack of verification might cause and have been discussing the case. Would love to hear how you use your service desk and what your needs are around user creation.
Cheers,
Lingbo
Hi Lingbo Lu [Atlassian],
How will this help if still no verification email is being send?
I can still create an account on Your behalf and pretend I'm You.
That is not a good solution.
I'm not getting any email verification either so an account can be created using any email!!!!! is it related?
TJ Baker
added a comment - +1 to this one not being 'minor' for us. We don't want our system filled with spam bots.
And this is yet another issue that's over two years old that has actual negative impact on users....
TJ Baker
added a comment - +1 to this one not being 'minor' for us. We don't want our system filled with spam bots.
And this is yet another issue that's over two years old that has actual negative impact on users.... This is not a minor bug. Any customer who gets locked out is faced with a dialog that makes no sense - they are being asked to answer the CAPTCHA question but there is no question! Furthermore, they have no way to contact the administrators for help!
This needs to be fixed and quickly!
This affects Server as well as Cloud.
This is a critical bug that needs to be fixed. I want to enable the people within my organization (>8,000 people) to be able to create Service Desk account without my staff needing to create an account for them; however, I want to prevent people from outside my organization or robots from creating accounts or submitting tickets. There is an enhancement request (https://jira.atlassian.com/browse/JSD-868) to limit accounts to specific domains, but CAPTCHA/Honeypot is another solution. Something needs to be done to fix this ASAP.
The honeypot solution sounds great. Is there any timeline for implementation yet?
Currently it seems very easy to create a bogus account. We just encountered an issue with a junk account sending spam to 80+ users, which is not helping us in our effort to get users to move away from just sending emails and toward interacting with the ticketing system directly.
Several customers have reported that their instances have recently been flooded with spam accounts that appear to be part of a systematic phishing attack, which suggests that the honeypot strategy we’ve been using since JSD 3.2 is no longer effective.
This is a slightly different issue to
JSD-4324andJSD-1316as they were first reported, so to minimise any confusion, please head toJSDSERVER-5706for more details, including two potential workarounds and a guide to cleaning up the spam.On behalf of the JSD server team, we’re sorry for the inconvenience this has caused, and we’ll make a solution available as soon as we can.