Move away from default password

[Thomaiyar, Richard Marian]

Joseph,

#1 is not yet covered in any docs yet, but 
https://github.com/openbmc/docs/blob/master/user_management.md#deployment---out-of-factory 
this covers the out of factory deployment.

Regards,

Richard


On 6/17/2019 10:16 PM, Joseph Reynolds wrote:
> 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
>