[tac_plus] tac_plus login and enable password issue

[Alan McKinnon]

There is almost no reason left anymore to use DES hashes in
tac_plus.conf - they have become somewhat trivial to crack (tip: hire
the cpu grunt to do it from Amazon...)

The sysadmin has to generate the hashes somehow, I usually use openssl:

"openssl passwd -1"
generates MD5 hashes with a random salt
"openssl passwd -1 -salt xxxxxxxx"
does the same with a given salt (xxxxxxxx)

The -table option prints the hash and entered password, useful for
finding stupid users that enter their password at a username prompt
filling your logs with entries like "invalid user password123"

Many folks don't seem to know how tac_plus uses hashes, so a quick
summary is probably in order:

tac_plus uses the crypt() library in the underlying operating system
and asks it to hash a given password against the hash in tac_plus.conf.
This will of course either succeed or fail. As such, you can
transparently put any hash value you like in tac_plus.conf as long as
crypt() supports it and it will JustWork(tm).

On most modern Linuxes these days blowfish, sha-256 and sha-512 are
supported out of the box. One just needs to read man 3 crypt to find the
methods supported and man openssl to find the option switches to
generate those hashes.



On Mon, 12 Dec 2011 08:38:01 -0700
Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:

> Of note, it can be worked around, as I did with a salt in the
> quick/dirty cgi.
> 
> This is from the GNU crypt man pages:
> 
> GNU EXTENSION
> The glibc2 version of this function has the following additional fea-
> tures. If salt is a character string starting with the three charac-
> ters "$1$" followed by at most eight characters, and optionally termi-
> nated by "$", then instead of using the DES machine, the glibc crypt
> function uses an MD5-based algorithm, and outputs up to 34 bytes,
> namely "$1$$", where "" stands for the up to 8 charac-
> ters following "$1$" in the salt, followed by 22 bytes chosen from the
> set [a-zA-Z0-9./]. The entire key is significant here (instead of only
> the first 8 bytes).
> 
> -----Original Message-----
> From: tac_plus-bounces at shrubbery.net
> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
> Sent: Friday, December 09, 2011 2:33 PM
> To: tac_plus at shrubbery.net
> Subject: Re: [tac_plus] tac_plus login and enable password issue
> 
> On Fri, 9 Dec 2011 16:31:03 +0000
> john heasley <heas at shrubbery.net> wrote:
> 
> 
> > > This issue already solve with change the enable password with
> > > other password. In my case this happen if i use login password
> > > and enable password with same character from the first and have
> > > only 1 different character in the end of password. Maybe des
> > > encryption do not check until the last character.
> >
> > crypt(3) normally only supports a maximum 8 character password.
> 
> Of course! That explains everything.
> 
> Incidentally, crypt normally accepts up to 10 characters but only
> uses the first 8 for hashing. An password of 11 characters and longer
> causes an error.
> 
> That one has caused no end of confusion around here. It's one of those
> bizarre limits that users simply cannot get their wits around.
> 
> --
> Alan McKinnnon
> alan.mckinnon at gmail.com
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
> E-Mail to and from me, in connection with the transaction 
> of public business,is subject to the Wyoming Public Records 
> Act, and may be disclosed to third parties.
> 
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus



-- 
Alan McKinnnon
alan.mckinnon at gmail.com