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 !!
>>>>
>>
>