Move away from default password

[Joseph Reynolds]

On 2019-06-20 02:55, Carter Su wrote:
> Having a default password is a security risk, but if per BMC has an
> unique password, it may not very convenient for customer to use.
> Customers will change the default password when they install new
> machinery, or they may creat new account and password for BMC to use.

Thank you.  I understand that concern.  How do we balance ease of use 
-versus- security?
Having a well-known default password is easy to use, but too many 
installations fail to change the password, which gives attackers an easy 
way to take over the system.  Because of that, new laws are going into 
effect, for example [CA Law SB-327][], which require the system to not 
have a default password.

[CA Law SB-327]: 
https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180SB327

I am looking at three options:

1. Leave the default OpenBMC configuration with the default password.  
That is, if you build an OpenBMC image from source, it will have the 
default password.
I wouldn't change that unless until there is a better alternative.  (See 
2 and 3 below.)

2. Same as option 1, but have a way to set an unique password for each 
system.  Specifically, the firmware image would be identical for 
multiple systems, but the password would be different for each.  You 
could use randomly generated passwords, or a scheme that generates 
password based on the system serial number or some other unique 
identifier (such as a MAC address), with weaker or stronger security 
considerations for each.  Whoever build the BMC image and loads it onto 
the BMC could change the password before giving the BMC to its end user. 
  As you point out, this may be very inconvenient.

3. Create a new feature: a new security mode to restrict the BMC's 
operation to setting up a new account.  Specifically, when this feature 
is engaged, the BMC requires you to create a userid and password before 
its full function can be accessed.

- Joseph

> 
> 
> Carter Su
> 
> 
> ---------- Forwarded message ---------
> From: Stewart Smith <stewart at linux.ibm.com>
> Date: Tue, Jun 18, 2019 at 6:59 AM
> Subject: Re: Move away from default password
> To: Adriana Kobylak <anoo at linux.ibm.com>, Joseph Reynolds 
> <jrey at linux.ibm.com>
> Cc: openbmc <openbmc-bounces+anoo=linux.ibm.com at lists.ozlabs.org>,
> Openbmc <openbmc at lists.ozlabs.org>, Thomaiyar, Richard Marian
> <richard.marian.thomaiyar at linux.intel.com>
> 
> 
> Adriana Kobylak <anoo at linux.ibm.com> writes:
>>>> 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.
>> 
>> How would this new "factory settings" flash partition be protected
>> against being modified by an unauthorized or malicious user?
> 
> My guess would be it'd be protected the same way that the default
> password is today: not at all. If an attacker can write to flash, the
> only way to reset the box is to dediprog the BMC flash chip.
> 
> --
> Stewart Smith
> OPAL Architect, IBM.