After registration, show credentials

[mwild1]

The new web registration flow lost a feature - that the chosen credentials are available on the success page (with the password not visible by default).

I understand this may be controversial, but I strongly feel that the UX benefits are strong, and the security risks are minimal. Discussion and alternative suggestions welcome.

Rationale:

• The next thing the user is going to do after successful registration is re-enter their chosen credentials into an XMPP client, which may be on a different device.
• Not showing them their password punishes them unnecessarily for using a secure one.
• The web registration success page is a "dead end" as far as the user's browsing session goes. If the user did use a secure password and didn't note it down or remember it exactly, they have no way out of this situation.

Security concerns:

• The user may leave the page open, unaware it contains sensitive information. Potential fix: dynamically clear the password after a period of time.
• The browser may cache the sensitive information. Fix: appropriate caching headers, which should be used for all sensitive data served over HTTPS.

[horazont]

• The user may leave the page open, unaware it contains sensitive information. Potential fix: dynamically clear the password after a period of time.

I don't like that potential fix. I might be like "oh ok, the credentials are there, let's get dinner sorted first" and then come back an hour later and realize "oh no.". It would have to be communicated very clearly, and we all know how well we ourselves would read such a notice :).

[mwild1]

I don't like that potential fix. I might be like "oh ok, the credentials are there, let's get dinner sorted first" and then come back an hour later and realize "oh no."

Yes, for sure, it's a compromise. But I would imagine that the vast majority of people will be setting up ~immediately. For those people it's an improvement over the current situation, where access to the credentials is not an option even immediately after form submission.

If we did implement this timeout feature we could consider a warning, a visible timer with an option to cancel it, and finally if the timeout is reached we should provide some advice for users who forgot their password.

[horazont]

Fair, I briefly forgot the previous situation :). Let's roll with it!

[horazont]

This turns out to be really complicated especially with the recent changes to the invite flow for account import/export. In particular:

• The success page is a separate /success GET call, meaning we don't have the form data available anymore. That implies that we have to pass the password in a cookie (which may be tricky to clear!) or a GET parameter (no). I can't think of any other way off the top of my head.
• The POST action to upload import data would have to include the password too, or it will be tricky to communicate to the user that their password will vanish from the view once they upload their account data for import.