Implementation should use a popular accepted and portable method (Joomla, Wordpress, Drupal, ..) to keep Flyspray easy to integrate with other software instead inventing: http://www.openwall.com/phpass/

Edit: Did some research ..The original Software on openwall.com is not updated for a few years, but was base for different following developments:

I'd really have to +1 PBKDF2/bcrypt support- even salted sha256/sha512 would be WORLDS better than plain MD5, and bcrypt especially is already seen as a rather good method of storing passwords. Between the collision and just plain ease of cracking/bruteforcing MD5 (on that note, it seems the login maxes out on 30 chars for a password), MD5 is no longer a viable option, unfortunately.

Is there a reason you'd want to use the same scheme as those CMSes? If you're looking for interoperability, most of those listed (all, I think) support authentication APIs instead, which I'd imagine would be ideal as it cuts down on backend maintenance overhead (if you're going to use unified logins, the backend should only change a password in one place and all places should look to that for authentication). However, I'd say worry about that bridge when it comes to it- when you have the code ready to integrate into outside services, THEN worry about interoperability.

If you wish to not break old passwords, a simple solution can be found via the way dovecot handles passwords in SQL- there is a default scheme in the configuration for dovecot, which it will try to use if no specifier is found. However, a scheme can be applied via a specifier.Let me provide an example. Let's say your dovecot uses SHA512-CRYPT as the default in a new update (and previously used MD5-CRYPT), but you still have some users that have not yet updated their password (and thus switched over to the new default password scheme), and are still using MD5-CRYPT.

user2 is using the new SHA512 scheme, whereas user1 is still using MD5-CRYPT (old passwords can be prefixed via something like "UPDATE mailbox SET password = CONCAT("{MD5-CRYPT}", password) WHERE password LIKE '$1$%';").(Alternatively, the inverse could be done- the new passwords could be prefixed as {SHA512-CRYPT} and the old passwords non-prefixed, and the default in the configuration kept as MD5-CRYPT.) (By the way, both of those strings evaluate from "password" if you're curious.)

I imagine a similar method could be done here, as it easily allows multiple hashing schemes in the same table without breaking functionality for older hashes.

Lastly, but most importantly, I want to address this, as it struck a chord with me:"It is still on the wishlist, but not top priority, because it first requires the database or Flyspray is compromised/leaked or auth cookies are stolen."

I'm not sure if you're aware, but the vast majority of these leaks occur through SQL injection attacks. Would you be willing to vouch that Flyspray is 100% invulnerable to e.g. MySQL injection attacks, and will remain so in the future? If so, can I get that in writing? Because that'd be remarkably impressive. Strong salted hashes for passwords aren't put in place because the surrounding security is weak; they're there as a contingency plan in the event that an unknown vulnerability exists (and they always do, in varying degrees). At the *very* least it gives users enough time to change their passwords following news of a compromise were one to happen. (Plus let us not forget the "disgruntled employee" situation, etc.- not even administrators should be able to know what a user's password is. In fact, PCI compliance requires this.)

I apologize for the diatribe, but I really think this feature request is immensely important and I don't want to see it downplayed or delayed in lieu of other factors. It's a dangerous world out there, and if you can make it a little safer for your users, I highly suggest doing so. I do hope this helps.

Using a 6-8 char salt with SHA256 or SHA512 should be plenty, if you're worried about known/proven/tested. However, bcrypt is in use in many places already (and has been around for 11 years). I'd highly recommend it (as it is ever so slightly stronger than PBKDF2); https://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage goes into the gritty details as to why- basically, "it's very expensive in time to crack unless you have an FPGA, which are still rather expensive in cost"; it tends to be recommended over PBKDF2 because of its resilience against GPU-centric attacks (which are *much* more cheap in cost and prevalent). Wordpress (for instance) is currently working on adding support for it as well: https://core.trac.wordpress.org/ticket/21022 (Most of *their* deliberation is how to continue, if at all, to support users installing newer versions of Wordpress and then downgrading from PHP 5.3.7+ to PHP 5.2, which is itself ancient- so I wouldn't worry about it terribly much.)

I hope this helps! If you have any questions or have ways you think I might help, do feel free to let me know!

From a personal project of mine, I implemented it this way (though keep in mind I'm far from a web developer, so I bet there is a more elegant way of doing this). Note that $salt is generated outside (if one is specified- I recommend it), and it only does 10 rounds so it isn't ideal. See https://secure.php.net/manual/en/function.password-hash.php for more information (notably, PASSWORD_BCRYPT).

The DB's varchar for password WILL need to be extended to (at least) 60, however (I believe you currently have it set as 40), which can be handled via the setup script for upgrades. Since it's varchar, though, it should still be able to hold MD5 checksums as well (especially with the {MD5} etc. method I specified earlier).