Re: Feature Proposal: Transparent upgrade of crypt() algorithms
Hi all, Thanks for your attention to the matter/threads. I have thought a bit about this, and I hope I can add some value to the current conversation, below: 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 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. Agreed. My original intention was to create a patch that didn't touch a lot of code. 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. :) 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. 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. 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 standa
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
Warner Losh wrote this message on Fri, Mar 07, 2014 at 22:30 -0700:
> On Mar 7, 2014, at 10:22 PM, Allan Jude wrote:
> >> Performance for default, sha512 w/ 5k rounds:
> >> AMD A10-5700 3.4GHz3.8ms
> >> AMD Opteron 4228 HE 2.8Ghz 5.4ms
> >> Intel(R) Xeon(R) X5650 2.67GHz 4.0ms
> >>
> >> these times are aprox as the timing varies quite a bit, ~+/-10%?
>
> And what would that be on a RPi or other embedded device?
Ok, here you go, IXP425 533MHz is ~1465ms.. This is a fast AVILA
board, I have a slower 266MHz AVILA board next to me... Yes, that is
1.5 seconds at the default number of rounds for sha512 which is now the
default for passwords...
For comparision, md5 is 44.5ms and sha256 is 405ms on the AVILA...
So, by making sha512, we just killed the performance of embedded
systems... This is also with the default of 5000 rounds...
So, the autoscaling could either help on embedded because we let the
number of rounds drop below the default of 5k, or it stays the same, so,
no hit on embedded...
> And do the extra route have a peer-reviewed paper showing the increased
> strength?
Well, if it doesn't increase the strength, then we might as well drop
the rounds down to 1000 (the min per spec)... since clearly if
increasing rounds pass 5k doesn't increase strength, then the same can
be said for 1k...
As for papers, I don't think anyone wrote a peer-reviewed paper saying
that crypt-sha{256,512} is secure...
Plus, they clearly thought that changing the rounds would be helpful,
so, they added it as an option, well, actually, Drepper just copied
Sun for making rounds an option...
Per Drepper:
The more rounds are performed the higher the CPU
requirements are. This is a safety mechanism which might help
countering brute-force attacks in the face of increasing computing
power.
Notice the might...
http://www.akkadia.org/drepper/SHA-crypt.txt
> > One possible solution would be just setting the default login.conf
> > number of rounds, based on a test in the installer. Although this won't
> > help for systems that are deployed by imaging, or VM images (like EC2
> > images) etc.
Does CPU time measuring work properly on VM's? i.e. if I do a cpu
intesive task and measure it with getrusage, do I get how much I really
ran for? By my understanding, you can't, since often the VM isn't aware
of the parent, so doesn't know when to stop the clock when it isn't
running...
Unless I'm missing something, you really can't do any cpu or profiling
on a VM and trust the results...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On Mar 7, 2014, at 10:22 PM, Allan Jude wrote: >> Performance for default, sha512 w/ 5k rounds: >> AMD A10-5700 3.4GHz 3.8ms >> AMD Opteron 4228 HE 2.8Ghz 5.4ms >> Intel(R) Xeon(R) X5650 2.67GHz 4.0ms >> >> these times are aprox as the timing varies quite a bit, ~+/-10%… And what would that be on a RPi or other embedded device? And do the extra route have a peer-reviewed paper showing the increased strength? > One possible solution would be just setting the default login.conf > number of rounds, based on a test in the installer. Although this won't > help for systems that are deployed by imaging, or VM images (like EC2 > images) etc. I’m not sure that’s a good idea. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On 2014-03-07 21:15, John-Mark Gurney wrote: > Xin Li wrote this message on Fri, Mar 07, 2014 at 16:43 -0800: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> On 03/07/14 15:07, John-Mark Gurney wrote: >>> Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500: On 2014-03-07 17:06, 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 >>> >>> >> This looks like what we wanted. In the feedback you talked about >>> some changes to your patch required to make it work, is >>> there any progress on those? > >> Derek's patches worked perfectly for our needs, but we're the >> sort of people who use vipw and our own utilities for user >> management. It wasn't until later that we discovered at least >> one other file would need patching to satisfy everyone. We >> didn't want to employ the same copy-pasta method, so we asked >> for feedback about our proposed alternative. > >> secteam@, do you have any comments? Before we put any more >> work into this, we want to be sure that our proposal is an >> acceptable one. > > > Did you mean adding rounds capability, or transparent upgrade > of crypt() algorithms, or both? There are 2 separate but related threads 1) specify rounds for crypt() 2) transparent upgrade of crypt() algo (or more likely just number of rounds) >>> >>> Can't the two be merged... where 2 becomes a flag in login.conf >>> instead of an algo fetch, and then if it's true, it does the algo >>> fetch from 1? >>> >>> I really would like us to get 1 in, and then on boot dynamicly >>> adjust the number of rounds depending upon CPU usage... obviously, >>> a flag will adjust how long/many rounds the admin wants, but it >>> would allow an automatic increase in security as faster CPUs are >>> used... >> >> Or by the installer/a tool that gets run when doing >> mergemaster/etcupdate/freebsd-update: it's rare that CPU gets faster >> after installation, and we can probably just write in the >> configuration anyway? > > It's just easier to throw something into /etc/rc.d w/ an enable/disable > switch than it is to update one/all of those tools to do it... If you > update only one, then the users of the other tools won't get the benefit.. > Or someone forgets to update the other tool... or we could detect that > the CPU is the same, and keep the previous results... > >> Personally I'm not a big fan of making it something that changes over >> time: the attacker may do offline attacker than doing it on the victim >> system that revealed the salted hashes, so how fast the system CPU >> runs doesn't really matter, except for how long a system administrator >> is willing to have the user to wait. > > This is my point, there is currently the default number of rounds which > provides basic security, but if the sysadmin wants to provide > additional security, they can do so, either by fixing the number of > rounds to something larger, or by providing a time they are willing > to spend to do the work... > > I'm tired of default security parameters not being ideal, or secure > enough... Most sysadmins won't go and increase the number of rounds > since they don't know enough to (or couldn't before the other patch > was even presented), but they will continue to install FreeBSD on ever > faster machines, yet our only response so far is to switch algorithms, > instead of including more rounds, etc... This feature would allow us > to provide better security out of the box, and continue to scale our > security as time goes on... > > Performance for default, sha512 w/ 5k rounds: > AMD A10-5700 3.4GHz 3.8ms > AMD Opteron 4228 HE 2.8Ghz5.4ms > Intel(R) Xeon(R) X5650 2.67GHz4.0ms > > these times are aprox as the timing varies quite a bit, ~+/-10%... > > code available at: https://www.funkthat.com/~jmg/testcrypt.c > > Most people won't notice a 50ms delay on login, yet it'll give us a > 10x security benefit... Just for fun, compare how long it takes to > run sleep .005 and sleep .05 from the command line... Heck I think > most people would be fine w/ 100ms delay.. try it.. :) > > and if they don't mind something similar to how geli does
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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. 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? -- A.J. Kehoe IV (Nanoman) | /"\ ASCII Ribbon Campaign Nanoman's Company | \ / - No HTML/RTF in E-mail E-mail: nano...@nanoman.ca | X- No proprietary attachments WWW: http://www.nanoman.ca/ | / \ - Respect for open standards smime.p7s Description: S/MIME cryptographic signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
Xin Li wrote this message on Fri, Mar 07, 2014 at 16:36 -0800: > -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, Couldn't we merge passwd_format and passwd_modular into one, being either the name, or the begining salt string? since the salt string always begins w/ $, they wouldn't conflict, and could be properly resolved... > 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. So, the current code in pam_unix is: login_setcryptfmt which calls crypt_set_format as necessary makesalt crypt So, we could expand crypt_set_format to understand the two, and keep a copy of the rounds data, or we could expose makesalt into maybe crypt_makesalt (this would be nice) w/ an optional arg that provides either the name or the beging salt string w/ rounds, i.e. what passwd_format would contain... and update pam_unix and friends to use this... This last method would make login_setcryptfmt unnecessary, so I'm not sure how good/bad that is.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
Xin Li wrote this message on Fri, Mar 07, 2014 at 16:43 -0800: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 03/07/14 15:07, John-Mark Gurney wrote: > > Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500: > >> On 2014-03-07 17:06, 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 > >> > > > > > >> > This looks like what we wanted. In the feedback you talked about > > some changes to your patch required to make it work, is > > there any progress on those? > >>> > Derek's patches worked perfectly for our needs, but we're the > sort of people who use vipw and our own utilities for user > management. It wasn't until later that we discovered at least > one other file would need patching to satisfy everyone. We > didn't want to employ the same copy-pasta method, so we asked > for feedback about our proposed alternative. > >>> > secteam@, do you have any comments? Before we put any more > work into this, we want to be sure that our proposal is an > acceptable one. > >>> > >>> > >>> Did you mean adding rounds capability, or transparent upgrade > >>> of crypt() algorithms, or both? > >> > >> There are 2 separate but related threads > >> > >> 1) specify rounds for crypt() > >> > >> 2) transparent upgrade of crypt() algo (or more likely just > >> number of rounds) > > > > Can't the two be merged... where 2 becomes a flag in login.conf > > instead of an algo fetch, and then if it's true, it does the algo > > fetch from 1? > > > > I really would like us to get 1 in, and then on boot dynamicly > > adjust the number of rounds depending upon CPU usage... obviously, > > a flag will adjust how long/many rounds the admin wants, but it > > would allow an automatic increase in security as faster CPUs are > > used... > > Or by the installer/a tool that gets run when doing > mergemaster/etcupdate/freebsd-update: it's rare that CPU gets faster > after installation, and we can probably just write in the > configuration anyway? It's just easier to throw something into /etc/rc.d w/ an enable/disable switch than it is to update one/all of those tools to do it... If you update only one, then the users of the other tools won't get the benefit.. Or someone forgets to update the other tool... or we could detect that the CPU is the same, and keep the previous results... > Personally I'm not a big fan of making it something that changes over > time: the attacker may do offline attacker than doing it on the victim > system that revealed the salted hashes, so how fast the system CPU > runs doesn't really matter, except for how long a system administrator > is willing to have the user to wait. This is my point, there is currently the default number of rounds which provides basic security, but if the sysadmin wants to provide additional security, they can do so, either by fixing the number of rounds to something larger, or by providing a time they are willing to spend to do the work... I'm tired of default security parameters not being ideal, or secure enough... Most sysadmins won't go and increase the number of rounds since they don't know enough to (or couldn't before the other patch was even presented), but they will continue to install FreeBSD on ever faster machines, yet our only response so far is to switch algorithms, instead of including more rounds, etc... This feature would allow us to provide better security out of the box, and continue to scale our security as time goes on... Performance for default, sha512 w/ 5k rounds: AMD A10-5700 3.4GHz 3.8ms AMD Opteron 4228 HE 2.8Ghz 5.4ms Intel(R) Xeon(R) X5650 2.67GHz 4.0ms these times are aprox as the timing varies quite a bit, ~+/-10%... code available at: https://www.funkthat.com/~jmg/testcrypt.c Most people won't notice a 50ms delay on login, yet it'll give us a 10x security benefit... Just for fun, compare how long it takes to run sleep .005 and sleep .05 from the command line... Heck I think most people would be fine w/ 100ms delay.. try it.. :) and if they don't mind something similar to how geli does it, it could be as long as 2 seconds, giving a 500x benefit! :) and with the auto recrypt path, we could automatically "
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/07/14 15:07, John-Mark Gurney wrote: > Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500: >> On 2014-03-07 17:06, 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 >> > > >> This looks like what we wanted. In the feedback you talked about > some changes to your patch required to make it work, is > there any progress on those? >>> Derek's patches worked perfectly for our needs, but we're the sort of people who use vipw and our own utilities for user management. It wasn't until later that we discovered at least one other file would need patching to satisfy everyone. We didn't want to employ the same copy-pasta method, so we asked for feedback about our proposed alternative. >>> secteam@, do you have any comments? Before we put any more work into this, we want to be sure that our proposal is an acceptable one. >>> >>> >>> Did you mean adding rounds capability, or transparent upgrade >>> of crypt() algorithms, or both? >> >> There are 2 separate but related threads >> >> 1) specify rounds for crypt() >> >> 2) transparent upgrade of crypt() algo (or more likely just >> number of rounds) > > Can't the two be merged... where 2 becomes a flag in login.conf > instead of an algo fetch, and then if it's true, it does the algo > fetch from 1? > > I really would like us to get 1 in, and then on boot dynamicly > adjust the number of rounds depending upon CPU usage... obviously, > a flag will adjust how long/many rounds the admin wants, but it > would allow an automatic increase in security as faster CPUs are > used... Or by the installer/a tool that gets run when doing mergemaster/etcupdate/freebsd-update: it's rare that CPU gets faster after installation, and we can probably just write in the configuration anyway? Personally I'm not a big fan of making it something that changes over time: the attacker may do offline attacker than doing it on the victim system that revealed the salted hashes, so how fast the system CPU runs doesn't really matter, except for how long a system administrator is willing to have the user to wait. > Anyways, how many people are still using passwords instead of ssh > keys? Setting the time to be something like 100ms may seem long, > but considering few people should be using passwords these days, > it's less of an issue... I'm currently using SSH key plus Google Authenticator for my systems but all remote login via password is disabled. I am aware of, however, many people who refuse to use SSH key authentication because they don't want to carry their keys, which is a bad idea but they do it anyways. > Xin Li, if you need help reviewing, testing, let me know... Will do and thanks for the offer! Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTGme0AAoJEJW2GBstM+nsXnkQAIYplCr5wMtENLYMQCDSrOFJ 7oxKbW2Iy1qPbbrjAb6mG0TY4ugJu2T6Sg6Wp1B+um2sWqWkNMr+8auHokwuB8+1 8NpnbcZarFvmA5tgVEsh+JcAJF1qZRFQDku+DbL9f/ZXFn/4CtmLkw5NS/kIKf/0 TIeXykNie5nFCS8ifT5Ai7vEHImOTwS4OEVzXoTQSdFGuLnHrToCnV7LpOK2ceIo ssZ/0Go49tSzW8y3u2a0TZYTqMnh+0EzQFusWkulyCIam0NYjYON/3UY0/TpRgZd ik2QLqKXaMZBPmi4EsmgpQr97MS0PRag4lahZZad2CckZmhiwWrHLyECf0Xk5i1W +ACqSfJAzq+NeyDBW05y31qALeyUhm7+ALolSMDFkQMj5B7ra8qnQsbXVyG+DLmg itpCWfXUpKPxclkvirnDQx89BE1MOYGYBbw69IR5NWcvF3f4EF177xplwAMjHhn5 EXUVIeTwjHYoYgMiZKX8aFgyNR2EX/g6JvZS8236HUbskLQl5AAKM0RA4aQkAFGW 206DYokJW3TnXNArm8kKJCZrYAJb17XyzN6HcY89N+GA0oEkehy2qyQiBVqtpjgh 6WsslScxAnQM3LG84un98cdipOWwQerTwfeji1yqfmik5oNuCm4D/Jlt6rvJBFLb S5fUd1BQv+0woAKndGhb =rCdB -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 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- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500: > On 2014-03-07 17:06, 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 > > >>> > >>> This looks like what we wanted. In the feedback you talked about > >>> some changes to your patch required to make it work, is there any > >>> progress on those? > > > >> Derek's patches worked perfectly for our needs, but we're the sort > >> of people who use vipw and our own utilities for user management. > >> It wasn't until later that we discovered at least one other file > >> would need patching to satisfy everyone. We didn't want to employ > >> the same copy-pasta method, so we asked for feedback about our > >> proposed alternative. > > > >> secteam@, do you have any comments? Before we put any more work > >> into this, we want to be sure that our proposal is an acceptable > >> one. > > > > > > Did you mean adding rounds capability, or transparent upgrade of > > crypt() algorithms, or both? > > There are 2 separate but related threads > > 1) specify rounds for crypt() > > 2) transparent upgrade of crypt() algo (or more likely just number of > rounds) Can't the two be merged... where 2 becomes a flag in login.conf instead of an algo fetch, and then if it's true, it does the algo fetch from 1? I really would like us to get 1 in, and then on boot dynamicly adjust the number of rounds depending upon CPU usage... obviously, a flag will adjust how long/many rounds the admin wants, but it would allow an automatic increase in security as faster CPUs are used... Anyways, how many people are still using passwords instead of ssh keys? Setting the time to be something like 100ms may seem long, but considering few people should be using passwords these days, it's less of an issue... Xin Li, if you need help reviewing, testing, let me know... > > I need some time to digest the whole transparent upgrade idea but in > > general I think it's good. > > > > 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. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On 2014-03-07 17:06, 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 >>> >>> This looks like what we wanted. In the feedback you talked about >>> some changes to your patch required to make it work, is there any >>> progress on those? > >> Derek's patches worked perfectly for our needs, but we're the sort >> of people who use vipw and our own utilities for user management. >> It wasn't until later that we discovered at least one other file >> would need patching to satisfy everyone. We didn't want to employ >> the same copy-pasta method, so we asked for feedback about our >> proposed alternative. > >> secteam@, do you have any comments? Before we put any more work >> into this, we want to be sure that our proposal is an acceptable >> one. > > > Did you mean adding rounds capability, or transparent upgrade of > crypt() algorithms, or both? There are 2 separate but related threads 1) specify rounds for crypt() 2) transparent upgrade of crypt() algo (or more likely just number of rounds) > > I need some time to digest the whole transparent upgrade idea but in > general I think it's good. > > 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. > > Cheers, > -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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 >>> >> >> This looks like what we wanted. In the feedback you talked about >> some changes to your patch required to make it work, is there any >> progress on those? > > Derek's patches worked perfectly for our needs, but we're the sort > of people who use vipw and our own utilities for user management. > It wasn't until later that we discovered at least one other file > would need patching to satisfy everyone. We didn't want to employ > the same copy-pasta method, so we asked for feedback about our > proposed alternative. > > secteam@, do you have any comments? Before we put any more work > into this, we want to be sure that our proposal is an acceptable > one. > Did you mean adding rounds capability, or transparent upgrade of crypt() algorithms, or both? I need some time to digest the whole transparent upgrade idea but in general I think it's good. 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. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTGkLzAAoJEJW2GBstM+nsaVoP/017iARGzd++lCsfqyFDozGk nXJjatlrIcRjrbCmVRT0lsHiK/hoYJ4zZPeOu8EXU1Qs0/wggGHYePX7+zEVob2S YCxhqUOdG/jqrHnH8bljzWE/OtI7Y4PvFOLpsWkOE/uulssQfGDMSy8WJzFriqzv GXjAEyFrGXCT29gW6ozTRfDfPSOfd4MhwewbMYAUykSqucMfkG4FaDAgLxv/XdRi YmLQZuxxTzEqMYanZGq/0e5CvOwOuncd0aVxncJC8ZRcsHs5cqbzcyDkkRwvw/YU g1OsLXiO08zej0rOz1E4pud8O6q3unG5dNcz9Y96oNo0fJONMrk9IetCUCHBsR8N eyWJQyHL7wwwNlC5k8U9cOnsL3zxBv54N6bfWuWNNDpJmNrvgMr9LdPso+AX0gLD y4RhVJeLCQbLrkQawoM1+Ki5N0mQibk9BBGXH/ZPScP1pNqVt9tqXp94N5ZPLV54 Uu4cn/2uKjtTjl76YFlCTvfwwiuWgds1k6CnKZIW8luOp4cG5XOoOSztONqWr6S/ yd7SLDV4f8PC7Fi1iSkSuVW5MYz1I7RRVR1Z27oV3e3UwXwIgqRjHJawNZqIgVe1 4lk84+fm75ULLfiA6bgkMCjylyWHCzrdOQt/Zx+0vyZOer5x2p4gZmnYAyV2EQIP TM611j1UES6OUGFkfbWa =4Qur -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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 This looks like what we wanted. In the feedback you talked about some changes to your patch required to make it work, is there any progress on those? Derek's patches worked perfectly for our needs, but we're the sort of people who use vipw and our own utilities for user management. It wasn't until later that we discovered at least one other file would need patching to satisfy everyone. We didn't want to employ the same copy-pasta method, so we asked for feedback about our proposed alternative. secteam@, do you have any comments? Before we put any more work into this, we want to be sure that our proposal is an acceptable one. -- A.J. Kehoe IV (Nanoman) | /"\ ASCII Ribbon Campaign Nanoman's Company | \ / - No HTML/RTF in E-mail E-mail: nano...@nanoman.ca | X- No proprietary attachments WWW: http://www.nanoman.ca/ | / \ - Respect for open standards smime.p7s Description: S/MIME cryptographic signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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 > This looks like what we wanted. In the feedback you talked about some changes to your patch required to make it work, is there any progress on those? -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On Friday, March 07, 2014 10:34:40 am Tom Evans wrote: > On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin wrote: > > On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: > >> > > Password expiry is an orthogonal issue and should be up to > >> > > administrator > >> > > >> > policy. > >> > > >> > Yes, but if you are moving to a different algorithm to improve security, > >> > not > >> > coupling it with an eventual expiration of non-migrated accounts gives a > >> > false sense of security. Any admin worth his/her salt is going to want > >> > the > >> > option of enforcing that sort of policy along with the transparent > >> > update. > >> > They should really be implemented together is all. > >> > >> Account expiration and password expiration are already present. There is > >> absolutely no reason that password algorithm upgrade should be tied in any > >> way > >> to expiration. A transparent algorithm upgrade as proposed is *far* better > >> than the forced password change method that is commonly employed. If the > >> administrator wants to force all accounts to migrate by a set deadline, we > >> already have the expiration facilities in place to accomplish that. > >> Expiring > >> accounts that have not been used in a long time, regardless of algorithm > >> changes, should be part of general housekeeping and may be covered by > >> existing > >> policy. Password expiration serves no purpose, EVER. Password expiration > >> encourages users to choose bad passwords because they are throwaway items. > >> > >> Bruce states it well enough I need not elaborate further > >> https://www.schneier.com/blog/archives/2010/11/changing_passwo.html > >> > >> Anyone who fails to understand the above should NOT be an administrator. > > > > I think you failed to understand my point. I am assuming that an > > administrator > > wants the transparent upgrade (which I think is useful) because they are > > assuming that the hash algorithm is compromised or inferior. To that end, > > they may wish to limit the time window for which they accept hashes > > generated > > using the suspect algorithm. This is separate (I believe) from the issue > > Bruce > > raises above. For example, in this case, the administrator is perfectly > > happy > > for the actual plaintext to remain the same, the administrator simply wants > > to > > enforce the new hash. > > > > As far as I can tell, there is nothing in /etc/login.conf to allow for > > automatic > > account expiration if an account is idle for more than N days. > > > > OTOH, even that is probably not sufficient for the original case since a > > user might > > login with a different authentication method (e.g. ssh key) that would > > reset the > > idle timer without updating the hash. > > > > I suppose if you really were paranoid about the hash what you would want is > > an > > ability to set an expiration time on the hash algo itself where > > authentication > > using that hash always fails after the expiration time. This doesn't > > necessarily > > expire the entire account (e.g. ssh key auth would still work), though it > > might > > be a bit surprising to the user to find that the next time they attempt to > > use > > password authentication it doesn't work. (You would at least want a warning > > about the hash being expired on login via another mechanism.) > > > > All of this is orthogonal to adding a way to upgrade hashes. Yes, all > of the points you mentioned are relevant to general password security, > but doesn't explain why a feature that provides transparent hash > upgrades cannot be added without first adding the features you are > asking for. What I didn't say is that I think adding hash expirations is much more of an edge case and not very useful generically, so probably not worth the hassle. Also, I had originally suggested expiring accounts, but expiring accounts isn't really a good proxy for expiring hashes. Anyway, I think the original idea is good so long as it is optional. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On Fri, 7 Mar 2014 09:13:30 -0500 John Baldwin wrote: > I am assuming that an > administrator wants the transparent upgrade (which I think is useful) > because they are assuming that the hash algorithm is compromised or > inferior. I'd expect it to be done well in advance of that to give plenty of time for the transition. We are talking about brute force attacks and GPU development is relatively predicable. And lets not lose sight of the fact that we are only talking about limited mitigation after an attacker has gained root access, not front-line security. > I suppose if you really were paranoid about the hash what you would > want is an ability to set an expiration time on the hash algo itself > where authentication using that hash always fails after the > expiration time. Whenever I've been required to change passwords it's always been imposed immediately after a login. Just locking-out an account sounds very heavy-handed to me. It seems like it would be trivial to extract a list of accounts using the old-style hashes from master.passwd - at least that way you can send them an email. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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 -- A.J. Kehoe IV (Nanoman) | /"\ ASCII Ribbon Campaign Nanoman's Company | \ / - No HTML/RTF in E-mail E-mail: nano...@nanoman.ca | X- No proprietary attachments WWW: http://www.nanoman.ca/ | / \ - Respect for open standards smime.p7s Description: S/MIME cryptographic signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin wrote: > On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: >> > > Password expiry is an orthogonal issue and should be up to administrator >> > >> > policy. >> > >> > Yes, but if you are moving to a different algorithm to improve security, >> > not >> > coupling it with an eventual expiration of non-migrated accounts gives a >> > false sense of security. Any admin worth his/her salt is going to want the >> > option of enforcing that sort of policy along with the transparent update. >> > They should really be implemented together is all. >> >> Account expiration and password expiration are already present. There is >> absolutely no reason that password algorithm upgrade should be tied in any >> way >> to expiration. A transparent algorithm upgrade as proposed is *far* better >> than the forced password change method that is commonly employed. If the >> administrator wants to force all accounts to migrate by a set deadline, we >> already have the expiration facilities in place to accomplish that. Expiring >> accounts that have not been used in a long time, regardless of algorithm >> changes, should be part of general housekeeping and may be covered by >> existing >> policy. Password expiration serves no purpose, EVER. Password expiration >> encourages users to choose bad passwords because they are throwaway items. >> >> Bruce states it well enough I need not elaborate further >> https://www.schneier.com/blog/archives/2010/11/changing_passwo.html >> >> Anyone who fails to understand the above should NOT be an administrator. > > I think you failed to understand my point. I am assuming that an > administrator > wants the transparent upgrade (which I think is useful) because they are > assuming that the hash algorithm is compromised or inferior. To that end, > they may wish to limit the time window for which they accept hashes generated > using the suspect algorithm. This is separate (I believe) from the issue > Bruce > raises above. For example, in this case, the administrator is perfectly happy > for the actual plaintext to remain the same, the administrator simply wants to > enforce the new hash. > > As far as I can tell, there is nothing in /etc/login.conf to allow for > automatic > account expiration if an account is idle for more than N days. > > OTOH, even that is probably not sufficient for the original case since a user > might > login with a different authentication method (e.g. ssh key) that would reset > the > idle timer without updating the hash. > > I suppose if you really were paranoid about the hash what you would want is an > ability to set an expiration time on the hash algo itself where authentication > using that hash always fails after the expiration time. This doesn't > necessarily > expire the entire account (e.g. ssh key auth would still work), though it > might > be a bit surprising to the user to find that the next time they attempt to use > password authentication it doesn't work. (You would at least want a warning > about the hash being expired on login via another mechanism.) > All of this is orthogonal to adding a way to upgrade hashes. Yes, all of the points you mentioned are relevant to general password security, but doesn't explain why a feature that provides transparent hash upgrades cannot be added without first adding the features you are asking for. It's like trying to prevent people from shooting themselves in the foot by only giving them rocks to throw. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On 2014-03-07 09:13, John Baldwin wrote: > On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: Password expiry is an orthogonal issue and should be up to administrator >>> >>> policy. >>> >>> Yes, but if you are moving to a different algorithm to improve security, not >>> coupling it with an eventual expiration of non-migrated accounts gives a >>> false sense of security. Any admin worth his/her salt is going to want the >>> option of enforcing that sort of policy along with the transparent update. >>> They should really be implemented together is all. >> >> Account expiration and password expiration are already present. There is >> absolutely no reason that password algorithm upgrade should be tied in any >> way >> to expiration. A transparent algorithm upgrade as proposed is *far* better >> than the forced password change method that is commonly employed. If the >> administrator wants to force all accounts to migrate by a set deadline, we >> already have the expiration facilities in place to accomplish that. Expiring >> accounts that have not been used in a long time, regardless of algorithm >> changes, should be part of general housekeeping and may be covered by >> existing >> policy. Password expiration serves no purpose, EVER. Password expiration >> encourages users to choose bad passwords because they are throwaway items. >> >> Bruce states it well enough I need not elaborate further >> https://www.schneier.com/blog/archives/2010/11/changing_passwo.html >> >> Anyone who fails to understand the above should NOT be an administrator. > > I think you failed to understand my point. I am assuming that an > administrator > wants the transparent upgrade (which I think is useful) because they are > assuming that the hash algorithm is compromised or inferior. To that end, > they may wish to limit the time window for which they accept hashes generated > using the suspect algorithm. This is separate (I believe) from the issue > Bruce > raises above. For example, in this case, the administrator is perfectly happy > for the actual plaintext to remain the same, the administrator simply wants to > enforce the new hash. > > As far as I can tell, there is nothing in /etc/login.conf to allow for > automatic > account expiration if an account is idle for more than N days. > > OTOH, even that is probably not sufficient for the original case since a user > might > login with a different authentication method (e.g. ssh key) that would reset > the > idle timer without updating the hash. > > I suppose if you really were paranoid about the hash what you would want is an > ability to set an expiration time on the hash algo itself where authentication > using that hash always fails after the expiration time. This doesn't > necessarily > expire the entire account (e.g. ssh key auth would still work), though it > might > be a bit surprising to the user to find that the next time they attempt to use > password authentication it doesn't work. (You would at least want a warning > about the hash being expired on login via another mechanism.) > 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 -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: > > > Password expiry is an orthogonal issue and should be up to administrator > > > > policy. > > > > Yes, but if you are moving to a different algorithm to improve security, not > > coupling it with an eventual expiration of non-migrated accounts gives a > > false sense of security. Any admin worth his/her salt is going to want the > > option of enforcing that sort of policy along with the transparent update. > > They should really be implemented together is all. > > Account expiration and password expiration are already present. There is > absolutely no reason that password algorithm upgrade should be tied in any > way > to expiration. A transparent algorithm upgrade as proposed is *far* better > than the forced password change method that is commonly employed. If the > administrator wants to force all accounts to migrate by a set deadline, we > already have the expiration facilities in place to accomplish that. Expiring > accounts that have not been used in a long time, regardless of algorithm > changes, should be part of general housekeeping and may be covered by > existing > policy. Password expiration serves no purpose, EVER. Password expiration > encourages users to choose bad passwords because they are throwaway items. > > Bruce states it well enough I need not elaborate further > https://www.schneier.com/blog/archives/2010/11/changing_passwo.html > > Anyone who fails to understand the above should NOT be an administrator. I think you failed to understand my point. I am assuming that an administrator wants the transparent upgrade (which I think is useful) because they are assuming that the hash algorithm is compromised or inferior. To that end, they may wish to limit the time window for which they accept hashes generated using the suspect algorithm. This is separate (I believe) from the issue Bruce raises above. For example, in this case, the administrator is perfectly happy for the actual plaintext to remain the same, the administrator simply wants to enforce the new hash. As far as I can tell, there is nothing in /etc/login.conf to allow for automatic account expiration if an account is idle for more than N days. OTOH, even that is probably not sufficient for the original case since a user might login with a different authentication method (e.g. ssh key) that would reset the idle timer without updating the hash. I suppose if you really were paranoid about the hash what you would want is an ability to set an expiration time on the hash algo itself where authentication using that hash always fails after the expiration time. This doesn't necessarily expire the entire account (e.g. ssh key auth would still work), though it might be a bit surprising to the user to find that the next time they attempt to use password authentication it doesn't work. (You would at least want a warning about the hash being expired on login via another mechanism.) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
> > Password expiry is an orthogonal issue and should be up to administrator > > policy. > > Yes, but if you are moving to a different algorithm to improve security, not > coupling it with an eventual expiration of non-migrated accounts gives a > false sense of security. Any admin worth his/her salt is going to want the > option of enforcing that sort of policy along with the transparent update. > They should really be implemented together is all. Account expiration and password expiration are already present. There is absolutely no reason that password algorithm upgrade should be tied in any way to expiration. A transparent algorithm upgrade as proposed is *far* better than the forced password change method that is commonly employed. If the administrator wants to force all accounts to migrate by a set deadline, we already have the expiration facilities in place to accomplish that. Expiring accounts that have not been used in a long time, regardless of algorithm changes, should be part of general housekeeping and may be covered by existing policy. Password expiration serves no purpose, EVER. Password expiration encourages users to choose bad passwords because they are throwaway items. Bruce states it well enough I need not elaborate further https://www.schneier.com/blog/archives/2010/11/changing_passwo.html Anyone who fails to understand the above should NOT be an administrator. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On Friday, February 28, 2014 4:58:29 pm Eitan Adler wrote: > On 27 February 2014 20:14, Allan Jude wrote: > > With r262501 > > (http://svnweb.freebsd.org/base?view=revision&revision=262501) importing > > the upgraded bcrypt from OpenBSD and eventually changing the default > > identifier for bcrypt to $2b$ it reminded me of a feature that is often > > seen in Forum software and other web apps. > > > > Transparent algorithm upgrade. > ... > > I would strongly support this > > > I think Nick's point is you do want passwords using the "old" hash to expire > are some point if they haven't been auto-converted. > > Password expiry is an orthogonal issue and should be up to administrator policy. Yes, but if you are moving to a different algorithm to improve security, not coupling it with an eventual expiration of non-migrated accounts gives a false sense of security. Any admin worth his/her salt is going to want the option of enforcing that sort of policy along with the transparent update. They should really be implemented together is all. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On 27 February 2014 20:14, Allan Jude wrote: > With r262501 > (http://svnweb.freebsd.org/base?view=revision&revision=262501) importing > the upgraded bcrypt from OpenBSD and eventually changing the default > identifier for bcrypt to $2b$ it reminded me of a feature that is often > seen in Forum software and other web apps. > > Transparent algorithm upgrade. ... I would strongly support this > I think Nick's point is you do want passwords using the "old" hash to expire are some point if they haven't been auto-converted. Password expiry is an orthogonal issue and should be up to administrator policy. > This might actually be more applicable with my next suggestion, exposing > tuneables to control the number of rounds for bcrypt and sha512crypt. As > this would make it easy to upgrade all existing bcrypt/sha512crypt > hashes from the default number of rounds (10^4 and 5000 respectively) to > higher values. Another orthogonal issue: I'd like to see the results of the password hashing competition (see: https://password-hashing.net/. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On Friday, February 28, 2014 12:16:45 pm Allan Jude wrote: > On 2014-02-28 10:07, Nick Hibma wrote: > > > > On 28 Feb 2014, at 02:14, Allan Jude wrote: > > > >> With r262501 > >> (http://svnweb.freebsd.org/base?view=revision&revision=262501) importing > >> the upgraded bcrypt from OpenBSD and eventually changing the default > >> identifier for bcrypt to $2b$ it reminded me of a feature that is often > >> seen in Forum software and other web apps. > >> … > >> This would make it much easier to transition a very large userbase from > >> md5crypt to bcrypt or sha512crypt, rather than expiring the passwords or > >> something. > > > > The sleeping accounts won’t be upgraded, so be left at the ‘insecure’ algorithm. I do see the point of automatic updating of password hashes for a newer algorithm, but ‘not needing expiry’ isn’t the right argument. It is actually an argument opposing your change! > > > > What you probably meant was: don’t hassle users with the change in algorithm, possibly only the users that haven’t ever logged in after 6 months. > > > > Nick > > > > The algorithm upgrade would upgrade everyone, including people who > changed their password just 5 days ago. If an account is dormant, and > never logs in, even a password expirey wouldn't force a password change, > because the user never logs in. > > To better rephrase my point, the goal is to avoid having to adjust every > users password expirey to yesterday, in order to force them all to set > new passwords. I think Nick's point is you do want passwords using the "old" hash to expire are some point if they haven't been auto-converted. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On 2014-02-28 10:07, Nick Hibma wrote: > > On 28 Feb 2014, at 02:14, Allan Jude wrote: > >> With r262501 >> (http://svnweb.freebsd.org/base?view=revision&revision=262501) importing >> the upgraded bcrypt from OpenBSD and eventually changing the default >> identifier for bcrypt to $2b$ it reminded me of a feature that is often >> seen in Forum software and other web apps. >> … >> This would make it much easier to transition a very large userbase from >> md5crypt to bcrypt or sha512crypt, rather than expiring the passwords or >> something. > > The sleeping accounts won’t be upgraded, so be left at the ‘insecure’ > algorithm. I do see the point of automatic updating of password hashes for a > newer algorithm, but ‘not needing expiry’ isn’t the right argument. It is > actually an argument opposing your change! > > What you probably meant was: don’t hassle users with the change in algorithm, > possibly only the users that haven’t ever logged in after 6 months. > > Nick > The algorithm upgrade would upgrade everyone, including people who changed their password just 5 days ago. If an account is dormant, and never logs in, even a password expirey wouldn't force a password change, because the user never logs in. To better rephrase my point, the goal is to avoid having to adjust every users password expirey to yesterday, in order to force them all to set new passwords. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On 28 Feb 2014, at 02:14, Allan Jude wrote: > With r262501 > (http://svnweb.freebsd.org/base?view=revision&revision=262501) importing > the upgraded bcrypt from OpenBSD and eventually changing the default > identifier for bcrypt to $2b$ it reminded me of a feature that is often > seen in Forum software and other web apps. > … > This would make it much easier to transition a very large userbase from > md5crypt to bcrypt or sha512crypt, rather than expiring the passwords or > something. The sleeping accounts won’t be upgraded, so be left at the ‘insecure’ algorithm. I do see the point of automatic updating of password hashes for a newer algorithm, but ‘not needing expiry’ isn’t the right argument. It is actually an argument opposing your change! What you probably meant was: don’t hassle users with the change in algorithm, possibly only the users that haven’t ever logged in after 6 months. Nick signature.asc Description: Message signed with OpenPGP using GPGMail
