announce - [openwall-announce] How to manage a PHP application's users and passwords; JtR & OpenMP

[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 28 May 2010 03:45:41 +0400
From: Solar Designer <solar@...nwall.com>
To: announce@...ts.openwall.com
Subject: [openwall-announce] How to manage a PHP application's users and passwords; JtR & OpenMP

Hi,

This is to announce two items at once:

1. Last month, I wrote and submitted a lengthy article for the Month of
PHP Security (MOPS).  This article, entitled "How to manage a PHP
application's users and passwords", is now published on the MOPS website:

http://php-security.org/2010/05/26/mops-submission-10-how-to-manage-a-php-applications-users-and-passwords/index.html

In this article/tutorial, I will guide you through the steps needed to
introduce proper (in my opinion at least) user/password management into
a new PHP application.  I will start by briefly explaining
password/passphrase hashing and how to access the database safely.  Then
we will proceed through several revisions of the sample program.  We'll
start with a very simple PHP program capable of creating new users only
and having some subtle issues.  We will gradually improve this program
adding functionality (logging in to existing user accounts, changing
user passwords, and enforcing a password policy) and "discovering" and
dealing with the issues.  We will also briefly touch many related topics.

This article also serves as documentation on introducing phpass, our PHP
password hashing framework, into a PHP application.  A tarball and ZIP
archive with the article (HTML) along with sample programs is available
for download from the phpass homepage:

http://www.openwall.com/phpass/

The table of contents is:

Introduction
Password/passphrase hashing
	Salting
	Stretching
	Choice of the underlying cryptographic primitive
	phpass - the password/passphrase hashing framework for PHP applications
The database (and how to access it safely)
	SQL injections
		What SQL injections are
		How to deal with SQL injections
		Prepared statements with PHP and MySQL
	Employ the principle of least privilege
	Schema
The sample program is born
	How to create new users
	What if the user already exists?
	Avoid leaking server setup details
	How to differentiate MySQL errors
	The "Magic Quotes" issue
	Input filtering
How to authenticate existing users
How to change user passwords
How to enforce a password policy
	Future work
Timing attacks
Other related concerns
	Randomly-generated passwords/passphrases
	Randomness
	Resetting forgotten passwords/passphrases
	Online password guessing
	Denial of Service (DoS) attacks
	Password policy enforcement and usability concerns
	Challenge/response authentication
	Sessions
Licensing

That's it.  You may want to check out other material posted on the MOPS
website as well.

2. John the Ripper's implementation of OpenBSD-style Blowfish-based
crypt(3) hashes is being parallelized with OpenMP (which is readily
available with recent C compiler versions, including with gcc).  This is
expected to be made official with the next development release.
Meanwhile, there's a patch on the wiki:

http://openwall.info/wiki/john/patches

and here are benchmarks on 8-way x86-64 systems (Core i7 and Dual
quad-core Xeon):

http://www.openwall.com/lists/john-users/2010/05/08/1

and 32-way UltraSPARC T2 (quad-core, 8 threads per core):

http://www.openwall.com/lists/john-users/2010/05/16/2

The efficiency is very close to 100% (vs. multiple separate processes).
The quad-cores with SMT (Core i7 and UltraSPARC T2) show a 5.5x speedup
(over a single-process build/run of unpatched JtR 1.7.5).  The "true"
8-core system shows a 7.9x speedup.

An advantage of this approach is in its transparency and reliability -
JtR parallelized in this way works as usual, including the
interrupt/restore functionality (only one .rec file is created).
A drawback is that this has to be implemented per hash type (and it's
been implemented for just one hash type so far).

Implementation for specific other hash types may be considered,
especially in response to commercial demand (the resulting code will be
available to everyone, as usual).  Please let me know if interested.

Thank you for reading this far!

Alexander