cash wrote on 42515044-08-01

It would be a good time to redo password hashing when we up the requirement to PHP 5.3 since PHP added default implementations of Blowfish.

Also, this is not as easy as just adding library - we need to think through backward compatibility, forward compatibility for future changes in hashing, making this more pluggable, portability, Windows support, etc.

Milestone changed to Near Term Future Release by cash on 42515044-08-01

trac user sembrestels wrote on 42685890-08-24

For backwards compatibility we can:

• Reset all passwords and save new ones with the new hash algorithm.
• Rehash existing passwords with the new algorithm and hash twice new passwords (one with md5 and the other with the new algorithm).

trac user mrclay wrote on 42686786-09-05

1. Add new hash strategy (we have good options in 5.2--see below)
2. Add a second, wider password_hash column and start saving new hashes during log ins (store both)
3. Add admin process to disable legacy passwords (one way: removes the password and salt columns). The admin would then have the option to send every user without a new hash a customizable message with a reset pwd link.

cash, when BC issues would blocking the above steps?

Re: hash algos, Blowfish is ideal, but PBKDF2 with 10K iterations of sha256 is plenty secure. Plenty of libs out there that will do whatever's available and the algo is stored in the hash.

I'd prefer this not be pluggable; most attempts I see to "improve the hashing" usually add little security and could easily break something. I can see it now: "This plugin allows you to e-mail users their passwords by storing them with base 64 encryption" :)

cash wrote on 42687730-02-23

I want to store what hashing algorithm was used in hash field so that we'll have backward/forward compatibility.

The switchover strategy should really be a site decision. I would prefer something that works transparently for sites - all new users get the new hashes, anyone who changes a password gets the new hash, everyone else stays with the previous hash. We can offer a small plugin that forces the change for all users for those sites that want that.

trac user mrclay wrote on 42687755-02-12

Replying to cash:

I want to store what hashing algorithm was used in hash field

First char of all new hashes would be $, otherwise it's a legacy hash.

The switchover method you describe sounds reasonable to me.

I'd really like to solve this for 1.9. Plan is to use password_hash and, for PHP < 5.3.7, fallback to PhPass. A simple wrapper will sniff if the hash is for PhPass (begins with $2a$, $P$) or the newer library.

To add to above, at every login we can replace old legacy hashes with new ones.

Please can anybody say what the current status on this issue is? Thank you

How actual is this community entry?
http://community.elgg.org/discussion/view/1066345/changing-elgg-default-password-encryption-from-md5-reverse-compatibility-issues

This won't be in 1.9.X. It will likely go into 1.10.0.

Ok. thanks.
Is it possible to plugins to handle overwrite

generate_random_cleartext_password()
generate_user_password(...)

from

http://reference.elgg.org/master/users_8php.html

You can write a plugin that takes over user creation and authentication, but you can't override those specific functions with a plugin.

It is hard to do but I did a plugin to do it some time ago:
https://github.com/lorea/betterhash

In 1.10 let's at least take the 1st step of saving new hashes beside the legacy ones. If we can't finish full migration by 1.10 at least the later switch would have most accounts ready. /cc @ewinslow

PR #7495 for a start.

Happy to review any PRs

The PR I submitted just added a separate column for the new hashes. Having old and new hashes in the same column seems unwise to me, particularly if we're going to consider setting ElggUser salt/password as part of the public API (until 2.0 I hope) and allowing logins to use either hash.

With the new functions I don't see the benefit of keeping track of the hashing algorithm or exposing it to devs. It should be a black box and if devs want to tinker they can use password_get_info() to sniff the algo.

Decisions to make:

1. Do we remove legacy password/salt when the modern hash is saved (migration as users log in) or do we consider read access to password/salt as public API?
2. Do we offer a setting to force password resets whenever users try to log in without a modern hash.
3. Do we at least force password resets for admins?

I haven't looked at this yet, but I would say just as a matter of opinion:

1. yes, migration as users log in
2. yes, security conscious admin will want that. An inactive user could have a legacy hash sitting in the db forever and be a potential point of weakness.
3. yes

Closing this as #7594 is merged