Open Source Security
Welcome at » 2007 » September

Moments after I posted the previous entry, I received notification that Ulrich Drepper has now published his new proposal[1] to add sha256 and sha512 to crypt. It includes a proposal to lengthen the salt to 16 and allow for the number of rounds to be optionally specified in the salt string. According to the specification, “The maximum length of a password string is therefore (excluding final NUL byte in the C representation):

SHA-256 80 characters
SHA-512 123 characters” [2]

So it looks like we might get a stronger algorithm for passwords widely adopted in the near future.

BTW, I saw this come through the gov-sec mailing list which is a mailing list for Linux adoption by U.S. government. [3]

[1]http://people.redhat.com/drepper/sha-crypt.html
[2]http://people.redhat.com/drepper/SHA-crypt.txt
[3]https://www.redhat.com/mailman/listinfo/gov-sec

Within the past several months, an amazing number of people have asked me about the maximum length of passwords and user names in Red Hat Enterprise Linux and SUSE Linux Enterprise Server. Every one of them says that they have searched for this data and are not able to find it. I’ve searched around too and find it in bits and pieces but not as a consolidated whole. It is funny though (as in things that make you go hmmm), that Solar Designer has written an updated man page for crypt which contains almost all of this data, which is included in the glibc source RPM for SLES but not installed.

On RHEL5, the maximum length of a user name is 31 characters.
On SLES10, the maximum length of a user name is 32.
(Odd results, but try it and you will see!)

Algorithm: crypt
Prefix: none
Maximum Cleartext Password Length: 8
Length of Salt: 2-char (12 bits)
Iterations: 25 (built-in)
Length of Hashed String: 11-char (64bit)
Maximum Length of Hashed Password (prefix + salt + $ + hashed_str): 13-char (0 + 2 + 0 + 11 = 13)

Algorithm: md5
Prefix: $1$
Maximum Cleartext Password Length:
RHEL5.1: 79 (5.1 limit imposed by passwd)
SLES10: 127 (limit imposed by passwd, blames crypt in comment)
Length of Salt: 8-char (48 bits)
Iterations: 1000 (built-in)
Length of Hashed String: 22-char (128bit)
Maximum Length of Hashed Password (prefix + salt + $ + hashed_str): 34-char ( $1$salt$hashed_str ) (3 + 8 + 1 + 22 = 34)

Algorithm: Blowfish (SUSE)
Prefix: $2a$
Maximum Cleartext Password Length: 72
Length of Salt: 22-char (128 bits)
Iterations: 16 (built-in)
Length of Hashed String: 31-char (184bit)
Maximum Length of Hashed Password (prefix + salt + $ + hashed_str): 60-char ($2a$nn$salthashed_str) (4 + 2 + 1 + 22 + 31)

Note that I am still working on experimenting with the formatting of this entry because I find the current presentation relatively unreadable. So this entry may change after it is published.

How do you know that you live in an obscure part of the Net? It took 27 days to get my first 3 spam comments. 🙂

The Register has a story Root-locked Linux for the Masses[1] that I’m finding almost unreadable because in the first sentence, the project originator has overloaded by the acronym TCP and the term Trusted Computing. I find it supremely amusing that someone would start a new project called the Trusted Computing Project, which has absolutely nothing to do with Trusted Computing – talk about starting from a deficit.

[1] http://www.theregister.co.uk/2007/09/14/linux_box/

OSSI submitted OpenSSL 0.9.8 for FIPS 140-2 validation. They have a press release on their home page. They successfully completed a validation of OpenSSL 0.9.7j earlier this year. This is an important validation of the cryptographic strength of OpenSSL. Red Hat has also validated NSS at FIPS 140-2 level 2. Since FISMA was enacted, government agencies are required by law to use FIPS 140-2 validated encryption whenever cryptography is used to protect the security of the system. FISMA explicitly eliminates waivers so these FIPS 140-2 validations are critical for Linux adoption by government agencies.

I just added a link to Alan Robertson’s new blog Managing Computers. I’m glad that Alan is starting a blog because whenever I talk to him, I always learn something new and walk away with a new insight or koan to ponder. I hope that in addition to blogging about Managing Computers, Alan blogs about Managing Communities, because during my limited and short lived involvement in the Linux-HA community I found it wonderfully refreshing how nice people were to each other in that community.

Gerrit is blogging the Linux Kernel Summit this week and his blog entrys are well worth reading, if just for the use of the word kerfuffle. Seriously, there is good stuff there – Andrew Morton on Linux Kernel Quality is especially interesting to me. I had heard that Andrew was tossing around the idea of requiring test cases for patch submissions. That would greatly increase test code coverage and reduce regressions, but based on the discussion in Gerrit’s blog posting, it looks like it would have been dismissed out of hand for requiring to much additional work, if it had even been brought up at the kernel summit. A related topic was brought up during the Documentation session with a proposal to pull LTP tests into Linus’ git tree.
Off the topic of quality, this cracked me up: “The running joke was that long explanations of x86 functionality requested by the s390 people was usually ended with the comment “oh, I understand now, we have an instruction that does that” ;)”
I love this coverage of the Kernel Summit, along with LWN’s coverage, it is better than actually being there!

Joe Herrick has written a very interesting article about security in a virtualized environment: Virtualization security heats up in which he states that 43% of the readers of iTnews have completely disregarded the issue. This article reviews current thoughts about virtualization security and puts virtualization security best practices into print: “Defense in depth and proper virtual machine layout and design, including not mixing VMs with different security postures and requirements on the same host system, are crucial.” (A more detailed list is included later in the article.) This article also carries the meme that open source is more secure: “The million-dollar question here: Is it safer to rely on the open source community to vet and test Xen, or are VMware and other vendors of proprietary hypervisors the best path to secure hosts?” An interesting bit of news that I somehow completely missed: “XenEnterprise has endured the pokes and prods of the open source community, earning a Common Criteria Level 5 rating.” Wow! Congratulations to them! Buried in the middle of the article is how Trusted Computing can help secure this environment. It was nice to see the topic discussed without all of the usual political rhetoric and just the technical features analyzed for their enterprise applicability. Very interesting and educational article. Thanks!

UPDATE: I can’t find any independent verification that XenSource completed an evaluation at EAL5 unfortunately.