Protection against compromised accounts

[jonasraoni]

Problem

Given that attackers have many ways to attack an account, it makes sense to make the task more difficult.

Status

Currently we have these protections:

• Option to enable the captcha on login.
• Option to expire a session when sensible information is changed (e.g. IP)
• Our passwords are properly hashed and salted

Ideas

1. A very simple, but powerful measure is to send an email notification after logging into the account: "You've just logged in, if it wasn't you, your account might be compromised, change your password"

2. We can also include two-factor authentication methods:

• One-time passwords (OTP): https://github.com/search?q=otp+language%3APHP&type=repositories&l=PHP&s=stars&o=desc
• Email codes. For example Notion uses a passwordless approach, where temporary passwords are sent by email. It's a way to forward most of the security responsibility to the email provider.
• Use the browser API (https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)

3. Together with the captcha, the login can also be rate-limited to protect against brute-force attacks. I think we should include/integrate the https://github.com/ulsdevteam/pkp-betterPassword into the codebase.

4. If we store recent locations used by the user, it's possible to block (ask for an extra step, such as an email confirmation) attempts from unexpected locations.

5. Display active sessions (specially when there's more than a single one attributed to the same user!)

[marcbria]

More ideas:

• Account Lockout Policy: Temporarily lock accounts after N repeated failed login attempts (N could be a config param set by admins).
• Breached Password Checks: Validate user passwords against breach databases (e.g., Have I Been Pwned) and force resets if compromised.
• Alerts: Warn admins if a journal is getting too much attempts (ie: 20 by user / 100 by journal?) in a short period of time (in 15min?).

I think we don't need to implement 2FA inside OxS tools, as far there are nice third party projects just focused on this like:

• https://www.keycloak.org
• https://www.authelia.com

But maybe ensure OxS could work nicely with them and write documentation?

[asmecher]

The OpenID plugin (now in the plugin gallery) supports Keycloak; not sure about Authelia.

[asmecher]

I'm interested in many of these approaches, but IMO the pathway to supporting them is via better adoption of Laravel as a prerequisite. Starting with 3.5.0, we use Laravel for session and cookie management; @Vitaliy-1 has some work in progress to convert user management to Eloquent; and at some point we'll reach a level of adoption where we have to tackle/adopt bootstrapping and configuration. Somewhere along the line we'll be able to delegate login/logout/password change/2fa/OpenID/etc. to the Laravel ecosystem, which will considerably reduce our technical debt while opening a lot of possibilities. Building out our toolset in advance of that change will increase technical debt.

[almereyda]

The configuration case is handled in #8015

[mfelczak]

Hello @asmecher, to confirm that I'm following: is the plan atm to not add any new features to improve account security until we have Eloquent in place? Assuming that this is the case, what sort of timeline would we be looking at before some of the improvements identified here would be considered for inclusion? Are we looking at a 3.6 or 3.7 roadmap at this point?

[asmecher]

We should consider our options feature-by-feature -- I wouldn't prohibit improvements until Laravel/Eloquent is used for user accounts, for example. But we currently have a lot of platform tech debt in user/password/login/session management that I would like to delegate to Laravel, so further entrenching our tech debt around that stuff would be a strike against IMO.

[mfelczak]

In addition to the improvements identified above, I think we'd be well served to include the latest round of NIST recommendations, see e.g. a recent summary.

As a minimum, we should increase the minimum password length to 15 characters. We could also consider porting some of the features provided by the betterPassword plugin into core, specifically blocking weak passwords, temporarily locking-out accounts after N failed login attempts, and disallowing password re-use. Some of the other plugin features are no longer recommended as best practices, e.g. requiring special characters in passwords.

[mfelczak]

With respect to MFA, there are probably at least two types that we need to consider.

The first type would be built-in with our applications and would not require any 3rd-party integration, e.g. with Keycloak, OpenID. As I understand it, the large majority of OJS deployments will not have the capacity or resources to host a dedicated SSO solution.

Built-in support could include any/all of the following:

• an email code each time there is a login attempt to a privileged role (SA/JM/Editor)
• an email notification each time there is a login attempt from a different IP
• OTP as outlined in the original description

MFA authentication via mobile authenticator apps can also be supported directly within our applications without requiring deployment of a 3rd-party service, similar to the default feature set provided by other open source platforms, e.g. Mattermost, Nextcloud.

The second type of MFA would be provided by 3rd-party services that integrate with OJS, e.g. Keycloak, OpenID. To my mind, these are edge-case deployments rather than typical for our community and user base.

In a nutshell, OJS should support best practice features out-of-the-box, including strong account protection, regardless of whether users have installed additional plugins or are able to integrate OJS with 3rd-party services.

[mfelczak]

CC'ing @ctgraham as well for his input given his experience in this area.

[jonasraoni]

In the Indonesia event there were many people asking about how to protect their installations against hacking attacks, they have a lot of problems with cassino ads inserted into their journals, so I think we should provide good defaults out-of-the-box. I'd say that passwords were relegated to cryptographic salts, 2FA is a requirement.

But given that many users are not skilled enough to setup some types of 2FA (e.g. OTP), I think the defaults should be nice. The passwordless approach from Notion for example, is the most user friendly in my opinion, and of course, the user should be able to change the authentication method.

[asmecher]

@jonasraoni, I think a lot of those installs were deployed unsafely (e.g. files_dir in web root) and not kept up to date (vulnerable to old stored XSS issues). I do want us to improve our game around 2FA, encouraging stronger passwords, etc., but I don't think it'll resolve those kinds of issues.

(I sometimes review Youtube videos from third parties describing how to install OJS, and they very frequently put files_dir in the web root. In some language communities these videos are heavily relied upon.)

[marcbria]

A "security checklist" plugin could be a nice project for a hackathon... just saying. ;-)

[ctgraham]

My thumbs-up to the discussion here so far. The only thing I would like to add which I don't see already in the thread is that another goal should be integrating as much as possible with external authentication. Let Shibboleth, ORCID, Google, OpenID, etc. handle responsibility for the 2FA; others already do it and do it well.

[marcbria]

I am with Clinton. Actually my initial comment was already along those lines.

Of course, if there is energy and time, I would love to see 2FA techniques implemented in the core but I suspect that with the resources we have it will never be as good as specific tools (which are actually not that complicated to set up) or third party services (some of them not only free but also from public institutions).

[mfelczak]

I think we'll have to agree to disagree on this one 🙂 To my mind, this is the perspective of Institutional hosting that includes more technical staff and resources and is not representative of the majority of our user community, including journals that struggle with installation and maintenance of their OJS install, nevermind setup and maintenance of 3rd party SSO integrations. This is also not the approach adopted for WordPress, Mattermost, or Nextcloud which include built-in/plugin support for MFA and don't depend on 3rd party integrations.

[asmecher]

I would be equally happy to delegate 2fa support to Laravel's toolset. I think the key point is that we shouldn't be adding homebrew implementations to our stack.