Date: Mon, 17 Jun 2013 17:25:54 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Eduardo Morras <emorrasg@yahoo.es> Cc: "<freebsd-questions@freebsd.org>" <freebsd-questions@freebsd.org> Subject: Re: FreeBSD maximum password length Message-ID: <13CA24D6AB415D428143D44749F57D7201F936C4@ltcfiswmsgmb21> In-Reply-To: <20130617164744.1c4e3d02e57de825d500e309@yahoo.es> References: <CAPkyVLw=m5-3HX7YC-Zqm=OgTLMhNYq4trBSWso8qEmPzqV38Q@mail.gmail.com> <44li69diyv.fsf@be-well.ilk.org> <CAPkyVLwNAUU_2E0d8Go6OP4m7jqHeHKCWEt5WRhtYcgRBSQ2nQ@mail.gmail.com> <20130617164744.1c4e3d02e57de825d500e309@yahoo.es>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 17, 2013, at 7:47 AM, Eduardo Morras wrote: > On Mon, 17 Jun 2013 17:49:56 +0330 > takCoder <tak.official@gmail.com> wrote: >>=20 >> I need to moderate the input password in my system's user interface. And= I >> believe i have tested longer passwords than that, about 1000 characters >> long, and there was no limitations, via using this command in a /bin/sh >> test shell script : "echo PASSWORD | pw user mod USER -h 0". >=20 > If I remember well, any password longer than default size is truncated, s= o passwords >=20 > a) 'AhN12Njufsn8794432kjfvsnkkJHNDSMNDKh844mNJKnhjhu8u8424' > b) 'AhN12Njufsn8794432kj' >=20 > have the same salt hash value and both validate the user. >=20 Depends on the hashing algo. Old crypt(3) stored passwords with a 12-bit (2x Base64 characters; [0-9a-zA= -Z./]) followed by the hashed cleartext. This [ancient] format limited password input to 8 characters. With this alg= orithm, input beyond 8 characters was ignored, so the behavior you describe= is accurate -- with the old DES based one-way hash algorithm (which hasn't= been default for a vey long time). The default in FreeBSD is MD5, but you can go to AES256 (Rijndael) if you l= ike, or Blowfish, or whatever you like. Each of these has different limitat= ions, but will not exhibit the behavior you describe above. There is no limit to these algorithms, only in the implementations -- that = is to say that if you implement a read-buffer of 128k, that's the practical= limit of your applications input (read: these algorithms have no limitatio= ns on input, however that being stated=85 no CRC algorithm has a limitation= on input). But be aware=85 What makes these algorithms more secure is their larger salts *and* their s= tated rate of collisions. MD5 is no longer considered secure. It's secure *enough* for most people, b= ut if you run a tight ship, any one with a few multiplexed GPUs running a C= UDA thread against your hash can break it in a matter of a week if not days= . The benchmark (in my mind) for any cryptographically strong algo is that = with almost dream-like hardware, it would still be impossible to reverse th= e one-way trapdoor hash in one's-own lifetime. Of course, achieving that as a human can be hard considering that we rarely= (if ever) produce strong inputs to the strong algorithms. However, if you = want to be pedantic about choosing a strong password=85 you should actually= take respite in the fact that these algorithms is still like their CRC bre= thren in that: Inputs greater than the hash length are cryptographically more secure than = inputs shorter than the hash length. I digress=85 --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201F936C4>