Implement password protected screen locking

[mfs12]

• where to store the password?
  • store it on the printer because finally this what is going to be protected?
• how to store the password? just a checksum of the password with a nuance would be enough.
• how should the dialog look like?
  • on top of the screensaver?
  • what if screensaver is disabled?
• how many fails should be allowed?
• what if the device gets reset?
• howto prevent bruteforce attacks?

[dc42]

The primary requirement I am aware of is to operate in a mode in which the display works but you can't enter any commands. I will call this Command Locked mode. Here is a possible outline specification:

• Have a facility to set and store a password or PIN. This could be stored in flash memory or PanelDue, or perhaps in config.g and sent to PanelDue.
• Have an option on the Setup page to put the PanelDue into Command Locked mode. PanelDue will switch to the Status screen.
• When in Command Locked mode, the only buttons that can be actioned will be the Control, Status and Console page selection buttons. If any other button is pressed, a PIN or password popup dialog will be displayed.
• When the PIN or password popup is displayed, if you enter the correct PIN or password (probably followed by pressing an OK button) then PanelDue returns to normal mode
• The PIN/password popup will also have a Cancel button, which removes the popup
• If the PIN/password popup is displayed and no button is pressed for some time, the popup is removed. This could be done on the dimming timeout, i.e. if the dimming timeout expires then as well as dimming the screen, the popup is removed.
• It should be possible to put PanelDue into Command Locked mode from RepRapFirmware.
• If we decide to store the PIN or password in PanelDue flash memory, then it must be possible to reset or clear the PIN/password from RRF, to provide recovery from a lost PIN or password.
• While in Command Locked mode, popup messages continue to be displayed as normal, however any attempt to acknowledge or cancel a message that requires a response will invoke the PIN/password popup.

[mfs12]

@dc42

Have a facility to set and store a password or PIN. This could be stored in flash memory or PanelDue, or perhaps in config.g and sent to PanelDue.

RRF already has a password. Would it make sense to re-use that? then there would be only one password for the system. And the recovery can be done completely with existing infrastructure. Checking with the gcodes, i realized there's not yet a command to verify the password but only to set it.

[mfs12]

I think either everything is configured and handled in RRF, i.e. password, command locking / normal mode, timeout, which is then provided via OM or everything is handled by PD. The latter is my preferred one. I think only the password might be handled still by RRF so there's always a "simple" way of recovery using an already established workflow.

And i would prefer not to bother RRF with all this stuff, except eventually the password. I am still undecided about this point. I think it would be even ok to store the password in PD's flash. Isn't it erased anyway when a new firmware is flashed? Just checked. Not it isn't erased. Can this be erased with bossa?

[dc42]

The present RRF password scheme is insecure in that the password appears in plain text in config.g. Although we are not looking for high security, I think we should do better for this feature. One possibility is that we add a command to set the PanelDue password (e.g. M551 with a S parameter to specify which password is being set), then we send a salted hash of that password to PanelDue, which stores it in NVM if it is different from the one already stored. That means users do not have to put that command in config.g.

[mfs12]

Related to #71.