[Freeipa-users] change min and max lifetime of random password

[Alexander Bokovoy]

On Mon, 24 Mar 2014, Stijn De Weirdt wrote:
>hi alexander,
>
>>>No, because then you have to either ship keytabs around during
>>>provisioning or hardcode that user's password in the kickstart and
>>>they are already nervous about doing that for the OTP.
>>This topic raises regularly on IRC. My suggestion was to create these
>>one time passwords based on some function of time and host parameters
>>you can control centrally, for example, IP address.
>>For example, using Python expression:
>>
>>>>>from time import gmtime
>>>>>addr = "192.168.0.1"
>>>>>time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
>>>>>pw = lambda t, a: ''.join(a.split('.') + map(lambda x:
>>>>>'{:02d}'.format(x), t))
>>>>>pw(time(gmtime()), addr)
>>'19216801201403242030'
>>
>>i.e. a password is an IP address octets concatenated with date and time
>>rounded down to 15 minutes.
>>
>>Then ship the function to calculate the OTP as part of kickstart file.
>>Only a password generated when running install within 15 minutes window of
>>setting OTP on the server will work if IP address is the same as defined
>>on the server.
>>
>>No real password is in the kickstart file, OTP will turn itself off
>>automatically on enrollment and time has to be within the window of
>>opportunity.
>>
>but the password itself is still valid if the install failed and 
>someone else tries to use it.
Right. Nobody actually prevents you from running a cron job on the
server side to lock down these passwords if they were not used up in
a fixed amount of time.

>it's good that you can't guess the password that easily (it's 
>slightly better than a fixed string in the kickstart script), might 
>be a good candidate if it was coupled with a short enough lifetime. 
>(coupled with minimum lifetime as an offset, you might even schedule 
>installations in the future).
>i don't understand what the ip adds to the password though. the 
>ipa-client-install should fail if the ip/hostname doesn't match the 
>data in freeipa for that host, right? (the only secret is in the 
>timewindow that the admin scheduled, assume that the 
>ipa-client-install enforces the ip/hostname)
In a typical environment you have central control over those types of
data associated with the spawned machines, like MAC addresses or IP
addresses.

If the password is including bits that are forced to the host by a
central authority, it makes harder to get rogue clients to re-use the
same template for other combinations of MAC/IP address. They would need
to know exact IP or MAC address of the machine they want to impersonate.
You can take other unique parameters into account.

You need to think of what is truly unique to your clients but there
still will be question of trust to the client who attempts to
authenticate. This trust should be verified on multiple levels, a
password to enroll the client is just one of them.
-- 
/ Alexander Bokovoy