Date: Mon, 10 Mar 2014 18:12:00 -0400 From: "A.J. Kehoe IV (Nanoman)" <nanoman@nanoman.ca> To: "Derek (freebsd lists)" <482254ac@razorfever.net>, freebsd-current@freebsd.org Cc: secteam@freebsd.org Subject: Tuning libcrypt with Modular Crypt Format Message-ID: <20140310221200.GA69840@nanocomputer.nanoman.ca> In-Reply-To: <531BE33B.4010504@razorfever.net> References: <2167732.JmQmEPMV2N@desktop.reztek> <201403070913.30359.jhb@freebsd.org> <5319DE84.3040602@allanjude.com> <20140307161313.GA49137@nanocomputer.nanoman.ca> <531A2CC1.8080802@allanjude.com> <20140307215223.GB49137@nanocomputer.nanoman.ca> <531A42F3.5020207@delphij.net> <20140307225050.GC50880@nanocomputer.nanoman.ca> <531A660D.3040101@delphij.net> <531BE33B.4010504@razorfever.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Derek (freebsd lists) wrote: [...] >On 03/07/2014 07:36 PM, Xin Li wrote: >> On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote: >>> Xin Li 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=3D15000 >>>>>>> >>>>>>> Like this? >>>>>>> >>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D182518 >>>>>>> >>>>>>> Request for comments: >>>>>>> >>>>>>> http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903 [...] >My reasons for this were first to see if there was any interest >from a committer to take this further. Much more likely to have >a 15 or so line patch looked at, than one that touches stuff all >over the place - I think. > >We are now at least having a conversation about it. > >It seemed to be a lot of work to specify rounds via >login_setcryptfmt, with a bunch of changes also required in >libcrypt. > >I don't have the resources to test for regressions in libcrypt, >beyond the scope of whether login.conf works as expected >(specifically, the ports tree, yp, ldap, or any other areas that >I don't know about). > >If other developers were willing to work together on the api/abi >changes, I would feel a lot better about spending my time there >and doing it right. Without support from other, more >knowledgeable people (as far as what will break if we do XYZ), >who will eventually merge productive changes, I would be wasting >my time. > >I don't want to be the libcrypt api changing pixie, scattering >patches into /dev/null. :) So far, I've seen five people say that they want this functionality: 2005-01-08: Steven Alexander Jr. 2012-12-05: Derek 2013-07-07: me 2013-10-29: jmg@ 2014-02-27: Allan Jude There will surely be more, and I think it's fair to say that none of us are= sufficiently familiar with the many things that depend on libcrypt and lib= util. To avoid breaking something, we need feedback from the people who wo= uld ultimately be committing these changes. Is this the correct mailing li= st to discuss this proposed feature? >> My suggestion is that we either have: >> >> a) passwd_format and passwd_round (so that they don't conflict), or >> > >I recommend against this. By example, based on current scrypt >modular crypt RFCs, there are multiple tunable parameters. It's >conceivable that other future algorithms will have different >functional and named parameters. > >Additionally, I think having all the parsing code for this >scattered about actually makes things less clear. For example, >$2a$08$ means a lot more to people (across different *nix >backgrounds) than blf, is concise, and is/already should be well >documented in crypt(3). Likewise with sha512. Looking at >login.conf, you can't tell exactly what it means. > >Modular crypt is something that developers are working to stay >compatible with (e.g. $5$, $6$, $2y$, etc), is understood outside >of the context of FreeBSD system administration, and would be >understood by people who are knowledgeable enough to seek to >change this aspect of their system. This is exactly what I meant. I completely agree. >> 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. >> > >As jmg suggested, by supplying the modular format for >passwd_format, we eliminate this conflict, and make it obvious. >I definitely support this notion. Option C gets my vote too. Modular crypt is pretty standard across all imp= lementations, whereas options A and B would require additional proprietary = parsing, which I feel would be an unnecessarily more complex change. >That means touching login_setcryptfmt and friends, I think. > >>> 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. >> > >Specifically: > >The makesalt aspect can/should be put into libcrypt, refined >appropriately, and exposed publicly. It is a terrible little >piece of code as it is now, twice (or more!), and it could be >cleaned up considerably. This could be a nice little api. > >Secondly, since the digests are used externally, I think it would >be good to push the custom base64 code out to a library >somewhere, so there is the standard way to do it, documented. >Maybe libcrypt is the right place for this function too, since >that is the context in which I have seen it. I forget for sure >now, but I think each algorithm is also responsible for base64 >encoding their output. Not that I'm saying we should just rip it >out, but it might be worthwhile to look case by case, if it's >appropriate. This is how I envision it too. The idea is not to have libcrypt depend on = libutil, but rather the opposite. Currently, there are at least two places= where this code is being used, and in my opinion, libcrypt would be a bett= er place for it. >As far as autotuning the work-factor, I think that just being >able to set it at all is a huge improvement, and autotuning is >Just Details. We can see that this will be fraught with problems >establishing consensus, and could stall making progress with the >other good work. Even if every couple of years, the default in >login.conf gets bumped to whatever. When people run mergemaster, >it'll show, and the admin can decide then. As it is right now, >rounds are fixed, that's not appropriate for any use-case, small >or large. > > >Finally, I agree the ability to auto-update existing digests is >desirable. That and the other policy stuff can happen totally >separate from the discussion around exposing the tunables. I agree that these would be nice to have, and I agree that these should be = discussed after we get the basic functionality. Like Derek said, we curren= tly lack the ability to set this at all, or at least not without patching o= ur systems first. Let's start with manual tuning. --=20 A.J. Kehoe IV (Nanoman) | /"\ ASCII Ribbon Campaign Nanoman's Company | \ / - No HTML/RTF in E-mail E-mail: nanoman@nanoman.ca | X - No proprietary attachments WWW: http://www.nanoman.ca/ | / \ - Respect for open standards --HlL+5n6rz5pIUxbD Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIPUAYJKoZIhvcNAQcCoIIPQTCCDz0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DLwwggV3MIIDX6ADAgECAgMOkYIwDQYJKoZIhvcNAQENBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MTQwMjI0MTcwOTA5WhcNMTQwODIzMTcwOTA5WjA9MRgwFgYDVQQDEw9DQWNlcnQgV29UIFVz ZXIxITAfBgkqhkiG9w0BCQEWEm5hbm9tYW5AbmFub21hbi5jYTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAK9WRGqRDUDjWwNIfZTBp4FL5bI0kY3ZqvM6tEO+Sqp5YxATre8F a+BYbeNp/8MKfuPrRgE2jRzlePAx7kpvZUhRTGAZpncmHC7Z3FDl8Ugid4193ReCfPypb9Gs 3ZgPfzJyNuDeCM3amz/cDXC/makJLpmLzu95D91hD+V30iActE5j1tNewMq9qJRoEdr5Tqus bUjjDm8kiK5sz9JzQjFoufuaWIR57w2Sm1gDVZ0MH46fxZ/SwLDDzt4VC2u+1oS4KSmVUm6X Wv1/Fmdf2sOOu9Ro2xVjJHW+j16lsFPPj+lkDv5tb0G7I2vBoKEQg/s+h8J4F+l/xPL3O5xB c68CAwEAAaOCAUIwggE+MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5 b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5D QWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUH AwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQw IgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwHQYDVR0RBBYwFIESbmFub21hbkBu YW5vbWFuLmNhMA0GCSqGSIb3DQEBDQUAA4ICAQCEaPJcTaHwgbPsRG2zNaFL1TioYnJPLzv4 HIIf7D6uvTHn8lNs5wgXD5iXKCxNflCmKuhTg0Oc7tRANpMI7H8UjAUsfqLMnslDKGiQw9yr Y0lOjYviAwLeTiYElR9/lWelR82WwDHAoYkrTJePhj2v138pk4fBxBOjVptqN58TjvKqqiQF lGBKpnLLwsscN3f7ITJHHs728voulBtis0aL7LuYMIrsIRg3GHPOoNlxU4ud/knjoFspOIAS a0Yb8h10eZrvSSa019abqSTK8lOBkV0bH7FT++3J5obkREtRqrRJPU92U+OYWOPSq1nPFEou TfBzJpY+AS7fi0YUVSMZ0Nr85zywlZGwETGCya1lNEKAiF6GSxpRuUD7yneUaoYQnYisi7zA BSp5ur2aiw3PFY/P2D3xFjP3zUSUszFefPlO4lMD3TYz8KCirBKDvR3hRHPV52Wam+6nwuWW HNKQ464j5jeqRTNX3FJMeytJmX59EoTltIusIEpqxC7S40JOlaDBbXsVuufvBm0Bk3RNktC7 ylA3CB2eHwAZLnxN8hIncZAq4PK2Zmth1YriEQlkCUAsVeFkLEWNAqRAsREXcfqQj4H75Pb8 ku0QsesX7Ci3R4tF4dECz0TguxI7SuSq/TpoToz8Xg+OH1O9JLODcFjx+lf5Ul0ScggcJdpI 1jCCBz0wggUloAMCAQICAQAwDQYJKoZIhvcNAQEEBQAweTEQMA4GA1UEChMHUm9vdCBDQTEe MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcNMDMw MzMwMTIyOTQ5WhcNMzMwMzI5MTIyOTQ5WjB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzCCAiIwDQYJKoZIhvcN AQEBBQADggIPADCCAgoCggIBAM4iwOJGfew2KAdQlvKgM0CMS/E7Zj8x5WsCNtvWfPbxiI9O dzYFQZX5CfASz0aGc2C3bn7owFhkrs2wrUUXDGP6Zwro1tK/PueYxPBM+uADuzVdbCHeniDZ us1mMjdy+vcI9cfNWMmO5w5e6j7+HKEUChVshoRbZGYqeqlLU3n1iKJ77i8KYSuNsn5NVqUT 7Orakp6sREEeWGBlBWb4wES9y5T3Qn4L92VomFEF8PMFkQQdGxeC7MhXu8NreojxsHLMJVsg kewWAhKPMukXGEjQxwUuAjBCuCWcBWs/qjqn61NI9+jStgeY3BvGNH9/yRyCegVYKwhb8zii qxddZsmY154Qi6LS3XSa93EMcmDfzW+YM52WNHY+JHqSsA6VHm/moEU4R6rXQe1KtxL21xuD ig8u2Am2WdeqBP/Sk31oLt2LS6tYui+N6pWnoMNUiaX724tRIp2yw74RviyRhouWeK0g04ov Gj/G0FFlhyGxGQFlf0Uch/V80EFMTymYIf0zH3UMBFH6GXfb1BQc7oHDHfWYt2kGkSLdAFDM gTGsEgd7ONpoW+Yr1H7JX63o63JM8wHlSyC/mqZXypEAAYuhdSE3tWMNZz5GT3AgZ87F1lnb AuDw0svNumK3kEHo3SDkKbxkKULIItx4mv9D7JgbCVFLWlrCcfHEy3Op5aELAgMBAAGjggHO MIIByjAdBgNVHQ4EFgQUFrUyG9TH8+DmjvO90rA67rI5GNEwgaMGA1UdIwSBmzCBmIAUFrUy G9TH8+DmjvO90rA67rI5GNGhfaR7MHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0 dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnggEAMA8GA1UdEwEB/wQFMAMB Af8wMgYDVR0fBCswKTAnoCWgI4YhaHR0cHM6Ly93d3cuY2FjZXJ0Lm9yZy9yZXZva2UuY3Js MDAGCWCGSAGG+EIBBAQjFiFodHRwczovL3d3dy5jYWNlcnQub3JnL3Jldm9rZS5jcmwwNAYJ YIZIAYb4QgEIBCcWJWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwVgYJ YIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFk IG92ZXIgdG8gaHR0cDovL3d3dy5jYWNlcnQub3JnMA0GCSqGSIb3DQEBBAUAA4ICAQAox+6c ggK6XIASyjUKHYFviWqZzPJoD3+n4Y1YlT698gbDkFqstWD2mUMBo4hwnJ1inaSHr2dYDTA2 O+atSNPLdAKGcT7iKwNo8TRiQEY7U+oo9Kz7ZpVTik1d/TvZYNfKeWk7sWWSpsaBglyczetN AYql3xFVqhXKHzfAgphwYdtqfJajji5UPk8hqZDv3IK/3OhFrU2Qcwg8lGWwBJl2f+K8wmoV qpcENyTYHpRObQ5RvtbEj8qWbfdD3+gwZSc7e7tDQ2PEQ/ey7GjM4RmOIvuY4XtaPgE3O4sI sKLzlU4ay5vNmrHbsnDwLUrb2LDjb0VIMxL//jwyKlT3xPeK8Igjwkf+ZHpxwNEepmOwB36k L9MBj9yfK7bGCKkPk0gl/BL9n0Lc88Q+9lew191p0QZ3NApL0sqg/xzGjMkWvsTMMjdoc18I +1H3SVM2BQqVAkzyeRoQ9tg6dZzzHfGiDXBnhhuzFvUv5aTreYb5PQvCcwulmaxv/Ge45S8L phgkjXvRSDUpGECsk2DhloZQtHpZ2I8hC5/PgpHGO79r3AeRuZdWI6q2bJTGSAY85M5OquT2 LwncU28u/HTrOmOZwqasibynskSgDYoQ42zyJMv6m59wRy7eFIvUsiAJlqJk8SQc3KE1nBWy 1LxVLn0G9ZwOVfRa1pPadq0lc0zFQzGCAlwwggJYAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3Qg Q0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMO kYIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xNDAzMTAyMjEyMDBaMCMGCSqGSIb3DQEJBDEWBBSVl1Bmi7NT/Hmd4d1/jLXPcF/H 5DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBlYn/2 9oizPwyqYKg3gVZNgG7VUGnB552GN6Whya8ezruo4DfDjfSa1bWgLIOgCzACoM2jjwj2DWUB v7RXhVI0DttqBSmok72SVSW/Yk47bO3MD9lBbwWoAUtggAPQs8DZmnpI3KmhQvw3uAoXi1hx cSZBuhRYYIY0Z3Ns7m8XJWMqo8XwPmWF8H/L1bcIYibS6agIRY6g0HBLtMo1cVF15JyuoQcm RXgupHJgyS/l5AL1hQXMxrHkNRQM/892YLMuuG70jGiNwHT1TOYfadslIS/6FO563IeKRj7g 8zhtOkXozfEpQ9zRtQYWHOe13kl4HB61vjLCXeJFSlOHnVxf --HlL+5n6rz5pIUxbD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140310221200.GA69840>