Re: Feature Proposal: Transparent upgrade of crypt() algorithms

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote:
> Xin Li wrote:
>> Hi,
>> 
>> On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote:
>>> Allan Jude wrote:
>>>> On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote:
>>>>> Allan Jude wrote:
>>>>> 
>>>>> [...]
>>>>> 
>>>>>> Honestly, my use case is just silently upgrading the
>>>>>> strength of the hashing algorithm (when combined with my
>>>>>> other feature request). Updating my bcrypt hashes from
>>>>>> $2a$04$ to $2b$12$ or something. Same applies for the
>>>>>> default sha512, maybe I want to update to rounds=15000
>>>>> 
>>>>> Like this?
>>>>> 
>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=182518
>>>>> 
>>>>> Request for comments:
>>>>> 
>>>>> http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903
> 
> [...]
> 
>> Speaking for adding rounds, the only problem that needs to be
>> fixed is that the proposed patch makes it possible to create
>> conflicting configuration (passwd_format and passwd_modular can
>> use different hashing algorithms) and need to be fixed and
>> polished.  I like the idea of making it possible to use more
>> rounds though.
> 
> This was deliberate for backward compatibility.  passwd_format will
> be used by default if passwd_modular isn't defined.  If
> passwd_modular is defined as "disabled", then passwd_format will be
> used.

Well, my point is that the two shouldn't be allowed to exist together
if they can mean something conflicting.  Allowing passwd_format=sha512
AND passwd_modular=$2a$08$ in the same configuration creates confusion
and it's not good.

My suggestion is that we either have:

a) passwd_format and passwd_round (so that they don't conflict), or

b) extend passwd_format in a compatible manner to allow specifying a
round, or,

c) make passwd_format and passwd_modular conflict so we don't silently
accept it and instead bail out when doing pwd_mkdb.

> What do you think of the idea of putting this into libcrypt instead
> of pam_unix.c, and then patching pam_unix.c and pw_user.c to
> reference libcrypt?

Which part of the idea?  I think it's a bad idea to make libcrypt to
depend on libutil (for login_cap(3)) but we should probably provide
new wrappers in login_cap(3) to do the common things when requested
for various password manipulating tools to reduce duplicated code.

Cheers,
- -- 
Xin LI <delphij_at_delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBCgAGBQJTGmYMAAoJEJW2GBstM+nsDJ8QAJ+SM9WuRCXo1KYERj+/NJsC
VoP8psjZDZ7+hGOnG7iSwREYTLpxSEAw+sPnIhMgEy1Tg5jCcPvnIhCN/n+XPvaR
HG0o0TdTXL5ZVU4HyKuhNH6JGF9sWWua7Ki/jFguqE+1rdmivcbhrHMZNqOy8Djc
N/dnoCD/eN8K2/FiwP+KjTsYeSyisKFMyiGimQNcuPA7boF4ZBgJmmJqPASHzO9M
DVccoVPrDUip/6BdM+CNx/rNTry1sW3lMFSAuJkx+LENgulbhFz5R0aRGglzwGnJ
LocXVCZlTv0QB37qp9VIHCtTO5n8GxOx43dEtgjWF1cjDs+s+iKjEylX8NguUi0x
SjYu5WOw8xXNdE48QtqpT0N5aHSw9+CCwbrocGaOVYy11voGzo+r3C7jXprhQl8a
pgeiXH5pyBpo9Eh7+/aZdN3WcBjpaOVDnX8We7A9my1lVjxyuLXFyhC3q2OqUjvl
dX4ywKIjiFHSOz0ivzi+uQPx6PD05UuyrWUDING2PvMD/oMtg/hHbR5IxOHdmgPq
j7brHNOk7gxu1f/NFft/yfJAKem6JXjlX68z6/9jMrwxZ8jwTWWAtHrVBjo9/u2i
7ShSZlsEi62GewoIKRRVKvKmdX7Xl+Of/p/DZMTNGCJ9K5NnhEnLKWSp+I5VF0LN
fVQkTqpRaXglMVa/iRkG
=xSx1
-----END PGP SIGNATURE-----