My linux must be too old (Debian stable) because I don't see a reference implementation in there, but here is one.

This document also comes with a textual description of the algorithm, which might be better suited for a perl re-implementation (in case nobody knows of an existing implementation).

But wouldn't it be much easier to use the C reference implementation? Why does it need to be perl?

You just need a C compiler on one of the machines, and then you can copy the compiled binary to all the other machines.

Thanks for the referenced documentation, moritz.
The algorithm described before the source is not clearly just a SHA-256 digest.
I was able to compile the source on *bsd , just providing auxiliary implementations for mempcpy() and stpncpy() GNU functions.
I preferred a pure Perl implementation just because my authentication scripts are all Perl, and for future portability. Before trying, I believed that the sha256-crypt from glibc2.7 was too much GNU to port it with ease.

Unfortunately so, I'm not going to write sha256-crypt for Perl, but I will follow moritz' suggestion and plug this external C binary : /

I finally found one in Crypt::Passwd::XS::unix_sha256_crypt() , it is not pure Perl but portable enough for my needs. It is based on the reference C implementation linked by moritz

blah blah blah I not check cpan

Digest::SHA::PurePerl - Perl implementation of SHA-1/224/256/384/512

I'm not too deep into cryptography, so please pardon my ignorance, but...

What exactly is the relation between the SHA-256 digest and the SHA-256 mode of crypt()? Is the latter just a bit of pre processing and post processing around the former?

Perl 6 - second systems done right

blah blah blah, I not understand question :/

I wonder if this is an appropriate time for your company to Meditate on whether now might be a very good time to replace that authentication mechanism with, say, LDAP?

There are many good reasons to consider such a thing, especially when multiple hardware platforms are beginning to enter the mix.   It is at such a juncture that systems begin to become un-manageable, i.e. strictly from a corporate infrastructure-management point of view.   You really do want to be able to control everything from one centralized, consistent administrative interface.   This is usually not how systems begin, but when the bullet is finally bitten and the legacy systems are changed, the company often breathes an immense sigh of relief.   I personally suggest that the idea should be submitted for very serious consideration.   Perhaps, to quote Ensign Chekov, “Now would be a very good time, Scotty...”