Move away from default password

[Joseph Reynolds]

There is some interest in moving OpenBMC away from a default password.
- email: 
https://lists.ozlabs.org/pipermail/openbmc/2019-June/016515.html  (which 
references a RestrictionMode design: 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/21195)

Having a default password is a security risk.  Note that changing to a 
different default password is not a good solution.  For example, if a 
bad actor learns the default password from one device, that actor will 
likely know the password for many of them.

I am exploring two options for OpenBMC, and want your feedback.

1. Unique password per BMC.
In this approach, there is a way to change the factory default password. 
  Example flow: assemble the BMC, test it, factory reset, generate unique 
password (such as `pwgen`), then use a new function “save factory 
default settings” which would save the current setting into a new 
“factory settings” flash partition.  After that, a factory reset 
would reset to the factory installed password, not to the setting in the 
source code.
Presumably the new factory default would be printed on a sticker, or 
something.
Are there any other factory settings (settings unique to each device) 
that would benefit from being set like this?
One downside to this approach is someone who orders 100 systems has to 
enter 100 unique passwords.

2. Create new account on first access.
Specifically, default OpenBMC to use a new RestrictionMode=SetupAccess 
which:
  - (A) requires users to set up their credentials (at least: remove the 
default password) before they can leave that mode, and
  - (B) does not let the user do anything else, including other 
provisioning or operating the host, while in this mode.
So we could manufacture the BMC with a default password, but require it 
to be changed as the first step to provision the BMC.
We might want to make network services react to this new mode, for 
example, the phosphor-webui GUI would likely want to handle this 
specially, and most REST APIs would be restricted.
Note this approach gives an attacker a window of time before the 
credentials are set up.

I believe both of these approaches represent reasonable security 
practices which may satisfy laws regarding consumer products.  For 
example, CA Law SB-327 
https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180SB327

Are there guidelines we can follow?  Can you find additional 
vulnerabilities with these approaches?  Can we do better than this 
without requiring additional infrastructure?

I plan to discuss this at the 2019-06-26 Security working group meeting: 
https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/
and would be happy to see ideas here.

- Joseph