Solaris 11 now uses SHA-256, so we can have longer than 8 character passwords now, by default. That is nice.

I'll just make it clear that this password is never used as a line of defence. Only a select few can reach the tools that actually make use of the passwords. Other users go through a web-based management system under a controlled environment.

However, I strive for perfection, so I notice this and wonder.

Can I configure or install a repetition parameter of the Solaris 11 password hash? I want the hash to take 50ms, which is probably more secure than default.

Ideally I want to switch it over to bcrypt. Can you give me some pointers?

1 Answer 1


Are unix/linux sha256/sha512 passwords in /etc/shadow key-strengthened?

Yes. They use a crypt procedure that does a default of 5000 rounds of hashing. The sha256-crypt/sha512-crypt procedure is described here and in java

Can I change the number of rounds?

Yes. Simply edit /etc/pam.d/passwd or /etc/pam.d/common-password (or solaris equivalent) and add 'rounds=73500` at the end of the line that looks similar to:

password    [success=2 default=ignore]  pam_unix.so obscure sha512 rounds=73500

and then change your password using passwd. Why 73500? Well, timing crypt with rounds=5000, I was getting about 3.4 ms per password. (5000*50/3.4 ~ 73500). You can check if a password in your /etc/shadow files was done an abnormal number of rounds if it looks starts with yourusername:$6$rounds=73500$RFzXZTGB$ where $6$ indicates the crypt procedure used (sha256-crypt is $5$, sha512-crypt $6$) followed by number of rounds and then the salt.

But I want bcrypt; Can I switch to that:

Check /etc/pam.d/ and (1) change all references of pam_unix.so to pam_unix2.so (check that the file is there) and (2) then change sha512 to blowfish in /etc/pam.d/common-password


One noticeable difference between bcrypt vs sha512-crypt; is that bcrypt work-factor scales exponentially; e.g., a work-factor of 12, should take double as long as a work-factor of 11, while sha512-crypt rounds scale linearly (e.g., rounds=10000 should take twice as long as rounds=5000). This is simply because bcrypt says do 2work-factor rounds. As a quick benchmark on my machine, one bcrypt round is more expensive than a sha512-crypt round; with a rough equivalence of ~4 ms with rounds=5000 or work-factor=6 (26=64 bcrypt-rounds). But as both can be scaled up this should not be an issue until the number of rounds overflow the unsigned 32-bit/64-bit int (when rounds = 4 billion or 1019 respectively).

Python timing Stuff With sha512-crypt

You can check crypt via python (in linux this performs just as fast as the C version as it just is a thin wrapper for the crypt library written in C)

>>> import crypt
>>> crypt.crypt('testtest', '$6$6LzxTFam$')

In python on my machine with the crypt module it takes about 3.4 ms per sha512-crypt password at 5000 rounds and ~50 ms with 73500 rounds.

>>> import timeit
>>> timer = timeit.Timer("crypt.crypt('testtest', '$6$6LzxTFam$')", setup="import crypt")
>>> timer.timeit(1000)
# with 73500 rounds:
>>> timeit.Timer("crypt.crypt('testtest', '$6$rounds=73500$RFzXTGB$')", 'import crypt').timeit(1000)
  • 1
    For crypt options, the Solaris equivalent is crypt.conf and the information on the default number of rounds is in the man page for each crypt module, such as crypt_sha256(5).
    – alanc
    Aug 19, 2012 at 2:50
  • How to generate a longer salt? I saw a recommendation somewhere that the salt should be at least as big as the output of the hash (which sounds like massive overkill given the size of the default salt, but hey, couldn't hurt, right?)
    – Steven Lu
    Jul 24, 2013 at 4:19
  • 1
    @StevenLu - The salts only job is to prevent brute-forcing accounts in parallel, so the salt only has to be unlikelihood to be used twice for most cases. So with a million hashes with 8-char/base-64 salt, its unlikely they'll be any repeats, and even if there was one, that just means breaking two specific accounts (out of the million) will take half the work as breaking both individually. sha256crypt allows up to 16-char base-64 salts (2^96 possible salts), so unless you expect roughly 2^48 accounts you don't have to worry at all about salt reuse in that case.
    – dr jimbob
    Jul 24, 2013 at 5:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .