Re: RFC: changes to default password strength checks in pam_unix
Quoting Joey Hess ([EMAIL PROTECTED]): Steve Langasek wrote: Arguably if the consensus is that the default minimum password length should be raised in the users' best interests, we would want to change the makepasswd package's default at the same time. And we might also want to make d-i do the same checks, currently it enforces no minimum lengths at all.. And, to complete that discussion, we currently have a bug report for user-setup (the D-I component which deals with root/user creation and password setting), which suggest to enforce some basic checks of passwords. A proposed implementation is in that bug report and Javier Fernandes Sanguino proposed self to try implementing something stronger. Given the various advices given in this thread about password strength enforcement by default, I'm not sure that we will finally implement this..:-) But, certainly, at least we could enforce the same pwd length than PAM. signature.asc Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
On Tue, Sep 04, 2007 at 08:26:41PM +, Oleg Verych: gmane reading wrote: I.e *i don't care* about entering passwords on middle ground, without knowing, WTF this installer may do with them, not having comfortable environment for that _important_ action. Thus i have silly, empty passwords after installation. Then, i get my imagination and compose really super-druper passwords for root and users (that i create myself by script with, IDs i want/have on filesystems, not by installation process). Well, if you give public network access to any machine before the initial configuration is complete, that's _your_ problem. The UNIX way was always if the admin wants to shot himself in the foot, let him. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sshd defaults (Re: RFC: changes to default password strength checks in pam_unix)
05-09-2007, Gabor Gombas: On Tue, Sep 04, 2007 at 08:26:41PM +, Oleg Verych: gmane reading wrote: I.e *i don't care* about entering passwords on middle ground, without knowing, WTF this installer may do with them, not having comfortable environment for that _important_ action. Thus i have silly, empty passwords after installation. Then, i get my imagination and compose really super-druper passwords for root and users (that i create myself by script with, IDs i want/have on filesystems, not by installation process). Well, if you give public network access to any machine before the initial configuration is complete, that's _your_ problem. The UNIX way was always if the admin wants to shot himself in the foot, let him. Oh, sure! I did network friendly install by downloading only vmlinuz and netinstall initramfs, and i've shot myself in the foot, nice! Give me more of that prehistoric crap, please! Or maybe i just want to test Sid like that. Again i need running OS after reboot, but nothing else, like password management. Test means creating rootfs and all other things, so don't propose me useing some ready fs. I didn't traced issue, but Sid have problem with filesystems, like XFS, which support sparse files. I've gigs of /var/log/lastlog and faillog in every Sid install tests!!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
I apologize if my meaning was unclear; it was not meant to be rude. I think that looking at only the power of modern CPUs - how long it takes to crack a password - misses the point. If you enforce longer passwords than people are comfortable with, you get weaker passwords (or poor password management practices). It's the humans that matter, not the machines. OK, got the point. Sorry for the misunderstanding (I was thinking that you were suggesting the original proposer of this enforcement to get a better brain..:-)). For sure, this point is to be considered and, definitely, this is what I've personnally experienced in day to day life (user getting weak passwords when the length is enforced). Despite this, I still favor some enforcement on passwords and the legnth is part of the problem. I see this as a kind of cultural enforcement of the fact that passwords are important stuff and seeing us (Debian, often seen as the operating system of choice for hardcore geeks) being serious about this is something that I would find correct policy. signature.asc Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
Right, I know there are going to be use cases where 6 is too long for the minimum length, and users will need to lower the setting in /etc/pam.d/common-password. Do you think we need to provide some hook for these Debian Edu users to change the setting automatically, via preseeding or otherwise, or do you think users this is a corner case even within Debian Edu? Well, yesterday I was just about to suggest some debconfization of the password minimum length (low priority question). You just added some debconf crap to pam (now with the best English wording ever...), so adding a few more should be easy. That would certainly help CDD to preseed the question for their own needs. signature.asc Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
04-09-2007, John Kelly: On Sep 3, Lars Wirzenius wrote: ti, 2007-09-04 kello 10:17 +0900, Miles Bader kirjoitti: If the system is excessively anal about what passwords it will let you use, people will just start writing them down... That is arguably better than having passwords which can be guessed by doing brute-force attackes over ssh. I stop brute force attacks by sending auth log messages to a FIFO which I read with a perl script. After 10 login failures, your IP is firewalled for 24 hours. What about having more secure Debian's sshd_config by default? PermitRootLogin no DenyUsers * to start with. Also i would really love to have sshd rc script being able to load different configs easily. I have dummy sshd on 22 port and one actual door on another. Having more dummy services else where, is more security by obscurity. Not 100% protection, but something. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
[Steve Langasek] Right, I know there are going to be use cases where 6 is too long for the minimum length, and users will need to lower the setting in /etc/pam.d/common-password. Do you think we need to provide some hook for these Debian Edu users to change the setting automatically, via preseeding or otherwise, or do you think users this is a corner case even within Debian Edu? I'm not sure. Personally, I want to enforce strong passwords, but I realize that it will be a hard sell in some environment and that we could loose installations if we make it too hard to avoid such enforcing. Some schools even use the same password for all lower grade users instead of providing very easy passwords, and I am not sure if that is better. I am convinced the schools will come up with some new an innovative insecure way to work around any enforced password policy, so it might not matter either way. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Tue, 4 Sep 2007 07:53:08 + (UTC), Oleg Verych [EMAIL PROTECTED] wrote: What about having more secure Debian's sshd_config by default? PermitRootLogin no DenyUsers * Doing remote ssh installations without any console access will make you unhappy with that default. -- Internet service http://www.isp2dial.com/
Re: RFC: changes to default password strength checks in pam_unix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/04/07 03:10, Petter Reinholdtsen wrote: [snip] Some schools even use the same password for all lower grade users instead of providing very easy passwords, and I am not sure if that is better. That's just stupid. Since first grade, my children have been able to remember their own passwords. Sure, they were simple at first (dog and cat), but now in third grade they are relatively sophisticated. I am convinced the schools will come up with some new an innovative insecure way to work around any enforced password policy, so it might not matter either way. :) - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG3RgqS9HxQb37XmcRAtOqAJ9ZmnJ0nsPR3IJlVOk9vgyoGkmr3wCfaZEH stWe4OraHAZcNrEJuzxE79c= =tv0u -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
ma, 2007-09-03 kello 23:40 -0400, John Kelly kirjoitti: On Sep 3, Lars Wirzenius wrote: That is arguably better than having passwords which can be guessed by doing brute-force attackes over ssh. I stop brute force attacks by sending auth log messages to a FIFO which I read with a perl script. After 10 login failures, your IP is firewalled for 24 hours. Works great. I'm sure it does work great. Can you work on making sure it is the default in lenny if openssh-server is installed? -- Talk is cheap. Whining is actually free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Mon, Sep 03, 2007 at 11:40:07PM -0400, John Kelly wrote: I stop brute force attacks by sending auth log messages to a FIFO which I read with a perl script. After 10 login failures, your IP is firewalled for 24 hours. I have a rate-limiting iptables ruleset for SSH (and HTTP). In my experience, brute force attackers give up after the rate-limiter starts tarpitting them. See http://antti-juhani.kaijanaho.fi/stuff/ratelimit.txt - Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
Steve Langasek [EMAIL PROTECTED] writes: For years, the Debian pam packages have by default had a weaker password length requirement than upstream. I can think of no reason for this to be the case, especially when upstream doesn't support a configurable minimum password length and Debian does. Does anyone else have a reasoned argument why Debian should have a weaker password length check than upstream (4 chars instead of 6)? If not, this will be changed in the next upload of pam. I think making it 6 would be a good idea. However, I think 8 as a default may be too long. Having enabled the cracklib stuff in pam_unix while testing the new PAM, I agree that this should remain disabled. Many users (including myself) find the enforcement of all those extra checks annoying, and I agree with other comments that extra checks don't always result in more security due to tacking fixed patterns onto a shorter password. It would be nice to make the pam_unix cracklib stuff configurable in configure, so we don't need to patch the Makefiles, and push that upstream. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpw3XfkBQtGz.pgp Description: PGP signature
Re: RFC: changes to default password strength checks in pam_unix
On Tue, 04 Sep 2007 12:31:15 +0300, Lars Wirzenius [EMAIL PROTECTED] wrote: I stop brute force attacks by sending auth log messages to a FIFO which I read with a perl script. After 10 login failures, your IP is firewalled for 24 hours. I'm sure it does work great. Can you work on making sure it is the default in lenny if openssh-server is installed? It's the type of thing an admin can do locally: set up syslog.conf so that it copies auth log data to a FIFO: auth.info -/var/log/auth auth.=notice-/var/log/auth.notice auth.=notice|/var/tmp/hostaccess.sshd And then read it with a program or script which makes local decisions on how to handle it. If someone wants to take that idea and distribute it with debian, go for it. Personally, I don't have time to fight the political battle that would ensue. -- Internet service http://www.isp2dial.com/
Re: RFC: changes to default password strength checks in pam_unix
Roger Leigh [EMAIL PROTECTED] writes: Having enabled the cracklib stuff in pam_unix while testing the new PAM, I agree that this should remain disabled. Many users (including myself) find the enforcement of all those extra checks annoying, and I agree with other comments that extra checks don't always result in more security due to tacking fixed patterns onto a shorter password. I think you'll find that if the patterns that you use aren't ones that cracklib knows, it *does* make the password more secure. Why? Because guess how attackers try to crack passwords? It's not like most of them write their own password cracking software. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
Steve Langasek wrote: Arguably if the consensus is that the default minimum password length should be raised in the users' best interests, we would want to change the makepasswd package's default at the same time. And we might also want to make d-i do the same checks, currently it enforces no minimum lengths at all.. -- see shy jo signature.asc Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
On Tue, 2007-09-04 at 07:53 +, Oleg Verych wrote: [...] What about having more secure Debian's sshd_config by default? PermitRootLogin no You'll have to convince the openssh package maintainers first - see #105571, #298138 and #431627 for their opinions on whether that change is more secure. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
04-09-2007, Adam D. Barratt: On Tue, 2007-09-04 at 07:53 +, Oleg Verych wrote: [...] What about having more secure Debian's sshd_config by default? PermitRootLogin no You'll have to convince the openssh package maintainers first - see #105571, #298138 and #431627 for their opinions on whether that change is more secure. Thanks for references! But in public i want to say following. While making new installation all i care is rebooting to working operating system. I.e *i don't care* about entering passwords on middle ground, without knowing, WTF this installer may do with them, not having comfortable environment for that _important_ action. Thus i have silly, empty passwords after installation. Then, i get my imagination and compose really super-druper passwords for root and users (that i create myself by script with, IDs i want/have on filesystems, not by installation process). Having ssh defaults is just debian's asking -- here i'm, take me, wise man! -- -o--=O`C #oo'L O ___=E M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Tue, Sep 04, 2007 at 12:31:15PM +0300, Lars Wirzenius wrote: I'm sure it does work great. Can you work on making sure [fail2ban] is the default in lenny if openssh-server is installed? Keep in mind that, by design, fail2ban opens up a denial-of-service vulnerability, especially with the proliferation of NAT routers. It's not something that should be used without people being aware of what it does. -- Dwayne C. Litzenberger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Mon, Sep 03, 2007 at 05:45:49PM +0300, Lars Wirzenius wrote: ma, 2007-09-03 kello 08:33 -0600, Wesley J. Landaker kirjoitti: Especially when the most common response I've seen to a system saying that a password is not long enough is to start adding easily guessable extension strings to the password the user already picked, NOT to sit back down and think up a better, intrinsicly longer password: That's true. Ideally, we would replace passwords with a better authentication system, but I'm not sure that's going to be feasible. IMHO, user-supplied passwords are not appropriate to use over the Internet, because they _will_ be weak. On most of my boxes, passwords are useless for anything except local authentication, and even for that, they aren't used much. How about a Debian policy that enumerates the specific cases where passwords are allowed to be used for authentication, and states that password authentication must be disabled by default for everything else? If you design the system so that it doesn't trust passwords much to begin with, you don't have to care about how strong the passwords are. -- Dwayne C. Litzenberger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Tue, Sep 04, 2007 at 02:50:25PM -0600, Dwayne C. Litzenberger wrote: How about a Debian policy that enumerates the specific cases where passwords are allowed to be used for authentication, and states that password authentication must be disabled by default for everything else? If you design the system so that it doesn't trust passwords much to begin with, you don't have to care about how strong the passwords are. Because not everyone has the luxury of always working from a place where keys can be effectively managed and used. Personally, *none* of my systems allow password logins from the network. However, that needs to be a decision for the individual admin. Think about it. Someone sets up a box and then heads over to a friend's house. He wants to SCP some stuff over. No password authentication? Oops. Too bad. I don't think that will work without driving away users. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
On Tue, 4 Sep 2007 14:50:25 -0600, Dwayne C. Litzenberger [EMAIL PROTECTED] wrote: On most of my boxes, passwords are useless for anything except local authentication, and even for that, they aren't used much. How about a Debian policy that enumerates the specific cases where passwords are allowed to be used for authentication, and states that password authentication must be disabled by default for everything else? IMO, it's better to leave that policy at a local level, determined by local admins. Excessive legislation at a federal level is undesirable to me. -- Internet service http://www.isp2dial.com/
Re: RFC: changes to default password strength checks in pam_unix
On Mon, Sep 03, 2007 at 07:01:38AM +0200, Christian Perrier wrote: It seems you disagree, but don't really give a rationale for it except some other programs we have in Debian default to 6 chars. Am I right? (BTW, this makepasswd doesn't seem to be isntalled by default) And can also be easily patched (I bet). Also, as a makepasswd user, I often have to invoke it as makepasswd --minchars 8 since several passwords I have to generate require a minimum of 8 characters anyway. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
Hi Christian! You wrote: I don't really understand the need for turning your comment this way, which indeed doesn't make your point clear, whether you agree or disagree with the idea of default enforcement of 8 characters length for passwords. It seems you disagree, but don't really give a rationale for it except some other programs we have in Debian default to 6 chars. Am I right? And what's the rationale to change the minimum length to 8? It won't help security, as people who pick weak passwords now, will still pick weak, but longer, passwords. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Mon, September 3, 2007 08:37, Bas Zoetekouw wrote: And what's the rationale to change the minimum length to 8? It won't help security, as people who pick weak passwords now, will still pick weak, but longer, passwords. I agree with Bas here: I'm all for removing the Debian deviation from upstream, so please go ahead with that, but raising it further is not necessarily a useful thing to do. I can easily think of a 6-char password that is a lot more difficult to guess than an 8 char one. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
[Steve Langasek] Does anyone else have a reasoned argument why Debian should have a weaker password length check than upstream (4 chars instead of 6)? If not, this will be changed in the next upload of pam. I've been told that the schools using Debian Edu in lower grades pick very simple and short passwords for the kids, and this will become harder if the minimum lenght is increased. Thought it was best to bring that up publicly. I am not sure if these schools practice is a good idea, nor if it should be allowed in the future, but it should at least be part of the background when the change is considered. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
ma, 2007-09-03 kello 09:30 +0200, Petter Reinholdtsen kirjoitti: I've been told that the schools using Debian Edu in lower grades pick very simple and short passwords for the kids, and this will become harder if the minimum lenght is increased. Thought it was best to bring that up publicly. They will, of course, be able to change the default value for the minimum password length to something less, so I don't think that's a reason against changing the default length. -- Fundamental truth #5: Always ask the simple troubleshooting questions first. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Monday 03 September 2007 01:07:15 Thijs Kinkhorst wrote: On Mon, September 3, 2007 08:37, Bas Zoetekouw wrote: And what's the rationale to change the minimum length to 8? It won't help security, as people who pick weak passwords now, will still pick weak, but longer, passwords. I agree with Bas here: I'm all for removing the Debian deviation from upstream, so please go ahead with that, but raising it further is not necessarily a useful thing to do. I can easily think of a 6-char password that is a lot more difficult to guess than an 8 char one. Especially when the most common response I've seen to a system saying that a password is not long enough is to start adding easily guessable extension strings to the password the user already picked, NOT to sit back down and think up a better, intrinsicly longer password: e.g. password: apple Too short, must be 8 characters! password: apple123 password: dog Too short, must be 8 characters! password: dogabcd So raising the minimum length doesn't necessarily result in better passwords -- *especially* not from the kind of user who uses a derivative of apple or dog[1]. And maybe it's not 1234 or abcd, but I'd wager a lot of people have some sort of algorithm -- or will quickly make one -- to extend a picked password without starting from scratch when e.g. a bunch of unimportant web services demand 15 character passwords. =) Anyway, poor password pickers will still be poor even if you force them to long length ones, and good password pickers will still be good even if you force them to a shorter length. (Remember that there still quite a few systems out there that have a *maximum* password of 8 characters, so you have to get creative anyway...) However, all that said, you have to draw the minimum line somewhere, 8 is a subjectively better arbitrary default than 6, and it's also good to match upstream in this case. [1] Seriously similar to real passwords I've seen in the wild. -- Wesley J. Landaker [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 signature.asc Description: This is a digitally signed message part.
Re: RFC: changes to default password strength checks in pam_unix
I agree with Bas here: I'm all for removing the Debian deviation from upstream, so please go ahead with that, but raising it further is not necessarily a useful thing to do. I can easily think of a 6-char password that is a lot more difficult to guess than an 8 char one. Especially when the most common response I've seen to a system saying that a password is not long enough is to start adding easily guessable extension strings to the password the user already picked, NOT to sit back down and think up a better, intrinsicly longer password: that's what libpam-cracklib is for. -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
ma, 2007-09-03 kello 08:33 -0600, Wesley J. Landaker kirjoitti: Especially when the most common response I've seen to a system saying that a password is not long enough is to start adding easily guessable extension strings to the password the user already picked, NOT to sit back down and think up a better, intrinsicly longer password: That's true. Ideally, we would replace passwords with a better authentication system, but I'm not sure that's going to be feasible. If we decide to stick with short passwords (and I'm not opposing that, Steve's explanation of his strategy made sense to me), we should make sure that we keep the default install such that network access to the computer won't be possible. Then, if anyone installs openssh-server or something, it's their own fault. (If we wanted to be really evil, we would have openssh-server verify that a valid password is of high quality before it accepts it.) -- I am a werehuman. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Sun, Sep 02, 2007 at 10:29:31PM -0400, Daniel Jacobowitz wrote:
How about modern brain availability? You'll just get a lot of annoyed
people changing it back; for example, makepasswd still uses a minimum
length of six.
And pwgen defaults to eight... the length recommended by IETF RFC
4086 section 7.1.1, taken from the US DoD recommendations
(superseding section 7.1 of RFC 1750, which was recommending the
same 8 byte length back in 1994, for perspective).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Sun, Sep 02, 2007 at 10:29:31PM -0400, Daniel Jacobowitz wrote: On Sun, Sep 02, 2007 at 02:39:25PM -0700, Steve Langasek wrote: On Mon, Sep 03, 2007 at 12:04:52AM +0300, Lars Wirzenius wrote: su, 2007-09-02 kello 12:47 -0700, Steve Langasek kirjoitti: Does anyone else have a reasoned argument why Debian should have a weaker password length check than upstream (4 chars instead of 6)? If not, this will be changed in the next upload of pam. What's the justification of not using a minimum password length of 8? Given modern processor power availability, I can't think of one; How about modern brain availability? You'll just get a lot of annoyed people changing it back; for example, makepasswd still uses a minimum length of six. Arguably if the consensus is that the default minimum password length should be raised in the users' best interests, we would want to change the makepasswd package's default at the same time. But I'm in no hurry to drive such a change from the PAM side. I know that even with support from packages like makepasswd this is a change that would annoy users, so I'm not keen to bump the minimum any higher without fairly broad support among developers. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Mon, Sep 03, 2007 at 09:30:34AM +0200, Petter Reinholdtsen wrote: [Steve Langasek] Does anyone else have a reasoned argument why Debian should have a weaker password length check than upstream (4 chars instead of 6)? If not, this will be changed in the next upload of pam. I've been told that the schools using Debian Edu in lower grades pick very simple and short passwords for the kids, and this will become harder if the minimum lenght is increased. Thought it was best to bring that up publicly. I am not sure if these schools practice is a good idea, nor if it should be allowed in the future, but it should at least be part of the background when the change is considered. Right, I know there are going to be use cases where 6 is too long for the minimum length, and users will need to lower the setting in /etc/pam.d/common-password. Do you think we need to provide some hook for these Debian Edu users to change the setting automatically, via preseeding or otherwise, or do you think users this is a corner case even within Debian Edu? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Mon, Sep 03, 2007 at 07:01:38AM +0200, Christian Perrier wrote: Given modern processor power availability, I can't think of one; How about modern brain availability? You'll just get a lot of annoyed people changing it back; for example, makepasswd still uses a minimum length of six. My weak English makes me think your comment is rude. Please excuse me then if this is not. I apologize if my meaning was unclear; it was not meant to be rude. I think that looking at only the power of modern CPUs - how long it takes to crack a password - misses the point. If you enforce longer passwords than people are comfortable with, you get weaker passwords (or poor password management practices). It's the humans that matter, not the machines. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
Daniel Jacobowitz [EMAIL PROTECTED] writes: If you enforce longer passwords than people are comfortable with, you get weaker passwords (or poor password management practices). It's the humans that matter, not the machines. Exactly. If the system is excessively anal about what passwords it will let you use, people will just start writing them down... [One system I like is the password strength meter that you get when signing up for a gmail account, updated with every keystroke when entering a password. I don't recall whether it actually enforced anything, but I think when the user can see what's happening and very easily make incremental modifications, the results would tend to be better.] -miles -- (\(\ (^.^) ()) *This is the cute bunny virus, please copy this into your sig so it can spread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
ti, 2007-09-04 kello 10:17 +0900, Miles Bader kirjoitti: If the system is excessively anal about what passwords it will let you use, people will just start writing them down... That is arguably better than having passwords which can be guessed by doing brute-force attackes over ssh. -- Happiness is going NIH on your own stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Sep 3, Lars Wirzenius wrote: ti, 2007-09-04 kello 10:17 +0900, Miles Bader kirjoitti: If the system is excessively anal about what passwords it will let you use, people will just start writing them down... That is arguably better than having passwords which can be guessed by doing brute-force attackes over ssh. I stop brute force attacks by sending auth log messages to a FIFO which I read with a perl script. After 10 login failures, your IP is firewalled for 24 hours. Works great. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Mon, 03 Sep 2007, John Kelly wrote: I stop brute force attacks by sending auth log messages to a FIFO which I read with a perl script. After 10 login failures, your IP is firewalled for 24 hours. fail2ban is an easy way to do this (for ssh and optionally anything else that people will try to bruteforce.) Description: bans IPs that cause multiple authentication errors Monitors log files (e.g. /var/log/auth.log, /var/log/apache/access.log) and temporarily or persistently bans failure-prone addresses by updating existing firewall rules. The software was completely rewritten at version 0.7.0 and now allows easy specification of different actions to be taken such as to ban an IP using iptables or hostsdeny rules, or simply to send a notification email. Currently, by default, supports ssh/apache/vsftpd but configuration can be easily extended for monitoring any other ASCII file. All filters and actions are given in the config files, thus fail2ban can be adopted to be used with a variety of files and firewalls. . Homepage: http://www.fail2ban.org Don Armstrong -- The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. -- Douglas Adams _Mostly Harmless_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
su, 2007-09-02 kello 12:47 -0700, Steve Langasek kirjoitti: Does anyone else have a reasoned argument why Debian should have a weaker password length check than upstream (4 chars instead of 6)? If not, this will be changed in the next upload of pam. What's the justification of not using a minimum password length of 8? -- Crappy tools are not worth it. Find or make better ones. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Mon, Sep 03, 2007 at 12:04:52AM +0300, Lars Wirzenius wrote: su, 2007-09-02 kello 12:47 -0700, Steve Langasek kirjoitti: Does anyone else have a reasoned argument why Debian should have a weaker password length check than upstream (4 chars instead of 6)? If not, this will be changed in the next upload of pam. What's the justification of not using a minimum password length of 8? Given modern processor power availability, I can't think of one; but I would prefer to deal with this in two parts, first establishing whether we have a good reason to use a /lower/ default than upstream, and then discussing with upstream whether that default should be raised. The upstream default of 6 has been around for at least 5 years, possibly as long as a decade; and the code in question is inactive when pam_unix is linked to cracklib, which I think most distributors other than Debian are doing (we confine the use of libcracklib to the separate pam_cracklib module, to keep cracklib out of base); so there probably isn't any modern justification for this default at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Sun, Sep 02, 2007 at 02:39:25PM -0700, Steve Langasek wrote: The upstream default of 6 has been around for at least 5 years, possibly as long as a decade; and the code in question is inactive when pam_unix is linked to cracklib, which I think most distributors other than Debian are doing (we confine the use of libcracklib to the separate pam_cracklib module, to keep cracklib out of base); so there probably isn't any modern justification for this default at all. Just curious, what is the rationale for wanting to keep cracklib out of base? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
On Sun, Sep 02, 2007 at 07:38:23PM -0400, Roberto C. Sánchez wrote: On Sun, Sep 02, 2007 at 02:39:25PM -0700, Steve Langasek wrote: The upstream default of 6 has been around for at least 5 years, possibly as long as a decade; and the code in question is inactive when pam_unix is linked to cracklib, which I think most distributors other than Debian are doing (we confine the use of libcracklib to the separate pam_cracklib module, to keep cracklib out of base); so there probably isn't any modern justification for this default at all. Just curious, what is the rationale for wanting to keep cracklib out of base? Size and complexity. Adding libpam-cracklib to base would be a 2MB increase in the size of a minimal Debian system on i386, and add 5 packages to the list of what has to be installed before the user can do something as simple as set the initial root password. Also, in terms of modularity, I don't think it makes sense for pam_unix to link to cracklib anyway when we have a separate pam_cracklib module for that (whether it's in a separate package or not). I also think that enabling cracklib password checking is probably not a reasonable default for single-user systems, because however much we might like users to use secure passwords, the hassle of disabling cracklib if the user disagrees with us on this point is enough to make this a very unpleasant user experience. Maybe if and when we have better up-front documentation of what the password requirements are we could consider this as a default, but I don't want users to go through the experience of hitting five different password strength rules, one-by-one, in the ever-more-frustrating process of trying to set a password. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Sun, Sep 02, 2007 at 05:20:42PM -0700, Steve Langasek wrote: On Sun, Sep 02, 2007 at 07:38:23PM -0400, Roberto C. Sánchez wrote: Just curious, what is the rationale for wanting to keep cracklib out of base? Size and complexity. Adding libpam-cracklib to base would be a 2MB increase in the size of a minimal Debian system on i386, and add 5 packages to the list of what has to be installed before the user can do something as simple as set the initial root password. Also, in terms of modularity, I don't think it makes sense for pam_unix to link to cracklib anyway when we have a separate pam_cracklib module for that (whether it's in a separate package or not). I also think that enabling cracklib password checking is probably not a reasonable default for single-user systems, because however much we might like users to use secure passwords, the hassle of disabling cracklib if the user disagrees with us on this point is enough to make this a very unpleasant user experience. Maybe if and when we have better up-front documentation of what the password requirements are we could consider this as a default, but I don't want users to go through the experience of hitting five different password strength rules, one-by-one, in the ever-more-frustrating process of trying to set a password. OK. Good to know. Thanks, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: RFC: changes to default password strength checks in pam_unix
On Sun, Sep 02, 2007 at 02:39:25PM -0700, Steve Langasek wrote: On Mon, Sep 03, 2007 at 12:04:52AM +0300, Lars Wirzenius wrote: su, 2007-09-02 kello 12:47 -0700, Steve Langasek kirjoitti: Does anyone else have a reasoned argument why Debian should have a weaker password length check than upstream (4 chars instead of 6)? If not, this will be changed in the next upload of pam. What's the justification of not using a minimum password length of 8? Given modern processor power availability, I can't think of one; How about modern brain availability? You'll just get a lot of annoyed people changing it back; for example, makepasswd still uses a minimum length of six. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
Given modern processor power availability, I can't think of one; How about modern brain availability? You'll just get a lot of annoyed people changing it back; for example, makepasswd still uses a minimum length of six. My weak English makes me think your comment is rude. Please excuse me then if this is not. I don't really understand the need for turning your comment this way, which indeed doesn't make your point clear, whether you agree or disagree with the idea of default enforcement of 8 characters length for passwords. It seems you disagree, but don't really give a rationale for it except some other programs we have in Debian default to 6 chars. Am I right? (BTW, this makepasswd doesn't seem to be isntalled by default) signature.asc Description: Digital signature
