2FA for future upgrades?

Are there any plans on integrating 2 factor authentication in pkp library or OJS? Concerning the (apparently) growing attacks on journals, stronger authentication methods might be a good idea. While SMS based services come at a cost, FIDO’s U2F method will only generate costs once for users (~$10 and up). Those keys can also be used to login into other services and even some systems. Chrome and Opera already natively support it, Microsoft is part of the consortium and working on integrating it into Windows 10 and Edge and there’s a Firefox plugin to support U2F.

There’s library provided on github under BSD license by the original developers and even Wordpress supports it by now.

see following links:
Fido Alliance
Ars Technica article
Discussion on NIST denouncing SMS 2FA

In my opinion there’s no way past 2FA to strengthen OJS’s security.

Hi @dtwardy,

This is a good idea, but I’ll admit to not having given it much thought yet. Perhaps @ctgraham has something percolating in the back of his brain?

Alec Smecher
Public Knowledge Project Team

Personally, I think our goal should be to disassociate ourselves as much as possible from the credential collection of traditional authentication. We can pass authentication off to those who can handler 2FA, such as OAuth, OpenID, and Shibboleth providers.

Well, I get it that authentication is a sensitive field and it takes a lot of effort to keep it safe and to fix bugs as fast as possible so relying on other services is attractive. But imho relying on big providers using OAuth or OpenID comes at a cost as you have to connect your profiles and therefore giving data gathering companies even more information. I don’t see public institutes in Europe to use Google Accounts or similar. Would be a tremendous data privacy issue. And while Shibboleth is being used by many universities, combining those services is sometimes not possible for non-institutional clients.

Maybe 2FA using code generators is an easier approach. OJS just needs to offer a QR code to be scanned with a code generator app and it gives you automatically temporarily limited codes. Emails would be less secure when received on the same device so code generators should be more secure. And in addition you’d make it harder for spam users to register.

U2F is a very interesting approach though since that key is quite cheap and could be used to access password managers as well (i.e. Dashlane and I think also 1password) and it’s already supported pretty well.

I recognize that we will be stuck continuing to manage local authentication because not everyone can find an appropriate and acceptable form of linked authentication.

Can you describe more about the concerns of data privacy raised by authentication via ORCiD’s OAuth or a Google OpenId? For the purposes of authentication and authorization, neither of these services exposes personally identifiable information without the express consent of the user, nor does it expose any activity based information, save for the action of the login itself.

True, but the information itself that a person is using that ID to identify itself in journal xyz is valuable information to create a more detailed profile. Those information can also be combined with the metadata provided by that journal. This might not be a problem concerning ORCiD since it is designed to offer a detailed academic profile, I’d be very careful relying Google services. For example we can’t even use Google’s Font API for data privacy reasons. Of course, it is a different scenario since fonts are always being loaded without user interaction.