ESC Sign Up Flow // Password Set-Up
Answered
Client: BellaGroup
Base scenario
- Customer signs up via ESC
- As part of the signup, they provide both the company email (e.g. company@company.com), their contact email (e.g. employee@company.com) and they type in password.
- After taking an initial look at the product catalog in ESC, they decide to sign-off for now and return later.
- When returning to the system a few hours/days later, they try to sign in with the company email and the chosen password. This results in the message "Invalid email or password. Please try again or contact your System Administrator."
- After a few more attempts, they press the "Forgot password" button and submit a request for the company@company.com email address.
Why is the initial set-up not valid anymore:
In the Audit Log two entries are generated:
The customer receives the "Assistance with your password" email in the company@company.com mailbox:
The customer clicks the link and enter their new password. But on clicking the "Reset Password and Sign In" button, they get the following message:
Alternative scenario
An alternative variant of the scenario is the following:
- The exhibitor is a returning customer who has exhibited at past events at Bella Group. Their account data, including the account's email address, has been migrated from our legacy system into Momentus
- The exhibitor receives the link to the ESC from the event organizer. As they know that they have exhibited at Bella Group in the past, they press the "Forgot password?" button and enter the email address registered with their account in Bella, as this is the address that they have used in the past to log in on our legacy portal.
- The rest of the scenario is the same as above: They get the green message and the email, but their attempt to reset the password ends with the same error.
In both variants of the scenario, it would seem to us that the relevant solution should be that the customer should not receive that positive green messsage and a reset password email that doesn't actually work.
Point 4 should just not happen since the Login has already been done successfully.
Additionally the client views this as a security risk as well.
The Reset Password dialogue in ESC (and possibly also other public applications) currently has two different standard replies, distinguishing between whether the user's email address is known to Momentus:
If the email address is known to Momentus:
If the email address is not known to Momentus:
This is a security risk to the software for two reasons:
- The 1st answer explicitly confirms to any external user that the email address, which they have entered, belongs to a registered user.
- Even without that explicitly worded confirmation, simply comparing the "green" versus "red" answers, will allow any external user to deduce the mechanism in place and hence they will be able to deduce whether an email address belongs to a registered user.
To prevent this security risk, we suggest to give the same response in both cases, e.g.
An email will be sent to the email address associated with your Username. It contains instructions on updating your password.
Please follow the instructions in the email to reset your password.
If you do not receive the email, then please check your spam filter as well as the email address entered.
-
This sounds like incorrect usage of emails. They only need to use the contact/employee email. They are trying to reset the account email password, which is not valid. Have them use the contact email only.
-
Thanks for the fast response. Do I get you right that they should completely remove the option to enter a company/account mail address in the sign up process? Step 2 in Base Scenario.
Or do you mean they only should use their contact e-mail for the shown process as they cleary do not in the example? -
Only use the contact email for the process.
-
@...
I got things sorted regarding the mail usage. Client will use different wording and add text box to the sign up process.
Still, a significant issue remains. It is generally possible for users who sign up, to request the password reset function with the wrong mail address (company mail in this case).
The system suggests the user with the green field that there is no issue and also sends the password reset mail to this address which puts the user on a path of being convinced to do the right thing. This leads to unnecessary long interactions and creates confusion. This marks also the core point of the client regarding expectation towards us to do better.
Please have a look at Ticket #311558
Would you consider this as an enhancement? How should we proceed? I think they have a valid point there. -
@...
I had a call with the client, and their concern is, if anyone mistakenly put the account email, their system tells them that this email exist but the password is wrong. And they can request a reset password.They know the user has to use the contact email and not the account email.
For them it is more a security issue rather than an actual problem
-
@... you got any feedback to our last comments? Thanks!
-
There is not a security issue. This is a process issue as it sounds like they do not use account and contact emails correctly. A person's email address should never be in the account email field, that should be a generic inbox, like “sales@company.com”.
-
Understand your point but for this client it does happen in reality which still makes it a case in my opinion.
Why can one go on with it when entering the wrong mail address? Wouldn't it be clearer to implement a clear message at this point? -
I believe this is due to we have a shared password reset feature with all apps. Some apps allow account sign in, thinking this was due to legacy iEBMS, so the shared feature allows resetting account and contact passwords. Each app determines if it allows account or contact sign in. ESC forces contact sign in with a linked company account. So, the shared reset password feature lets the user reset the account password but does not let an account sign in to ESC.
-
Hi @...,
Sarah Götza shared this with me. From my point of view we shouldn't sent the E-Mail if it is an organization account.
Is the iEBMS use case still relevant? Sarah and I are unable to identify any application that supports the login of an organization account. This issue is causing frustration among ESC users, who are unable to log in successfully. Additionally, this situation negatively impacts the bounce rate.
-
I agree. This will get worked out over time as we get all the apps on to the same framework and rules.
-
Should this be issued as an enhancement?
-
Yes
-
Enhancement Request is submitted:
https://app.pendo.io/s/6229449325477888/listen/feedback/views/ZWNAnL_3nsJ6p5EtfWhAOeEO8vg/items?openItem=38Vl19eHn5qpRm4i63Qxk7p6U1M
Please sign in to leave a comment.
Comments
14 comments
Date Votes