I'm looking for help around the best practice for validating identity within an update security details flow.
I am working on the sign-up, login, and updating process for a new web based financial application.
Login is via the usual email/password combo with 2FA via sms after successful password validation.
All security/login screens will be held on IdentityServer, while the application will be on our own servers, this means that accessing the update components must be shown via a new window - this will be chromeless and visually look to be part of the originating site.
As part of security we also request a 'security question', used for when the client phones up, which means we have the following data for security/login.
- email address (not updatable online)
- Password (updatable online)
- Telephone number (updatable online)
- Security Question (updatable online)
(only one of the security details may be changed in 24hrs)
When the client is logged in to the application they will be able to update password, telephone, and their security question from within the app. As this data will be accessed from the "my account" section which will show (and potentially allow updating of) other non-security related data (address, etc.). There is a requirement to re-authenticate the client before they can change any of the security data via re-entering the password.
Update password will be presented a common pattern - enter existing and then new password. For updating mobile phone and security question the password request is proposed to be a first step before accessing the upate component.
There has been a request from the business to duplicate the password functionality (enter password and update compmnent on the same screen) for telephone and security question.
My initial response is to say no as this seems to be mixing the authorisation and update tasks, potentially confusing the client. However, rather than just go with my gut reaction I hope to get some more concrete guidance on the issue.