Replace basic auth with a custom authentication process

[joelanman]

Browsers no longer always support basic auth so this PR replaces it with:

• middleware to check req.session.authentication is the current encrypted password
• if not, redirect to a new prototype-admin/password page
• a route to check the password POSTed from the page matches the PASSWORD set in the environment
• if so, set req.session.authentication to the current encrypted password
• redirect back to the page initially requested

to test this branch, run:

NODE_ENV=production USE_HTTPS=false PASSWORD=test npm start

Screenshot:

[joelanman]

@ma3574

Hi, is there any further info on "Browsers no longer always support basic auth" as the link in the first comment just links back to this pr? Thanks :)

sorry don't know what happened there, fixed now:
#1019

[joelanman]

discussed with Laurence - we could render the password page without redirecting, using res.render. This would mean the password page does not disrupt the browser history. Something to discuss with @natcarey

[joelanman]

updated with:

• underscore in input name (_password) so the password is not auto-stored
• 10 character password input width (in practice its more like 20 characters and theres no actual limit to the number of character)
• load Frontend JS and initialise it, to focus the Error Summary
• use govuk-grid-column-two-thirds-from-desktop for better use of screen width on tablets

[lfdebrux]

One other thought, we could salt the password. Currently two sites with the same password will have the same cookie value, not a massive issue but is slightly bad practice? Also, if we have a salt, that gives a way to revoke access without changing passwords, which may or may not be useful. Any thoughts on this @natcarey?

[nataliecarey]

@lfdebrux I've just been scanning back through and seen the salt question. I think I brushed it aside before because there's no data store containing the password but actually we could include a salt either:

• A uuid in a config file which is generated and then committed
• Something derived from the service name

Would you see value in either of those?

[lfdebrux]

@natcarey the first thing was more what I was thinking, because it allows changing easily if necessary. If we don't think it is necessary though that is fine.

[joelanman]

I don't have a strong opinion on salt, @natcarey should lead on it. I think you'd need access to someone's cookies to know that both encrypted passwords are the same, so it doesn't feel like a likely scenario. Committing it to git would make it public in many cases no?