Design proposal to Non-Interactive password update for REST client

Design proposal to Non-Interactive password update for REST client

[vishwa]

This email is about openbmc/openbmc#1714 ( REST API to update root 
password )

Goal is to do Non-interactive password updates to enable a REST client 
to update the root password.

My proposal is to use `getspent(3)` and `putspent(3)` and here is the flow.

REST client will provide a method that takes std::string as parameter.

The Provider at the BMC will receive the password and does these:

  - Executes `getspent(3)` for "root" and gets the entries.
  - Parses the `sp_pwdp` and extracts `encryption method` , `salt`.
  - Makes a call to `crypt(3)` with the extracted `salt` and `user 
input` and generates encrypted pass-code
  - Populates the structure and calls `putspent(3)` to update the password

Please let me know your opinion on this.

Thank you,

!! Vishwa !!

Re: Design proposal to Non-Interactive password update for REST client

[Kenneth Wilke]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

Could chpasswd be used for that?

________________________________
From: openbmc <openbmc-bounces+kenneth.wilke=rackspace.com@lists.ozlabs.org> on behalf of vishwa <vishwa@linux.vnet.ibm.com>
Sent: Friday, August 11, 2017 11:18:48 AM
To: OpenBMC Maillist
Subject: Design proposal to Non-Interactive password update for REST client

This email is about openbmc/openbmc#1714 ( REST API to update root
password )

Goal is to do Non-interactive password updates to enable a REST client
to update the root password.

My proposal is to use `getspent(3)` and `putspent(3)` and here is the flow.

REST client will provide a method that takes std::string as parameter.

The Provider at the BMC will receive the password and does these:

  - Executes `getspent(3)` for "root" and gets the entries.
  - Parses the `sp_pwdp` and extracts `encryption method` , `salt`.
  - Makes a call to `crypt(3)` with the extracted `salt` and `user
input` and generates encrypted pass-code
  - Populates the structure and calls `putspent(3)` to update the password

Please let me know your opinion on this.

Thank you,

!! Vishwa !!


[-- Attachment #2: Type: text/html, Size: 2214 bytes --]

Re: Design proposal to Non-Interactive password update for REST client

[vishwa]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

Sorry, I should have mentioned that I had looked at that option.

For `chpasswd`, I need to fork a process but with `putspent` I can do in 
same process.

On 08/11/2017 10:20 PM, Kenneth Wilke wrote:
>
> Could chpasswd be used for that?
>
> ------------------------------------------------------------------------
> *From:* openbmc 
> <openbmc-bounces+kenneth.wilke=rackspace.com@lists.ozlabs.org> on 
> behalf of vishwa <vishwa@linux.vnet.ibm.com>
> *Sent:* Friday, August 11, 2017 11:18:48 AM
> *To:* OpenBMC Maillist
> *Subject:* Design proposal to Non-Interactive password update for REST 
> client
> This email is about openbmc/openbmc#1714 ( REST API to update root
> password )
>
> Goal is to do Non-interactive password updates to enable a REST client
> to update the root password.
>
> My proposal is to use `getspent(3)` and `putspent(3)` and here is the 
> flow.
>
> REST client will provide a method that takes std::string as parameter.
>
> The Provider at the BMC will receive the password and does these:
>
>   - Executes `getspent(3)` for "root" and gets the entries.
>   - Parses the `sp_pwdp` and extracts `encryption method` , `salt`.
>   - Makes a call to `crypt(3)` with the extracted `salt` and `user
> input` and generates encrypted pass-code
>   - Populates the structure and calls `putspent(3)` to update the password
>
> Please let me know your opinion on this.
>
> Thank you,
>
> !! Vishwa !!
>


[-- Attachment #2: Type: text/html, Size: 3538 bytes --]

Re: Design proposal to Non-Interactive password update for REST client

[Kenneth Wilke]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

Makes sense, sounds like a good route to me

________________________________
From: vishwa <vishwa@linux.vnet.ibm.com>
Sent: Friday, August 11, 2017 12:11:01 PM
To: Kenneth Wilke; OpenBMC Maillist
Subject: Re: Design proposal to Non-Interactive password update for REST client

Sorry, I should have mentioned that I had looked at that option.

For `chpasswd`, I need to fork a process but with `putspent` I can do in same process.

On 08/11/2017 10:20 PM, Kenneth Wilke wrote:

Could chpasswd be used for that?

________________________________
From: openbmc <openbmc-bounces+kenneth.wilke=rackspace.com@lists.ozlabs.org><mailto:openbmc-bounces+kenneth.wilke=rackspace.com@lists.ozlabs.org> on behalf of vishwa <vishwa@linux.vnet.ibm.com><mailto:vishwa@linux.vnet.ibm.com>
Sent: Friday, August 11, 2017 11:18:48 AM
To: OpenBMC Maillist
Subject: Design proposal to Non-Interactive password update for REST client

This email is about openbmc/openbmc#1714 ( REST API to update root
password )

Goal is to do Non-interactive password updates to enable a REST client
to update the root password.

My proposal is to use `getspent(3)` and `putspent(3)` and here is the flow.

REST client will provide a method that takes std::string as parameter.

The Provider at the BMC will receive the password and does these:

  - Executes `getspent(3)` for "root" and gets the entries.
  - Parses the `sp_pwdp` and extracts `encryption method` , `salt`.
  - Makes a call to `crypt(3)` with the extracted `salt` and `user
input` and generates encrypted pass-code
  - Populates the structure and calls `putspent(3)` to update the password

Please let me know your opinion on this.

Thank you,

!! Vishwa !!



[-- Attachment #2: Type: text/html, Size: 3601 bytes --]

Re: Design proposal to Non-Interactive password update for REST client

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

On Fri, Aug 11, 2017 at 09:48:48PM +0530, vishwa wrote:
> This email is about openbmc/openbmc#1714 ( REST API to update root 
> password )
> 
> Goal is to do Non-interactive password updates to enable a REST client 
> to update the root password.
> 
> My proposal is to use `getspent(3)` and `putspent(3)` and here is the flow.
> 
> REST client will provide a method that takes std::string as parameter.
> 
> The Provider at the BMC will receive the password and does these:
> 
>   - Executes `getspent(3)` for "root" and gets the entries.

Make sure you're using getspent_r for this.

Should be done based on any user, not just 'root'.  We might only
support 'root' now but will want to easily add support for other users
in the near future.

>   - Parses the `sp_pwdp` and extracts `encryption method` , `salt`.

Is there a portable way to do this?  Is there any library that exists
already?

Tom and I spoke previously about a possible non-standard crypt algorithm
in order to satisfy some of the requirements of IPMI RMCP+'s
authentication protocol without storing plaintext passwords.  Please
follow up with him and see if what you are proposing here will mesh with
what he was planning.

>   - Makes a call to `crypt(3)` with the extracted `salt` and `user 
> input` and generates encrypted pass-code

The salt can/should be random for each password, shouldn't it?  It
sounds like you are attempting to reuse the salt from the previous
password and that is not required nor preferred to the best of my
knowledge.

>   - Populates the structure and calls `putspent(3)` to update the password
> 
> Please let me know your opinion on this.
> 
> Thank you,
> 
> !! Vishwa !!
> 

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Design proposal to Non-Interactive password update for REST client

[vishwa]

On 08/14/2017 10:05 PM, Patrick Williams wrote:
> On Fri, Aug 11, 2017 at 09:48:48PM +0530, vishwa wrote:
>> This email is about openbmc/openbmc#1714 ( REST API to update root
>> password )
>>
>> Goal is to do Non-interactive password updates to enable a REST client
>> to update the root password.
>>
>> My proposal is to use `getspent(3)` and `putspent(3)` and here is the flow.
>>
>> REST client will provide a method that takes std::string as parameter.
>>
>> The Provider at the BMC will receive the password and does these:
>>
>>    - Executes `getspent(3)` for "root" and gets the entries.
> Make sure you're using getspent_r for this.
Sure
>
> Should be done based on any user, not just 'root'.  We might only
> support 'root' now but will want to easily add support for other users
> in the near future.

Okay. I will have [User] and [Password] in the yaml.
>>    - Parses the `sp_pwdp` and extracts `encryption method` , `salt`.
> Is there a portable way to do this?  Is there any library that exists
> already?
I tried to look for that and did not find. I will continue looking.
> Tom and I spoke previously about a possible non-standard crypt algorithm
> in order to satisfy some of the requirements of IPMI RMCP+'s
> authentication protocol without storing plaintext passwords.  Please
> follow up with him and see if what you are proposing here will mesh with
> what he was planning.

I told Tom about this and he would get back to me.

BTW, I put the proposal of using crypt() after looking at:

https://github.com/shadow-maint/shadow/blob/master/src/passwd.c#L245

and

https://github.com/shadow-maint/shadow/blob/6fbc11ce2178205968c37853db752729359c9893/lib/encrypt.c

>>    - Makes a call to `crypt(3)` with the extracted `salt` and `user
>> input` and generates encrypted pass-code
> The salt can/should be random for each password, shouldn't it?  It
> sounds like you are attempting to reuse the salt from the previous
> password and that is not required nor preferred to the best of my
> knowledge.
>
Okay. I can generate a random string from [a-zA-Z0-9./] as needed by crypt()
>>    - Populates the structure and calls `putspent(3)` to update the password
>>
>> Please let me know your opinion on this.
>>
>> Thank you,
>>
>> !! Vishwa !!
>>

Re: Design proposal to Non-Interactive password update for REST client

[vishwa]

Tom and I talked and we should be fine with my current proposal.

Here is what we talked:

There would be a new encryption algorithm which would be denoted by some 
number ( Like 1 is for MD5 ) and crypt(3) would be enhanced to handle 
that. Since my proposal does not interpret the number and uses AS IS to 
generate the hash, we should be fine.

On 08/28/2017 05:04 PM, vishwa wrote:
> On 08/14/2017 10:05 PM, Patrick Williams wrote:
>> On Fri, Aug 11, 2017 at 09:48:48PM +0530, vishwa wrote:
>>> This email is about openbmc/openbmc#1714 ( REST API to update root
>>> password )
>>>
>>> Goal is to do Non-interactive password updates to enable a REST client
>>> to update the root password.
>>>
>>> My proposal is to use `getspent(3)` and `putspent(3)` and here is 
>>> the flow.
>>>
>>> REST client will provide a method that takes std::string as parameter.
>>>
>>> The Provider at the BMC will receive the password and does these:
>>>
>>>    - Executes `getspent(3)` for "root" and gets the entries.
>> Make sure you're using getspent_r for this.
> Sure
>>
>> Should be done based on any user, not just 'root'.  We might only
>> support 'root' now but will want to easily add support for other users
>> in the near future.
>
> Okay. I will have [User] and [Password] in the yaml.
>>>    - Parses the `sp_pwdp` and extracts `encryption method` , `salt`.
>> Is there a portable way to do this?  Is there any library that exists
>> already?
> I tried to look for that and did not find. I will continue looking.
>> Tom and I spoke previously about a possible non-standard crypt algorithm
>> in order to satisfy some of the requirements of IPMI RMCP+'s
>> authentication protocol without storing plaintext passwords. Please
>> follow up with him and see if what you are proposing here will mesh with
>> what he was planning.
>
> I told Tom about this and he would get back to me.
>
> BTW, I put the proposal of using crypt() after looking at:
>
> https://github.com/shadow-maint/shadow/blob/master/src/passwd.c#L245
>
> and
>
> https://github.com/shadow-maint/shadow/blob/6fbc11ce2178205968c37853db752729359c9893/lib/encrypt.c 
>
>
>>>    - Makes a call to `crypt(3)` with the extracted `salt` and `user
>>> input` and generates encrypted pass-code
>> The salt can/should be random for each password, shouldn't it? It
>> sounds like you are attempting to reuse the salt from the previous
>> password and that is not required nor preferred to the best of my
>> knowledge.
>>
> Okay. I can generate a random string from [a-zA-Z0-9./] as needed by 
> crypt()
>>>    - Populates the structure and calls `putspent(3)` to update the 
>>> password
>>>
>>> Please let me know your opinion on this.
>>>
>>> Thank you,
>>>
>>> !! Vishwa !!
>>>
>

Re: Design proposal to Non-Interactive password update for REST client

[tomjose]

If the non-standard crypt algorithm is supported, then the 
/etc/security/policy.conf would have be updated with a custom identifier.
The custom crypt algorithm would interpret the id appropriately and 
invoke the custom algorithm to generated the hash.

In the current implementation, it doesn't seem to have a way to plugin a 
custom algorithm to the standard crypt function.

https://docs.oracle.com/cd/E23824_01/html/821-1456/secsys-15.html

On Wednesday 30 August 2017 12:17 PM, vishwa wrote:
> Tom and I talked and we should be fine with my current proposal.
>
> Here is what we talked:
>
> There would be a new encryption algorithm which would be denoted by 
> some number ( Like 1 is for MD5 ) and crypt(3) would be enhanced to 
> handle that. Since my proposal does not interpret the number and uses 
> AS IS to generate the hash, we should be fine.
>
> On 08/28/2017 05:04 PM, vishwa wrote:
>> On 08/14/2017 10:05 PM, Patrick Williams wrote:
>>> On Fri, Aug 11, 2017 at 09:48:48PM +0530, vishwa wrote:
>>>> This email is about openbmc/openbmc#1714 ( REST API to update root
>>>> password )
>>>>
>>>> Goal is to do Non-interactive password updates to enable a REST client
>>>> to update the root password.
>>>>
>>>> My proposal is to use `getspent(3)` and `putspent(3)` and here is 
>>>> the flow.
>>>>
>>>> REST client will provide a method that takes std::string as parameter.
>>>>
>>>> The Provider at the BMC will receive the password and does these:
>>>>
>>>>    - Executes `getspent(3)` for "root" and gets the entries.
>>> Make sure you're using getspent_r for this.
>> Sure
>>>
>>> Should be done based on any user, not just 'root'.  We might only
>>> support 'root' now but will want to easily add support for other users
>>> in the near future.
>>
>> Okay. I will have [User] and [Password] in the yaml.
>>>>    - Parses the `sp_pwdp` and extracts `encryption method` , `salt`.
>>> Is there a portable way to do this?  Is there any library that exists
>>> already?
>> I tried to look for that and did not find. I will continue looking.
>>> Tom and I spoke previously about a possible non-standard crypt 
>>> algorithm
>>> in order to satisfy some of the requirements of IPMI RMCP+'s
>>> authentication protocol without storing plaintext passwords. Please
>>> follow up with him and see if what you are proposing here will mesh 
>>> with
>>> what he was planning.
>>
>> I told Tom about this and he would get back to me.
>>
>> BTW, I put the proposal of using crypt() after looking at:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_shadow-2Dmaint_shadow_blob_master_src_passwd.c-23L245&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=GM5LgBdrkHptZeS659KO05vpYZn7jOXt0dSR6XkNziE&m=0NWe9soH7zsqWvgyvCxg--peP4EPF2q4uNIf6lSSfMc&s=RwItfMYVZCBZ5am5cCX1wrs0O6FF8rjD7x2GGOMrmH0&e= 
>>
>> and
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_shadow-2Dmaint_shadow_blob_6fbc11ce2178205968c37853db752729359c9893_lib_encrypt.c&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=GM5LgBdrkHptZeS659KO05vpYZn7jOXt0dSR6XkNziE&m=0NWe9soH7zsqWvgyvCxg--peP4EPF2q4uNIf6lSSfMc&s=eXkgvg7YljMlii9b_K46o3btJh4J_QEH0Z-V2gSsQyI&e= 
>>
>>
>>>>    - Makes a call to `crypt(3)` with the extracted `salt` and `user
>>>> input` and generates encrypted pass-code
>>> The salt can/should be random for each password, shouldn't it? It
>>> sounds like you are attempting to reuse the salt from the previous
>>> password and that is not required nor preferred to the best of my
>>> knowledge.
>>>
>> Okay. I can generate a random string from [a-zA-Z0-9./] as needed by 
>> crypt()
>>>>    - Populates the structure and calls `putspent(3)` to update the 
>>>> password
>>>>
>>>> Please let me know your opinion on this.
>>>>
>>>> Thank you,
>>>>
>>>> !! Vishwa !!
>>>>
>>
>

Re: Design proposal to Non-Interactive password update for REST client

[vishwa]

Tom and I talked and my current proposal would still be fine per the 
discussion as the idea is to have crypt() link to custom crypto lib.