Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-3762

Create an email verification for new customers created thought the Customer Portal.

XMLWordPrintable

    • 1
    • 8
    • We collect Jira Service Desk feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.

      It would be great to have an email verification for new users created thought the Customer Portal avoiding the creating of new accounts with fake email address.

          Form Name

            [JSDSERVER-3762] Create an email verification for new customers created thought the Customer Portal.

            Shane Cebuliak added a comment -

            In conjunction with automation rules this can be a major security flaw in JIRA & JSD that allows user accounts to sign up without sending a verification email to the email addressed to sign up the account. I can see JSD Cloud has the is feature as per: https://confluence.atlassian.com/servicedeskcloud/blog/2017/07/security-update-verifying-your-customers-email-addresses, however, when will JIRA & JSD SERVER receive these changes? 

            You may ask, "Why is this a security issue?". When using automation rules like the default rule "Set organization using reporter's email domain" provided by Code Barrel's Automation for JIRA (https://blog.codebarrel.io/set-organization-in-jira-service-desk-using-reporters-email-domain-e705be9d4717\), any user may sign up using a domain that is not a valid email address but is a valid domain. Upon creation of the account and creating their first request they are added to the organization associated to the domain as per the automation rule. This then allows the user to login to their JSD account and view any requests shared with the organization in which they faked their email address for.

            Unless invites are sent to email address (as per how it's done with JSD Cloud) or without first verifying an email address, any user may impersonate an email address they don't have access to.

            With today's security threats it is common practice to verify emails before creating accounts. When will this be implemented for JIRA Server products?

            Shane Cebuliak added a comment - In conjunction with automation rules this can be a major security flaw in JIRA & JSD that allows user accounts to sign up without sending a verification email to the email addressed to sign up the account. I can see JSD Cloud has the is feature as per: https://confluence.atlassian.com/servicedeskcloud/blog/2017/07/security-update-verifying-your-customers-email-addresses , however, when will JIRA & JSD SERVER receive these changes?  You may ask, "Why is this a security issue?". When using automation rules like the default rule "Set organization using reporter's email domain" provided by Code Barrel's Automation for JIRA ( https://blog.codebarrel.io/set-organization-in-jira-service-desk-using-reporters-email-domain-e705be9d4717\ ), any user may sign up using a domain that is not a valid email address but is a valid domain. Upon creation of the account and creating their first request they are added to the organization associated to the domain as per the automation rule. This then allows the user to login to their JSD account and view any requests shared with the organization in which they faked their email address for. Unless invites are sent to email address (as per how it's done with JSD Cloud) or without first verifying an email address, any user may impersonate an email address they don't have access to. With today's security threats it is common practice to verify emails before creating accounts. When will this be implemented for JIRA Server products?

            Prem Chudzinski [extensi] added a comment - - edited

            Two of scenarios:

            1. The customer will provide a faulty (typo) email, will be directly redirected to the portal create a ticket and won't be able to receive a response - he won't be able to reset his password - communication will be lost as we won't be able to reach out to the customer...

            2. Someone will create a ticket pretending to be someone else - just for fun - giving for example Atlassian CEO email ... we'll response to Your CEO ... that is not going to be fun anymore. So as I'm able to steal Your identity that is a security gap, and will affect my business. How do I know if a request is real or just the competition tries to "do me a favor".

            Prem Chudzinski [extensi] added a comment - - edited Two of scenarios: 1. The customer will provide a faulty (typo) email, will be directly redirected to the portal create a ticket and won't be able to receive a response - he won't be able to reset his password - communication will be lost as we won't be able to reach out to the customer... 2. Someone will create a ticket pretending to be someone else - just for fun - giving for example Atlassian CEO email ... we'll response to Your CEO ... that is not going to be fun anymore. So as I'm able to steal Your identity that is a security gap, and will affect my business. How do I know if a request is real or just the competition tries to "do me a favor".

              agoldthorpe Aidan Goldthorpe
              aschneider@atlassian.com Adalberto Schneider
              Votes:
              27 Vote for this issue
              Watchers:
              30 Start watching this issue

                Created:
                Updated:
                Resolved: