Encrypt PM's and Specific Profile Fields for Account Recovery

[thecoalman]

Encryption of Specific Profile Fields For Account Recovery

One of the issues with the password reset is when a member has lost their email account. Determining if they are the actual user becomes impossible. An Admin can add some profile fields like a secret question and answer or phone numbers but this could potentially expose data the user does not want exposed if there is breach of the server.

If there was option to upload a public key to encrypt those fields they could then be accessed on demand with a private key which of course would not be on the server.

Encryption of PM's

I understand this is a very difficult proposition and some of the difficulties are outlined here:

viewtopic.php?f=496&t=2385721

Correct me if I wrong because encryption is not my strong suit. Generate an encrypted key that will be used to decrypt the PM's. The encrypted key will be decrypted with the password, on password reset regenerate the encrypted key so it will accept the new password.

To avoid issues with password loss could they not be encrypted to accept both the users key and the Admins public key I mentioned above? The admin could recover the PM's for a member if they lose their password. This could be an option the member could set in the UCP with a warning about permanent loss of the PM's if it's not enabled.

[2600]

I'm thinking something like a 2FA could help regain account control. There is a request here for 2FA and I support that.

[thecoalman]

Using third parties like Facebook, Google or whatever may be very useful for forums that have a younger and/or technologically adept crowd. My user base is older, likely to not be computer savvy and there is good chance they will not have Facebook etc. Forums with a user base like mine need a local solution like the one I'm describing.

[thecoalman]

One other thing I should mention here, I realize this is not 100% secure e.g. if a script is compromised the password or private key can be intercepted. What I'm suggesting is just an improvement over what currently exists that makes compromises for usability.

Options for generating private keys client side and using JS to decrypt client side would be secure but that obviously is much more involved.

[CHItA]

If there was option to upload a public key to encrypt those fields they could then be accessed on demand with a private key which of course would not be on the server.

I don't really understand how this would work. Do you mean the values should be encrypted with the admin's public key, so he/she could validate the identity of the board member?

Correct me if I wrong because encryption is not my strong suit. Generate an encrypted key that will be used to decrypt the PM's. The encrypted key will be decrypted with the password, on password reset regenerate the encrypted key so it will accept the new password.

To avoid issues with password loss could they not be encrypted to accept both the users key and the Admins public key I mentioned above? The admin could recover the PM's for a member if they lose their password. This could be an option the member could set in the UCP with a warning about permanent loss of the PM's if it's not enabled.

This wouldn't really add much security (depending on the strength of the user's password), and would add a large amount of duplicated data (each PM has to be stored with the admin's encryption key, each recipient's key and possibly the sender's key - assuming you want to be able to read back outgoing PMs). Generating that many copies seems to be a high price to pay for not much added security.

So this IMHO would be better of as an extension than anything.

[thecoalman]

I don't really understand how this would work. Do you mean the values should be encrypted with the admin's public key, so he/she could validate the identity of the board member?

Correct, once encrypted the user would only have the option of resetting those fields. They would not be able to read them. For example suppose they provided a phone number, the admin would be able to decrypt it and call them.

The private key would not be stored on the server thus preventing any possibility of those values being compromised. Correct me if I'm wrong but you can use JS so the admin can use the private key to decrypt client side.

This wouldn't really add much security (depending on the strength of the user's password), and would add a large amount of duplicated data (each PM has to be stored with the admin's encryption key, each recipient's key and possibly the sender's key - assuming you want to be able to read back outgoing PMs). Generating that many copies seems to be a high price to pay for not much added security.

So this IMHO would be better of as an extension than anything.

I realize what I have suggested is not 100% secure. Truly securing them is problematic but I think that is something phpBB should work towards.

If you were to consider truly securing them the one suggestion I have proposed that should be kept is user option to allow the admin to decrypt them in the event of loss of their key.

[CHItA]

I realize what I have suggested is not 100% secure. Truly securing them is problematic but I think that is something phpBB should work towards.

If you were to consider truly securing them the one suggestion I have proposed that should be kept is user option to allow the admin to decrypt them in the event of loss of their key.

PMs are secured by trying hard to not having security vulnerabilities in the core system, and by requiring authentication as the user to read the PMs that were sent to a specific user. These seem to me as fairly sufficient security measures.

Otherwise the crypto said of this is fairly tricky. The cleanest way to implement this functionailty is what is described in the topic that has been linked above, which is still tricky to implement. So in my view there is very little chance of this feature being implemented/accepted to the core.

[thecoalman]

PMs are secured by trying hard to not having security vulnerabilities in the core system,

I very well aware of the tremendous record phpBB3 has where security is concerned. In fact as a member of many other forums for website owners when I see such comments mentioning it's lack of security I smell blood.

Neither of these things have anything to do with that. The intention is to secure them if the server is compromised, when the database on phpBB.com was hacked it wasn't because of the lack of security in phpBB itself. phpBB has a very wide audience and some forums may be dealing with very intimate details like health. It's always been my opinion you need to protect the user from themselves. A "private message" should be private and personal information should be secured as much as possible.

Otherwise the crypto said of this is fairly tricky.

Understood but the encrypted profile fields should not be that difficult. I probably should of made this two separate suggestions.

[CHItA]

I agree that there could be usecases where this functionality is actually could be valuable (though in those cases it probably should be implemented in a way that is actually secure), however, I think that most boards do not need this functionality, therefore both of these should rather be extensions (in 3.3. it will be easier to install extensions from the ACP), and not a part of the core.

[thecoalman]

I think that most boards do not need this functionality,

We'll have to disagree about this. My opinion is that it's not matter of if you should protect user data but if you can. If you can then you should.

As far doing this as an extensions the encrypted profile fields is adding additional functionality for account recovery and easily abandoned if the extension is no longer supported. PM's would be a whole other matter. Without the means to back out of it or the knowledge there is continued support from phpBB it's not something I would consider installing.