<div dir="ltr">To Alan's point, try your password in a better hasher, like this one I threw up.  (Trivial python - available on request)<div><br></div><div><a href="https://192.146.215.251/cgi-bin/gen_pass.cgi">https://192.146.215.251/cgi-bin/gen_pass.cgi</a><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 28, 2015 at 11:01 AM, Alan McKinnon <span dir="ltr"><<a href="mailto:alan.mckinnon@gmail.com" target="_blank">alan.mckinnon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 28 Feb 2015 08:29:42 -0800<br>
Matt Almgren <<a href="mailto:malmgren@skyfire.com">malmgren@skyfire.com</a>> wrote:<br>
<br>
> I never noticed this before, but I see the same 8-character problem<br>
> with version F4.0.4.27a  and CentOS 6.4.<br>
<br>
<br>
</span>You will see it on all versions of tac_plus on all distros. The<br>
password encryption is done in the crypt() system call which is where<br>
DES is implemented.<br>
<br>
It's not a bug it's a feature, it's just the way DES works. One more<br>
reason why you should not use DES for password hashing, superior types<br>
exist.<br>
<div class="HOEnZb"><div class="h5"><br>
Alan<br>
_______________________________________________<br>
tac_plus mailing list<br>
<a href="mailto:tac_plus@shrubbery.net">tac_plus@shrubbery.net</a><br>
<a href="http://www.shrubbery.net/mailman/listinfo/tac_plus" target="_blank">http://www.shrubbery.net/mailman/listinfo/tac_plus</a><br>
</div></div></blockquote></div><br></div>

<pre>
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.