Slashdot Mirror

Actually, it's one of several errors in BleepingComputer's rewording of our original announcement. I am grateful to them for reporting on our work and I understand that journalists have to reword for original content and copyright reasons, but this inevitably leads to errors, and we'd be happier with people reading our original announcement.

No, LKRG is not just for known vulnerabilities. It is both for currently known and for future vulnerabilities that are yet unknown, but it's limited in the vulnerability categories and exploitation/persistence methods that it will catch.

In the original announcement, we acknowledge that LKRG is highly controversial, can be bypassed, is limited in what it can do, and isn't always a good idea to use. We say that it provides merely the controversial notion of security through diversity (as long as LKRG, or a given branch of it, is not very popular), much like running an uncommon OS kernel would, but without the usual drawbacks of actually running an uncommon OS.

Indeed, that's not perfect security, unlike fixing all security vulnerabilities would be - but realistically the Linux kernel is monolithic and so huge (and growing) and distros enable so much of its functionality by default (including with module auto-loading, ouch) that in practice it will always have plenty of vulnerabilities anyway, and a clutch like LKRG may fit some Linux installs just right, unfortunately. Not make them "secure" - just reduce the percentage of successful compromises in the real world.

We try to give some guidelines on where LKRG may be beneficial (on systems that are not well-maintained or not promptly rebooted into new kernels anyway) and where it's probably not (on otherwise hardened and/or well-maintained and promptly updated/rebooted/live-patched systems). We're not delusional, and we try to do our best not to mislead the prospective users of LKRG.

I don't think we're hearing the whole story. This post by Brad, in response to Linus' infamous "garbage" remark, seems to indicate that the patches are and have been split before, only Brad is (quite evidently) fed up of jumping through hoops for years for no pay with nothing to show for it at the end. He's right in that under the GPL there is no obligation to perform further work for free. If Bruce's legal theory holds, then it implies that coders releasing code under the GPL must continue to supply further work on that project whether they want to or not. That doesn't sound right to me, in fact it sounds like indentured slavery.

I can actually not find a single CVE for systemd since it was put into production.

Well congrats, now you have at least two: http://www.openwall.com/lists/oss-security/2016/09/30/1

* CVE-2016-7795
* CVE-2016-7796

This release contains security fixes. At least this one stood out, but more of the changelog sounds like it might fix exploitable issues.

Here is one http://www.openwall.com/lists/...

http://www.openwall.com/lists/...

At most sizeof(char *) bytes can be overwritten (ie, 4 bytes on 32-bit machines, and 8 bytes on 64-bit machines). Bytes can be overwritten only with digits ('0'...'9'), dots ('.'), and a terminating null character ('\0').

With only being able to overwrite 4 bytes max, you would think not much could be done, and indeed, mostly they were only able to make things crash. Most servers don't do dns lookup of a remotely supplied address, but mail-servers can, to verify the sender is correct.

Astonishingly, even without being able to write assembly shell-code, they were able to get the Exim mail server to execute arbitrary remote commands. That is the only vulnerability found so far.

From the oss-sec mailing list:

http://www.openwall.com/lists/...
This is not a vulnerability, this is expected behaviour.

http://www.openwall.com/lists/...

This paragraph suggests so many things which are simply wrong, confused,
or irrelevant that i don't know what to make of the rest of the article.

  * modern debian GNU/Linux systems do not have a wheel group at all. No
particular versions or flavors of "Linux system"

  * on systems where members of group wheel really do have unrestricted
access to the su command, having wheel in the first place *is* the
vulnerability -- it is a misconfiguration to expect an account to be
non-privileged if it is a member of wheel.

  * the last sentence appears to be about setuid/setgid binaries, but
makes no mention that the overwhelming majority of binaries are not
setuid/setgid.

Later on, the post suggests that wheel group membership is related to
sudo privileges.

It also seems to assume that polkit always permits access for members of
group wheel. I can find no such configuration on a modern debian system.

I don't think there's anything significant in this ambiguous,
underspecified, and confused report.

http://www.openwall.com/lists/...

Yeah I looked into this (the article/etc was completely confusing and
took some time to parse):

1) the article states they contacted red hat, we were unable to find
any inbound email or bugzilla entry pertaining to this issue, as always
if you have an issue you wish to report please contact secalert@...hat.com

2) this is expected behaviour, admin users can install software (do I
have to say this? really? yes. I was told I should say this).

3) don't run web apps as admin users (do I have to say this? really?
yes. I was told I should say this).

4) if you feel the need to run a web app as an admin user restrict what
they can do via SELinux, and don't let them install software (do I have
to say this? really? yes. I was told I should say this).

So TL;DR: it's not a security vulnerability, and it will NOT be getting
a CVE.

I can only assume this article/vuln is perhaps referring to something
like Cpanel and other control panels that people sometimes install
insecurely/improperly and then never update. Or something. Who knows.

From the oss-sec mailing list:

http://www.openwall.com/lists/...
This is not a vulnerability, this is expected behaviour.

http://www.openwall.com/lists/...

This paragraph suggests so many things which are simply wrong, confused,
or irrelevant that i don't know what to make of the rest of the article.

  * modern debian GNU/Linux systems do not have a wheel group at all. No
particular versions or flavors of "Linux system"

  * on systems where members of group wheel really do have unrestricted
access to the su command, having wheel in the first place *is* the
vulnerability -- it is a misconfiguration to expect an account to be
non-privileged if it is a member of wheel.

  * the last sentence appears to be about setuid/setgid binaries, but
makes no mention that the overwhelming majority of binaries are not
setuid/setgid.

Later on, the post suggests that wheel group membership is related to
sudo privileges.

It also seems to assume that polkit always permits access for members of
group wheel. I can find no such configuration on a modern debian system.

I don't think there's anything significant in this ambiguous,
underspecified, and confused report.

http://www.openwall.com/lists/...

Yeah I looked into this (the article/etc was completely confusing and
took some time to parse):

1) the article states they contacted red hat, we were unable to find
any inbound email or bugzilla entry pertaining to this issue, as always
if you have an issue you wish to report please contact secalert@...hat.com

2) this is expected behaviour, admin users can install software (do I
have to say this? really? yes. I was told I should say this).

3) don't run web apps as admin users (do I have to say this? really?
yes. I was told I should say this).

4) if you feel the need to run a web app as an admin user restrict what
they can do via SELinux, and don't let them install software (do I have
to say this? really? yes. I was told I should say this).

So TL;DR: it's not a security vulnerability, and it will NOT be getting
a CVE.

I can only assume this article/vuln is perhaps referring to something
like Cpanel and other control panels that people sometimes install
insecurely/improperly and then never update. Or something. Who knows.

From the oss-sec mailing list:

http://www.openwall.com/lists/...
This is not a vulnerability, this is expected behaviour.

http://www.openwall.com/lists/...

This paragraph suggests so many things which are simply wrong, confused,
or irrelevant that i don't know what to make of the rest of the article.

  * modern debian GNU/Linux systems do not have a wheel group at all. No
particular versions or flavors of "Linux system"

  * on systems where members of group wheel really do have unrestricted
access to the su command, having wheel in the first place *is* the
vulnerability -- it is a misconfiguration to expect an account to be
non-privileged if it is a member of wheel.

  * the last sentence appears to be about setuid/setgid binaries, but
makes no mention that the overwhelming majority of binaries are not
setuid/setgid.

Later on, the post suggests that wheel group membership is related to
sudo privileges.

It also seems to assume that polkit always permits access for members of
group wheel. I can find no such configuration on a modern debian system.

I don't think there's anything significant in this ambiguous,
underspecified, and confused report.

http://www.openwall.com/lists/...

Yeah I looked into this (the article/etc was completely confusing and
took some time to parse):

1) the article states they contacted red hat, we were unable to find
any inbound email or bugzilla entry pertaining to this issue, as always
if you have an issue you wish to report please contact secalert@...hat.com

2) this is expected behaviour, admin users can install software (do I
have to say this? really? yes. I was told I should say this).

3) don't run web apps as admin users (do I have to say this? really?
yes. I was told I should say this).

4) if you feel the need to run a web app as an admin user restrict what
they can do via SELinux, and don't let them install software (do I have
to say this? really? yes. I was told I should say this).

So TL;DR: it's not a security vulnerability, and it will NOT be getting
a CVE.

I can only assume this article/vuln is perhaps referring to something
like Cpanel and other control panels that people sometimes install
insecurely/improperly and then never update. Or something. Who knows.

The linked patch only fixes the primary vulnerability. There is an additional trailing string processing vulnerability (CVE-2014-7169) that is fixed by using the patch posted here.

I've read a bit through the threads and think that the reason it took so long was because they decided to remove a feature to fix the problem:

I believe the current plan is to completely remove the transliteration
module support, as it hasn't worked for 10+ years.

The git commit message states the same. There were really some problems in that function: https://sourceware.org/ml/libc...

> I'm not familiar with how CVE internals work

Why are you even arguing here, then?

CVE IDs are assigned by a number of CVE numbering authorities. This includes Mitre itself plus big software companies like MS and Red Hat, plus few extras. Each authority requests pools of CVE IDs to assign from Mitre. Year in CVE ID is the year of original bug report, which blows up the "sat on it for 6 months" theory.

Here's that initial bug report referenced in CVE. Note how it says: "Date: Mon, 5 May 2014 12:08:11 +0200 [snipped message to oss-security list] CVE-2014-0196 has been assigned to this issue. [snipped] Date: Tue, 29 Apr 2014 12:38:36 -0400 [snipped original bug report and patch] We, at suse, would appreciate embargo till Mon May 5th."

That is, discovered and reported with a patch at 140429, then published at 140505 with an ID from SUSE's pool reserved at 131203.

HTH, HAND.

PS: Hearbleed is also from 131203 IDs batch, as well as at least 323 others this year.

Ive used passphrases from passwdqc for quite some time. theyre just as complex and a whole lot easier to remember. The downside being many websites still restrict users to 8 or 10 character passwords whereas phrases can easily consume 17 or more characters.

Presentation slides (view online or download PDF), and links to the paper (PDF) and "dedrop" source code (GitHub):
http://www.openwall.com/presentations/WOOT13-Security-Analysis-of-Dropbox/

USENIX WOOT '13 web page dedicated to this talk, including video and audio (view/listen online or download the video .mp4 via a direct link from there):
https://www.usenix.org/looking-inside-drop-box

(Somehow the Slashdot story only links to a third-party article and to the paper PDF, but not to any of the authors' and the conference's web-based content.)

I assigned CVEs here: http://openwall.com/lists/oss-security/2013/06/30/2

I assigned CVEs here: http://openwall.com/lists/oss-security/2013/06/30/2

Openwall (OWL).

Secure?
When packaged for Owl, the software components are configured or, when necessary, modified in order to provide safe defaults, apply the least privilege principle, and introduce privilege separation. The use of safe defaults, where optional and potentially dangerous features need to be turned on explicitly, lets us audit the pieces of code used in in the default configuration in a more thorough way. Extra systems administration facilities ("owl-control") are provided for managing system features such as the optional SUID/SGID binaries independently from installing the corresponding packages. Every Owl package will have its audit status documented to allow for risk assessment.

Appliance?
Just the base OS - like a bootstrapped Deb. Allows packages from RHEL, CentOS and Fedora.

As per http://www.openwall.com/lists/oss-security/2013/01/01/3 this issue was assigned CVE-2012-6084. Remember folks, you can get your CVEs in advance which makes life easier for everyone. Please see http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html for details.

Thats how Linux (unix in general?) does it

$algo$salt$password_hash

Other systems have the problem of being too simple, aka the program just checks an unsalted MD5 hash of a local file/database. Or too complex, Vendor1 validates passwords this way and Vendor2 validates passwords that way, and all this crap has to work together.

Any new system should use some kind of password API, like http://www.openwall.com/phpass/ for example, that handles the encoding and decoding of passwords and different types of password in the same database.

you're trying (poorly) to troll, but for those who actually are curious, no, you should not do anything of the sort. you should use a proper password hashing framework which makes use of hash functions actually intended for use with authentication systems, such as phpass.

The biggest problem is that those cryptographic hashes tend to be easily parallelizeable on a commercial GPU, resulting in a brute force attack many times faster than an ordinary CPU. Hashes like bcrypt are much less GPU friendly.

John the Ripper now able to crack office files and use GPUs

4 July 2012, 12:38

http://h-online.com/-1631901

"Version 1.7.9-jumbo-6 of the John the Ripper password cracker sees significant format support enhancements. The open source tool is now able to crack password-protected office documents (Office 2007/2010 and OpenDocument) and Firefox, Thunderbird and SeaMonkey master passwords, as well as WPA-PSK keys and Mac OS X keychains. It can also request to use GPUs via CUDA and OpenCL. The suffix "jumbo" appears to be intended literally â" more than 40,000 lines of code have been added in the six months since the previous release.

Developer Solar Designer told The H's associates at heise Security that, in developing GPU support, the focus has been on modern functions which can be slow to calculate, such as WPA-PSK and Unix password hashes. For some functions, such as Ubuntu's standard hash function (sha512crypt) and the time-consuming bcrypt, there were, according to the developers, no crackers with GPU support until now, "because others were unhappy about releasing a tool with 'non-impressive' speed numbers, even if this is desirable in practice".

In the case of sha512crypt, this means that the GPU on a GeForce GTX 570 graphics card can generate around 11,000 hashes per second â" still more than five times faster than on a computer with eight CPU cores. By comparison, for SHA1 hashes, with GPU support this figure would normally be in the millions. For bcrypt, a graphics card just beats an eight-core system by a hair's breadth â" in both cases the maximum figure is around 5,000 hashes. The inability of GPUs to realise speed gains with bcrypt is due to the algorithm's design, which is very memory intensive. According to Solar Designer, the developers were primarily concerned with finding out just how slow the bcrypt implementation would be."

- http://www.openwall.com/lists/john-users/2012/06/29/1
- http://www.openwall.com/john/
- http://en.wikipedia.org/wiki/OpenDocument
- http://en.wikipedia.org/wiki/Bcrypt
- http://www.reddit.com/r/netsec/comments/vsygc/john_the_ripper_179jumbo6_adds_gpu_support/
- http://www.h-online.com/news/item/Cracking-DES-faster-with-John-the-Ripper-1273585.html
* http://www.h-online.com/security/news/item/John-the-Ripper-now-able-to-crack-office-files-and-use-GPUs-1631901.html

crve@h-online.com
Copyright © 2012 Heise Media UK Ltd.

###
Sensitive Information Security Sources and Breaches

Unauthorized disclosures of secrets are essential for democracy.

In response to Wikileaks background inquiries Cryptome offers that there are hundreds of online and offline sources of sensitive information security breaches which preceded Wikileaks beginning about 120 years ago. This outline traces the conflict between technological capabilities for sensitive information breaches and control by law enforcement when technical countermeasures are insufficient -- a few examples among many others worldwide:

http://cryptome.org/0002/siss.htm
####
Feds Look to Fight Leaks With âFog of Disinformationâ(TM)

http://cryptogon.com/?p=30257

July 4th, 2012

Via: Danger Room:

http://www.wired.com/dangerroom/2012/07/fog-computing/all/

John the Ripper now able to crack office files and use GPUs

4 July 2012, 12:38

http://h-online.com/-1631901

"Version 1.7.9-jumbo-6 of the John the Ripper password cracker sees significant format support enhancements. The open source tool is now able to crack password-protected office documents (Office 2007/2010 and OpenDocument) and Firefox, Thunderbird and SeaMonkey master passwords, as well as WPA-PSK keys and Mac OS X keychains. It can also request to use GPUs via CUDA and OpenCL. The suffix "jumbo" appears to be intended literally â" more than 40,000 lines of code have been added in the six months since the previous release.

Developer Solar Designer told The H's associates at heise Security that, in developing GPU support, the focus has been on modern functions which can be slow to calculate, such as WPA-PSK and Unix password hashes. For some functions, such as Ubuntu's standard hash function (sha512crypt) and the time-consuming bcrypt, there were, according to the developers, no crackers with GPU support until now, "because others were unhappy about releasing a tool with 'non-impressive' speed numbers, even if this is desirable in practice".

In the case of sha512crypt, this means that the GPU on a GeForce GTX 570 graphics card can generate around 11,000 hashes per second â" still more than five times faster than on a computer with eight CPU cores. By comparison, for SHA1 hashes, with GPU support this figure would normally be in the millions. For bcrypt, a graphics card just beats an eight-core system by a hair's breadth â" in both cases the maximum figure is around 5,000 hashes. The inability of GPUs to realise speed gains with bcrypt is due to the algorithm's design, which is very memory intensive. According to Solar Designer, the developers were primarily concerned with finding out just how slow the bcrypt implementation would be."

- http://www.openwall.com/lists/john-users/2012/06/29/1
- http://www.openwall.com/john/
- http://en.wikipedia.org/wiki/OpenDocument
- http://en.wikipedia.org/wiki/Bcrypt
- http://www.reddit.com/r/netsec/comments/vsygc/john_the_ripper_179jumbo6_adds_gpu_support/
- http://www.h-online.com/news/item/Cracking-DES-faster-with-John-the-Ripper-1273585.html
* http://www.h-online.com/security/news/item/John-the-Ripper-now-able-to-crack-office-files-and-use-GPUs-1631901.html

crve@h-online.com
Copyright © 2012 Heise Media UK Ltd.

###
Sensitive Information Security Sources and Breaches

Unauthorized disclosures of secrets are essential for democracy.

In response to Wikileaks background inquiries Cryptome offers that there are hundreds of online and offline sources of sensitive information security breaches which preceded Wikileaks beginning about 120 years ago. This outline traces the conflict between technological capabilities for sensitive information breaches and control by law enforcement when technical countermeasures are insufficient -- a few examples among many others worldwide:

http://cryptome.org/0002/siss.htm
####
Feds Look to Fight Leaks With âFog of Disinformationâ(TM)

http://cryptogon.com/?p=30257

July 4th, 2012

Via: Danger Room:

http://www.wired.com/dangerroom/2012/07/fog-computing/all/

John the Ripper now able to crack office files and use GPUs

4 July 2012, 12:38

http://h-online.com/-1631901

"Version 1.7.9-jumbo-6 of the John the Ripper password cracker sees significant format support enhancements. The open source tool is now able to crack password-protected office documents (Office 2007/2010 and OpenDocument) and Firefox, Thunderbird and SeaMonkey master passwords, as well as WPA-PSK keys and Mac OS X keychains. It can also request to use GPUs via CUDA and OpenCL. The suffix "jumbo" appears to be intended literally â" more than 40,000 lines of code have been added in the six months since the previous release.

Developer Solar Designer told The H's associates at heise Security that, in developing GPU support, the focus has been on modern functions which can be slow to calculate, such as WPA-PSK and Unix password hashes. For some functions, such as Ubuntu's standard hash function (sha512crypt) and the time-consuming bcrypt, there were, according to the developers, no crackers with GPU support until now, "because others were unhappy about releasing a tool with 'non-impressive' speed numbers, even if this is desirable in practice".

In the case of sha512crypt, this means that the GPU on a GeForce GTX 570 graphics card can generate around 11,000 hashes per second â" still more than five times faster than on a computer with eight CPU cores. By comparison, for SHA1 hashes, with GPU support this figure would normally be in the millions. For bcrypt, a graphics card just beats an eight-core system by a hair's breadth â" in both cases the maximum figure is around 5,000 hashes. The inability of GPUs to realise speed gains with bcrypt is due to the algorithm's design, which is very memory intensive. According to Solar Designer, the developers were primarily concerned with finding out just how slow the bcrypt implementation would be."

- http://www.openwall.com/lists/john-users/2012/06/29/1
- http://www.openwall.com/john/
- http://en.wikipedia.org/wiki/OpenDocument
- http://en.wikipedia.org/wiki/Bcrypt
- http://www.reddit.com/r/netsec/comments/vsygc/john_the_ripper_179jumbo6_adds_gpu_support/
- http://www.h-online.com/news/item/Cracking-DES-faster-with-John-the-Ripper-1273585.html
* http://www.h-online.com/security/news/item/John-the-Ripper-now-able-to-crack-office-files-and-use-GPUs-1631901.html

crve@h-online.com
Copyright © 2012 Heise Media UK Ltd.

####
Sensitive Information Security Sources and Breaches

Unauthorized disclosures of secrets are essential for democracy.

In response to Wikileaks background inquiries Cryptome offers that there are hundreds of online and offline sources of sensitive information security breaches which preceded Wikileaks beginning about 120 years ago. This outline traces the conflict between technological capabilities for sensitive information breaches and control by law enforcement when technical countermeasures are insufficient -- a few examples among many others worldwide:

http://cryptome.org/0002/siss.htm
####
Feds Look to Fight Leaks With âFog of Disinformationâ(TM)

http://cryptogon.com/?p=30257

July 4th, 2012

Via: Danger Room:

http://www.wired.com/dangerroom/2012/07/fog-computing/all

John the Ripper now able to crack office files and use GPUs

4 July 2012, 12:38

http://h-online.com/-1631901

"Version 1.7.9-jumbo-6 of the John the Ripper password cracker sees significant format support enhancements. The open source tool is now able to crack password-protected office documents (Office 2007/2010 and OpenDocument) and Firefox, Thunderbird and SeaMonkey master passwords, as well as WPA-PSK keys and Mac OS X keychains. It can also request to use GPUs via CUDA and OpenCL. The suffix "jumbo" appears to be intended literally â" more than 40,000 lines of code have been added in the six months since the previous release.

Developer Solar Designer told The H's associates at heise Security that, in developing GPU support, the focus has been on modern functions which can be slow to calculate, such as WPA-PSK and Unix password hashes. For some functions, such as Ubuntu's standard hash function (sha512crypt) and the time-consuming bcrypt, there were, according to the developers, no crackers with GPU support until now, "because others were unhappy about releasing a tool with 'non-impressive' speed numbers, even if this is desirable in practice".

In the case of sha512crypt, this means that the GPU on a GeForce GTX 570 graphics card can generate around 11,000 hashes per second â" still more than five times faster than on a computer with eight CPU cores. By comparison, for SHA1 hashes, with GPU support this figure would normally be in the millions. For bcrypt, a graphics card just beats an eight-core system by a hair's breadth â" in both cases the maximum figure is around 5,000 hashes. The inability of GPUs to realise speed gains with bcrypt is due to the algorithm's design, which is very memory intensive. According to Solar Designer, the developers were primarily concerned with finding out just how slow the bcrypt implementation would be."

- http://www.openwall.com/lists/john-users/2012/06/29/1
- http://www.openwall.com/john/
- http://en.wikipedia.org/wiki/OpenDocument
- http://en.wikipedia.org/wiki/Bcrypt
- http://www.reddit.com/r/netsec/comments/vsygc/john_the_ripper_179jumbo6_adds_gpu_support/
- http://www.h-online.com/news/item/Cracking-DES-faster-with-John-the-Ripper-1273585.html
* http://www.h-online.com/security/news/item/John-the-Ripper-now-able-to-crack-office-files-and-use-GPUs-1631901.html

crve@h-online.com
Copyright © 2012 Heise Media UK Ltd.

####
Sensitive Information Security Sources and Breaches

Unauthorized disclosures of secrets are essential for democracy.

In response to Wikileaks background inquiries Cryptome offers that there are hundreds of online and offline sources of sensitive information security breaches which preceded Wikileaks beginning about 120 years ago. This outline traces the conflict between technological capabilities for sensitive information breaches and control by law enforcement when technical countermeasures are insufficient -- a few examples among many others worldwide:

http://cryptome.org/0002/siss.htm
####
Feds Look to Fight Leaks With âFog of Disinformationâ(TM)

http://cryptogon.com/?p=30257

July 4th, 2012

Via: Danger Room:

http://www.wired.com/dangerroom/2012/07/fog-computing/all

The existing password hashing methods won't run on GPU well for user authentication, even when they do run well for cracking passwords. They lack sufficient parallelism within one hash computation. This is an issue I first raised in 1998, in pre-GPU context (it applies to recent CPUs as well, and the problem is getting worse with time).

A solution is to define a new password hashing method with sufficient (configurable) parallelism within one instance. We could then consider running it on GPU, unless it is GPU-unfriendly by other criteria. Do we really want to, though? GPUs in servers are not yet common, except in computing clusters. Their reliability may be lower than that of other typical server components. The drivers are currently relatively unreliable as well (although they may be reliable enough if running the same code, with no upgrades). Sure, computing clusters use them anyway, and get them to run reliably enough for their needs, but the extra hurdle and/or risk is there. Will we get embedded GPUs in typical servers soon? Will they be similar to current gamers' or HPC GPUs or not? This is not clear. Then there's Intel MIC, which delivers GPU-like performance, but is a lot closer to a CPU - it will require a lot of parallelism in the algorithm too, but it may run certain types of otherwise GPU-unfriendly code. Is this possibly a better target?

For current GPUs, a better strategy might be to make them inefficient - by using GPU-unfriendly hashes (for cracking, and for validation as well - as a side-effect).

We had a project last summer to research this kind of possibilities, focusing on use of FPGA boards in authentication servers. This could optionally buy us GPU-unfriendliness (if we want to make things more difficult for attackers with GPUs, but not FPGAs, and for botnets, which almost surely will lack FPGAs). We even considered some moderate CPU-unfriendliness of the component that we'd put on FPGA. Specifically, we experimented with bcrypt on FPGA, as well as with much smaller Blowfish-like "non-crypto" cores (not actual Blowfish), so that we could hopefully fit hundreds or thousands of those per chip (and have them somewhat CPU-unfriendly as well). Yuri, our GSoC 2011 student working on this project, did have some of this implemented in an experimental fashion, and some of it even worked (on FPGA boards kindly provided by Pico Computing), but an outcome of the summer project was that this would be time-consuming to bring to desired levels of performance and reliability. At that point, the project was put on hold.

A simpler and cheaper alternative (if there are only a handful of customers for this) may be to use dedicated servers, existing HSMs, or microcontrollers for just the password hashing. Indeed, microcontrollers are super slow, so their only function would be to hold and apply a local parameter, with the rest of the hashing method implemented on the host's CPU and RAM. If dedicated servers are used, they would need to be separate from authentication servers - that is, they won't know usernames, won't have access to any database, won't have any persistent storage except for the local parameter, and the OS and software indeed. They will accept password, salt, and parameters (such as the configurable per-hash processing and memory cost settings), and provide the hash. Thus, their attack surface would be minimal and they'd provide an extra layer of security against network-based attacks. We'd do this with FPGA boards as well, and we'd also have the greater/unusual computational complexity as a security layer (in case the local parameter or its backup copy is leaked/stolen), but well - using typical and pre-existing server hardware, drivers, etc. is just simpler and cheaper unless we start a new business and expect to have plenty of customers (although that might be possible).

The existing password hashing methods won't run on GPU well for user authentication, even when they do run well for cracking passwords. They lack sufficient parallelism within one hash computation. This is an issue I first raised in 1998, in pre-GPU context (it applies to recent CPUs as well, and the problem is getting worse with time).

A solution is to define a new password hashing method with sufficient (configurable) parallelism within one instance. We could then consider running it on GPU, unless it is GPU-unfriendly by other criteria. Do we really want to, though? GPUs in servers are not yet common, except in computing clusters. Their reliability may be lower than that of other typical server components. The drivers are currently relatively unreliable as well (although they may be reliable enough if running the same code, with no upgrades). Sure, computing clusters use them anyway, and get them to run reliably enough for their needs, but the extra hurdle and/or risk is there. Will we get embedded GPUs in typical servers soon? Will they be similar to current gamers' or HPC GPUs or not? This is not clear. Then there's Intel MIC, which delivers GPU-like performance, but is a lot closer to a CPU - it will require a lot of parallelism in the algorithm too, but it may run certain types of otherwise GPU-unfriendly code. Is this possibly a better target?

For current GPUs, a better strategy might be to make them inefficient - by using GPU-unfriendly hashes (for cracking, and for validation as well - as a side-effect).

We had a project last summer to research this kind of possibilities, focusing on use of FPGA boards in authentication servers. This could optionally buy us GPU-unfriendliness (if we want to make things more difficult for attackers with GPUs, but not FPGAs, and for botnets, which almost surely will lack FPGAs). We even considered some moderate CPU-unfriendliness of the component that we'd put on FPGA. Specifically, we experimented with bcrypt on FPGA, as well as with much smaller Blowfish-like "non-crypto" cores (not actual Blowfish), so that we could hopefully fit hundreds or thousands of those per chip (and have them somewhat CPU-unfriendly as well). Yuri, our GSoC 2011 student working on this project, did have some of this implemented in an experimental fashion, and some of it even worked (on FPGA boards kindly provided by Pico Computing), but an outcome of the summer project was that this would be time-consuming to bring to desired levels of performance and reliability. At that point, the project was put on hold.

A simpler and cheaper alternative (if there are only a handful of customers for this) may be to use dedicated servers, existing HSMs, or microcontrollers for just the password hashing. Indeed, microcontrollers are super slow, so their only function would be to hold and apply a local parameter, with the rest of the hashing method implemented on the host's CPU and RAM. If dedicated servers are used, they would need to be separate from authentication servers - that is, they won't know usernames, won't have access to any database, won't have any persistent storage except for the local parameter, and the OS and software indeed. They will accept password, salt, and parameters (such as the configurable per-hash processing and memory cost settings), and provide the hash. Thus, their attack surface would be minimal and they'd provide an extra layer of security against network-based attacks. We'd do this with FPGA boards as well, and we'd also have the greater/unusual computational complexity as a security layer (in case the local parameter or its backup copy is leaked/stolen), but well - using typical and pre-existing server hardware, drivers, etc. is just simpler and cheaper unless we start a new business and expect to have plenty of customers (although that might be possible).

I've been using passphrases for about 12 years (and more than that if we count those passphrases on PGP and SSH keys as well), and I'm not growing out of it yet. I often use mixed-character-type passwords as well, and my phrases often use weird word separators, misspelled and/or partial words (less typing, same or better security if you do it right), different languages, etc. The number of words also varies (but with too few words other bits of complexity have to be introduced). For me, what is easier or harder to memorize varies depending on what kind of suitable idea I happen to have at a given time. Besides, the variety in password/phrase types buys me a few extra bits of entropy. Even an attacker who has read this comment or cracked a few of my passwords somewhere doesn't come up with one single pattern on password type that I use - because there are many. Thus, let your users choose between short but complicated passwords and longer but less complicated phrases. Similarly, let them choose between server-generated strings and user-chosen ones (the latter may be subject to policy enforcement). Our passwdqc tool set (PAM module, library, program for use from scripts) gives all of these options by default (but they can be disabled in any combination...) For server-generated strings, passwdqc uses 3-word phrase-like ones, with non-whitespace separators (out of a set of 8) and random word capitalization by default - that's 47 bits, which is currently sufficient in most user authentication contexts when used along with bcrypt hashes. With 4 words and the same approach, it's 64 bits ("pwqgen random=64" will do that) - but that is rarely needed with a decent password hash. (It is reasonable for data encryption keys, though - plus some 20 bits of stretching with a decent KDF.)

I am all for passphrases. We've been supporting them in our passwdqc password/passphrase strength checking and policy enforcement tool (initially just a PAM module, then more) since I wrote it in 2000.

Implementation detail: when enforcing passphrase policy, we need to insist on some separators between words being present. passwdqc does, in order for the string to quality as a passphrase rather than password. Apparently, Dropbox does not, and I think that's a flaw. No wordlist can be comprehensive, and a separator-less passphrase is indistinguishable to a password/passphrase strength checker from a long and somewhat obscure dictionary word. Indeed, any passphrase (or a multi-word portion of it) can happen to be found in a dictionary (or on the web, etc.) as well - or just be reused by the user across multiple sites - but that's a somewhat different issue.

The design of PBKDF2, and the NIST publication you referenced, do not consider the difference in processing cost to defender vs. attacker, whereas that is precisely the aspect I've been focusing on in my analysis. PBKDF2 does nothing to bring the validation vs. cracking speed ratio close to 1.0.

Reposted from OSS-Security: http://www.openwall.com/lists/oss-security/2012/05/04/18

Hi,

I guess most of you have heard of this one already, yet it should be in here as well. The original issue was tracked as CERT VU#520827, CVE-2012-1823. PHP 5.4.2 and 5.3.12 were released with an incomplete fix, and apparently CVE-2012-2311 refers to that incomplete fix issue.

http://www.php-security.net/archives/11-Mitigation-for-CVE-2012-1823-CVE-2012-2311.html
http://www.kb.cert.org/vuls/id/520827
http://www.reddit.com/r/PHP/comments/t3pr8/how_serious_is_this/
http://www.reddit.com/r/netsec/comments/t4lxw/phpcgi_query_string_parameter_vulnerability_leads/
http://www.metasploitminute.com/2012/05/cve-2012-1823-php-cgi-bug.html
http://www.opennet.ru/opennews/art.shtml?num=33765 (in Russian)

Alexander

Yes, there are quite a few things to keep in mind for password hashing, when it comes to cryptography and hashing, it's always best to go with solutions which have been thought up by people who are properly familiar with the subject. Only fools try think up their own scheme and don't get it critically reviewed by peers first.

I use this for my PHP projects:
http://www.openwall.com/phpass/

I'm not clever enough to know for sure it's sound, but I am fairly confident it is based on the technical explanation on the website.

Do admins get more hardcore than that administer key servers like Kernel.org's, RedHat's, Debian's ?

Yeah, they do. Such as Open Wall Linux Project, spearheaded by one Solar Designer.

Do you really think the state of programming was so bad back then that people wouldn't test 129 byte strings?

I think the state of programming is so bad now that people wouldn't test it. A major security bug in Blowfish was just found last month caused precisely because of a signed/unsigned char mismatch.

Another problem with C. It does not natively define a 8-bit datatype so people use the char type when they need an 8-bit value.

Dealing with NUL is significantly simpler than dealing with length fields, and there are significantly fewer sources for confusion.

Is it, or are you just used to dealing with NUL-terminated strings?

If you wanted the standard to use a variable-length length as you suggest, you would need to make sure that all the programmers correctly store and parse variable-length strings. Of course they could get it right, but there are lots of ways they could get it wrong.

That's what libraries are for :-)

Here's a question: How much memory do you allocate for a string of N bytes? The NUL-termination answer: N + 1. The answer for your mysql variable-length length scheme: N + (N < 128 ? 1 : N < 16384 ? 2 : N < 2097152 ? 3 : .....) -- yes there is a correct answer, but it is much more complicated for the everyday programmer to deal with.

Again I say: libc.

I think the state of programming is so bad now that people wouldn't test it. A major security bug in Blowfish was just found last month caused precisely because of a signed/unsigned char mismatch.

Heh, a fair point. But if string handling is done in a library by the developer of the OS, and they don't get it right, nobody's going to buy their OS. "Joe average" programmer doesn't have to do it at all, they just call the moral equivalent of strlen(), strdup(), strchr(), strbrk() etc.

Note that my post was not necessarily saying that NUL was the right decision. Just that it isn't a no-brainer -- going the other route has a lot of complications.

What is so undesirable about making a string larger than a pointer?

It would mean that the C library would need to declare a "string" struct instead of using char*. Now rather than passing a char* as an argument, you would have to decide whether it's worth passing the two word "string" struct, or a string* pointer (allowing it to fit into a register). It makes things more complicated.

Also, have a look at how mysql deals with varchars. There is no 255 byte limit - when length exceeds that value, you just go to 2 bytes of length, etc. Your arguments about what type of integer to use conveniently ignore conventions like network order. In short, it is not too hard to solve.

No, it isn't too hard to solve. But it is non-trivial. Dealing with NUL is significantly simpler than dealing with length fields, and there are significantly fewer sources for confusion. Remember that in C, programmers fabricate their own strings (there is a minimal string library, but often you will see people just allocating memory for strings, populating them, and storing a '\0' on the end). If you wanted the standard to use a variable-length length as you suggest, you would need to make sure that all the programmers correctly store and parse variable-length strings. Of course they could get it right, but there are lots of ways they could get it wrong. The same applies to NUL.

Here's a question: How much memory do you allocate for a string of N bytes? The NUL-termination answer: N + 1. The answer for your mysql variable-length length scheme: N + (N < 128 ? 1 : N < 16384 ? 2 : N < 2097152 ? 3 : .....) -- yes there is a correct answer, but it is much more complicated for the everyday programmer to deal with.

Do you really think the state of programming was so bad back then that people wouldn't test 129 byte strings?

I think the state of programming is so bad now that people wouldn't test it. A major security bug in Blowfish was just found last month caused precisely because of a signed/unsigned char mismatch.

Where did you stop reading?

The only security issues mentioned were buffer overruns, with gets taking most of the blame. As I said above, only some NUL errors are buffer overruns and only some buffer overruns are NUL errors, and gets errors are not anything to do with NUL.

AES-NI is definitely too specific to AES, not reasonably reusable for DES. Yes, we have achieved a speed for DES comparable to that of AES with AES-NI.

We're actually considering building a password hashing method on top of something like this, where bitslice DES has the advantage of being scalable to arbitrary SIMD vector widths and not requiring specialized instructions for efficient implementation. DES is also FPGA-friendly (more so than AES), and we have a project to implement password hashing for authentication servers equipped with FPGA boards:

http://www.openwall.com/lists/crypt-dev/2011/04/05/2 - project rationale
http://www.openwall.com/lists/crypt-dev/2011/05/09/1 - alternative approach

We're also considering Eksblowfish-like constructions, though - such as to make use of Xilinx Block RAMs (and thus require attackers to use more resources too).

BTW, not sure if I am speaking to the right Matt, but of the two SHA-crypt flavors the SHA-512 based one actually has a practical advantage over the SHA-256 one: more complete use of 64-bit CPUs in servers. So I think Dragonfly BSD's choice was a mistake. GPU implementations for both are being worked on, and the difference should be seen.

AES-NI is definitely too specific to AES, not reasonably reusable for DES. Yes, we have achieved a speed for DES comparable to that of AES with AES-NI.

We're actually considering building a password hashing method on top of something like this, where bitslice DES has the advantage of being scalable to arbitrary SIMD vector widths and not requiring specialized instructions for efficient implementation. DES is also FPGA-friendly (more so than AES), and we have a project to implement password hashing for authentication servers equipped with FPGA boards:

http://www.openwall.com/lists/crypt-dev/2011/04/05/2 - project rationale
http://www.openwall.com/lists/crypt-dev/2011/05/09/1 - alternative approach

We're also considering Eksblowfish-like constructions, though - such as to make use of Xilinx Block RAMs (and thus require attackers to use more resources too).

BTW, not sure if I am speaking to the right Matt, but of the two SHA-crypt flavors the SHA-512 based one actually has a practical advantage over the SHA-256 one: more complete use of 64-bit CPUs in servers. So I think Dragonfly BSD's choice was a mistake. GPU implementations for both are being worked on, and the difference should be seen.

We're getting close to an official fix, which includes a quick self-test on every use (not just by "make check"), with both 7- and 8-bit chars: http://www.openwall.com/lists/oss-security/2011/06/21/2

"Gawker used this broken implementation, which replaced all non-ascii characters with question marks prior to hashing". link

"Versions of jBCrypt before 0.3 suffered from a bug related to character encoding that substantially reduced the entropy of hashed passwords containing non US-ASCII characters.

"An incorrect encoding step transparently replaced such characters by '?' prior to hashing. In the worst case of a password consisting solely of non-US-ASCII characters, this would cause its hash to be equivalent to all other such passwords of the same length". link

Didn't anyone ever test the algorithm to see if if functioned as designed, as in producing unique hashs for very similar passwords. Would be most important as part of an encryption suite ..

The impact of this is actually pretty wide. Crypt_blowfish has been gaining popularity as a hashing algorithm in PHP thanks to Openwall's PHPass framework. Four years ago most PHP projects that I know were still using MD5 or SHA1 to hash passwords. Today those MD5 and SHA1 hashes can be brute-force cracked by free software running on a $200 GPU in a matter of days if not hours. So even a buggy version of Blowfish is still better by far.

So yeah, it's a wide-ranging bug but not a world breaking one. For starters it only affects passwords that use 8-bit characters, so passwords typed by anyone using a US-English keyboard still produce the same hashes as the correct Blowfish implementation.

For passwords of length n*4-1 (3, 7, 11, 15, ...), 8-bit characters in certain positions will result in some characters being ignored by the hash function. This makes it possible (though still not easy) to produce a collision, i.e. multiple different passwords that result in the same hash.

It's bad, but I want to stress that using even a buggy crypt_blowfish for password hashing is still a quantum leap over the single-hashed MD5 or SHA1 that you were seeing literally everywhere in the PHP world just a few years ago.

Thanks for making me laugh, but at a glance, it looks like the bug is actually in this package, not PHP.

If they don't store them plaintext, they still have to store a hash (MD5, SHA2, etc...). If they know the hash algorithm (which I'm sure they do if they got DB access), they could easily run a brute force attack on the hashes that will crack any weak passwords (which I'm sure many are). Even password hashes on Linux systems can be cracked if the passwords are weak and the attacker has time. See http://www.openwall.com/john/.

The solution to this is simple: just iterate the hash function many times so that the time to hash the password is (say) 300ms - unnoticeable to an interactive user, but significant for a brute force attacker. This is called password stretching, and is as important as salt.

See http://www.openwall.com/articles/PHP-Users-Passwords for a review of this and other password hashing issues - not just for PHP, this article gives the thinking behind phpass which is now used in Drupal, and has been reimplemented in other languages. phpass includes bcrypt() as an option but can work even with really old PHP versions that only have MD5. Just because MD5 and SHA1 have been cracked to some degree doesn't invalidate them for password hashing with salt and stretching.

Key derivation functions perform essentially the same operation as password stretching, see http://en.wikipedia.org/wiki/Key_derivation_function - there is an IETF RFC for this.

Digression: Windows 7 still doesn't use salted passwords, which is why it's so easy to crack Win7 passwords given the hashed password, using Rainbow Tables - see http://en.wikipedia.org/wiki/Ophcrack - try the vendor's scarily good online password hash cracker for yourself...)

Most importantly: don't even think of implementing your own crypto code unless the above is very old news to you, because you WILL get it wrong - the examples of unsalted and unstretched passwords are only the beginning. Instead, search for a credible crypto library in your chosen language, and if necessary write a C wrapper so that your preferred scripting language can access a good C/C++ library such as Crypto++ - http://www.cryptopp.com/

The initial dump from Gawker showed 188,281 cracked passwords out of 1,247,893 in the password database, or 15%. They were salted. A report from totse says "261459 password hashes cracked, 486643 left". I don't know how that user selected the particular hashes he was working on -- looks like ~70% of the ones that weren't cracked in the initial dump. John the Ripper dictionary attacker and brute-forcer is being used on the password file, but the CUDA cracker doesn't have this DES-based algorithm in it.

How "passwd" works with root group r-- and no SUID is a mystery to me, I'll have to look later.

Please take a look at our presentation slides, it only takes a few minutes. Then you might have more specific questions on the implementation, which I'd be happy to answer.

http://www.openwall.com/tcb/
http://www.openwall.com/presentations/Owl/mgp00020.html
http://www.openwall.com/presentations/Owl/mgp00021.html
http://www.openwall.com/presentations/Owl/mgp00022.html
http://www.openwall.com/presentations/Owl/mgp00023.html

... he was more experienced than me ...

Please note that what I wrote in my reply to your comment was quite different. I never said anything about your experience. Now that you raised this topic, I can say that you appear to be familiar with Unix security. You simply had not looked at our stuff before you wrote your comment, that's all.

I find your comment re: the cost of PIE interesting, thanks! It leaves many questions, though. 6% on 32-bit x86 is the number I had been aware of before. Your statement that "the affected code was actually running less than 2% of the time" is curious and potentially very useful. However, this, assuming that it's true, does not yield your claimed 0.0012%; it yields 0.12%. Of course, 0.12% may be considered acceptable (far more likely than 6% at least). I am curious about the details of your test; I guess, some systems will actually run "the affected code" 100% of the time - e.g., this happens if I build John the Ripper as PIE and run it for days (which is why I dislike Gentoo building JtR like that, and have to recommend JtR users to make their own builds). ;-) I'd appreciate it if you e-mail me (solar at openwall.com) more details on your test, and we'll discuss from there. We're considering PIE by default for post-3.0 Owl-current (and next release).

Your comments about cron/at are similar to what we thought of when we designed the system. Just like our per-user shadow files, the crontab files are per-user (and they were prior to our changes as well). Our crond does check crontab file ownership, and then it will only run the cron jobs found in the file as the file's owner. Cron and at jobs running as root are supported - of course, as long as the corresponding files are root-owned.

How "passwd" works with root group r-- and no SUID is a mystery to me, I'll have to look later.

Please take a look at our presentation slides, it only takes a few minutes. Then you might have more specific questions on the implementation, which I'd be happy to answer.

http://www.openwall.com/tcb/
http://www.openwall.com/presentations/Owl/mgp00020.html
http://www.openwall.com/presentations/Owl/mgp00021.html
http://www.openwall.com/presentations/Owl/mgp00022.html
http://www.openwall.com/presentations/Owl/mgp00023.html

... he was more experienced than me ...

Please note that what I wrote in my reply to your comment was quite different. I never said anything about your experience. Now that you raised this topic, I can say that you appear to be familiar with Unix security. You simply had not looked at our stuff before you wrote your comment, that's all.

I find your comment re: the cost of PIE interesting, thanks! It leaves many questions, though. 6% on 32-bit x86 is the number I had been aware of before. Your statement that "the affected code was actually running less than 2% of the time" is curious and potentially very useful. However, this, assuming that it's true, does not yield your claimed 0.0012%; it yields 0.12%. Of course, 0.12% may be considered acceptable (far more likely than 6% at least). I am curious about the details of your test; I guess, some systems will actually run "the affected code" 100% of the time - e.g., this happens if I build John the Ripper as PIE and run it for days (which is why I dislike Gentoo building JtR like that, and have to recommend JtR users to make their own builds). ;-) I'd appreciate it if you e-mail me (solar at openwall.com) more details on your test, and we'll discuss from there. We're considering PIE by default for post-3.0 Owl-current (and next release).

Your comments about cron/at are similar to what we thought of when we designed the system. Just like our per-user shadow files, the crontab files are per-user (and they were prior to our changes as well). Our crond does check crontab file ownership, and then it will only run the cron jobs found in the file as the file's owner. Cron and at jobs running as root are supported - of course, as long as the corresponding files are root-owned.

How "passwd" works with root group r-- and no SUID is a mystery to me, I'll have to look later.

Please take a look at our presentation slides, it only takes a few minutes. Then you might have more specific questions on the implementation, which I'd be happy to answer.

http://www.openwall.com/tcb/
http://www.openwall.com/presentations/Owl/mgp00020.html
http://www.openwall.com/presentations/Owl/mgp00021.html
http://www.openwall.com/presentations/Owl/mgp00022.html
http://www.openwall.com/presentations/Owl/mgp00023.html

... he was more experienced than me ...

Please note that what I wrote in my reply to your comment was quite different. I never said anything about your experience. Now that you raised this topic, I can say that you appear to be familiar with Unix security. You simply had not looked at our stuff before you wrote your comment, that's all.

I find your comment re: the cost of PIE interesting, thanks! It leaves many questions, though. 6% on 32-bit x86 is the number I had been aware of before. Your statement that "the affected code was actually running less than 2% of the time" is curious and potentially very useful. However, this, assuming that it's true, does not yield your claimed 0.0012%; it yields 0.12%. Of course, 0.12% may be considered acceptable (far more likely than 6% at least). I am curious about the details of your test; I guess, some systems will actually run "the affected code" 100% of the time - e.g., this happens if I build John the Ripper as PIE and run it for days (which is why I dislike Gentoo building JtR like that, and have to recommend JtR users to make their own builds). ;-) I'd appreciate it if you e-mail me (solar at openwall.com) more details on your test, and we'll discuss from there. We're considering PIE by default for post-3.0 Owl-current (and next release).

Your comments about cron/at are similar to what we thought of when we designed the system. Just like our per-user shadow files, the crontab files are per-user (and they were prior to our changes as well). Our crond does check crontab file ownership, and then it will only run the cron jobs found in the file as the file's owner. Cron and at jobs running as root are supported - of course, as long as the corresponding files are root-owned.

How "passwd" works with root group r-- and no SUID is a mystery to me, I'll have to look later.

Please take a look at our presentation slides, it only takes a few minutes. Then you might have more specific questions on the implementation, which I'd be happy to answer.

http://www.openwall.com/tcb/
http://www.openwall.com/presentations/Owl/mgp00020.html
http://www.openwall.com/presentations/Owl/mgp00021.html
http://www.openwall.com/presentations/Owl/mgp00022.html
http://www.openwall.com/presentations/Owl/mgp00023.html

... he was more experienced than me ...

Please note that what I wrote in my reply to your comment was quite different. I never said anything about your experience. Now that you raised this topic, I can say that you appear to be familiar with Unix security. You simply had not looked at our stuff before you wrote your comment, that's all.

I find your comment re: the cost of PIE interesting, thanks! It leaves many questions, though. 6% on 32-bit x86 is the number I had been aware of before. Your statement that "the affected code was actually running less than 2% of the time" is curious and potentially very useful. However, this, assuming that it's true, does not yield your claimed 0.0012%; it yields 0.12%. Of course, 0.12% may be considered acceptable (far more likely than 6% at least). I am curious about the details of your test; I guess, some systems will actually run "the affected code" 100% of the time - e.g., this happens if I build John the Ripper as PIE and run it for days (which is why I dislike Gentoo building JtR like that, and have to recommend JtR users to make their own builds). ;-) I'd appreciate it if you e-mail me (solar at openwall.com) more details on your test, and we'll discuss from there. We're considering PIE by default for post-3.0 Owl-current (and next release).

Your comments about cron/at are similar to what we thought of when we designed the system. Just like our per-user shadow files, the crontab files are per-user (and they were prior to our changes as well). Our crond does check crontab file ownership, and then it will only run the cron jobs found in the file as the file's owner. Cron and at jobs running as root are supported - of course, as long as the corresponding files are root-owned.