There's a web service for data processing. It has two interfaces. One of them is a web interface for users registering, paying with PayPal, etc, it uses regular username plus password authentication. The other is for programmatic access from users' programs and it uses separate access keys which are then stored in users' programs to secure programmatic access.
Users can reset those access keys at any moment using the web interface. Once a user resets the access key his application is useless until he enters the new key into the application. This is a serious problem when the application is on showcase in an application store such as Google Play because the user has to republish his application with the new key.
So resetting the key must at all times be a well-thought action, not something done accidentally.
The more or less good solution is a two-step interface with a confirmation page. User is initially on "settings" page where he sees a "reset key" link. The "reset key" link actually leads to a confirmation page which says something like "This is serious thing, click HERE to confirm, otherwise get out of here", the user is required to follow the link under "HERE" to actually have the key reset. "HERE" link leads to
When he clicks "HERE" the following happens:
- His browser sends a
- The service accepts the request, resets the key, sends the new key via email and then replies with
HTTP 200 OKand a webpage saying something like "You're awesome, the key was reset, click THIS to get out of here"
- User's browser shows the "You're awesome" page and it also shows
/Profile/DoResetAccessKeyURL in the address bar
- The user likely navigates elsewhere but it might so happen that he leaves that page open and switches to another tab with lolcats
- Some time later he has his browser restarted (for any reason) but the open tab is kept by the browser and when he visits that tab again his browser runs another
GET /Profile/DoResetAccessKeyrequest and the key is reset again which is usually very, very undesired at that moment.
The proposed improvement has the service reset the key and respond with
HTTP 302 Redirect to /Profile/KeyWasReset. The user's browser sees
HTTP 302 response and requests another page which is at
Profile/KeyWasReset and that page contains "You're awesome" text. This way the browser doesn't store the dangerous URL and accidental reset is prevented.
Is this enough? What else should be done to make this interface protected from accidental key resets?