Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201F936C4>