I’m not sure what method of password storage is used here, but the assumption that some vulnerability in the DB or the webserver may expose data beyond the control of the phpBB software itself may not be out of order.
I have a few spare cycles if throwing bodies at a task like updating an encrypt method and modifying code to allow two password tables to exist (one for users that have not yet updated their PW and another table for users that have updated their PW) might help.
Any word if phpBB was the vector for the attack, or just the victim? In other words, if they got onto the server somehow and downloaded the database that’s different from phpBB being where the vulnerability is.
phpBB3 uses salted passwords. phpBB2 does not, which makes it more vulnerable to dictionary / rainbow attacks once the hashed content is retrieved.
I could find no info about it but there is a post on phpBB forums about it.
I guess the only info to glean from that thread is is that old passwords need to be updated with the latest encryption method.
I guess the way to do that without forcing everything to update their password is to simply add an encryption layer and store the doubly encrypted value instead of the old singly encrypted value.
old way
user enters pw > encrypt it > compare to encrypted to permit or deny access
new way.
encypt old encrypted pw store > new encrypted store
user enters pw > encrypt it > encrypt it again > compare to encrypted to permit or deny access
(BOB member since 2003-08-19)
(BOB member since 2003-08-19)