Users registration and security in OJS 3.1?

Software Support
1

Hi,

We use OJS 3.1.1-1 at university of Bordeaux in France.
Our chief information security officer (CISO) has a few concern about the registration method of users in OJS.

  1. Self registration
    User completes a form with some required fields.
    Required fields are: First Name, Last Name, Affiliation, Country, Login, Email, Username, Password
    Not required fields is: Middle Name
    He has to agree to have his data collected and stored according to the Policy Statement to complete his registration
    He chooses a username and a password. Password needs to have at least 6 characters. There is no obligation to have a combination of lower/upper case, numeric/letter, special character
    Then he receive an email with a link to validate his email account.

Comment of our CISO:

  • 6 characters for a password is too low to have strong password. It would be also better to obligation to have a combination of lower/upper case, numeric/letter, special character
  1. Registration of a user by the manager or a person with an editor role
    To register a user, the Manager completes a form with some required fields which are not the same than for self registration.
    Required fields are: First Name, Last Name, Login, Email, Username, Password
    Not required fields is: Middle Name, Affiliation, Country, etc.
    The Manager choose the password or generate random password for this user.
    He can choose that User must change password on next log in and Send user a welcome email.
    If Manager choosed to send user a welcome email to user, the user receives an email with his username and his new password in “plain-text”

Comment of our CISO:

  • Same comment for the password pattern
  • It’s not logical that required fields are not the same than for self registration
  • It’s no secured to send a “plain-text” password by email to the user. It would be better to send to the user an email with a non-replayable link with a link to validate his email account like for self-registration.
  • User hasn’t the opportunity to agree to have his data collected and stored according to the Policy Statement to complete his registration and he should have it like for self-registration.
  1. Reset Password
    User completes a form with his email address and he receives an email with a link to reset his password.
    When he clicks on the link, he receives an email with his username and his new password in “plain-text”

Comment of our CISO:

  • It’s no secured to send a “plain-text” password by email to the user. It would be better to send to the user an email with a non-replayable link that allows him to complete a new password online
  1. Password Encryption
    I read this in OJS forum:
    Passwords will automatically be updated to a modern hash rather than the old md5 and sha1 hashes as they are used (or as new ones are created). The encryption option in config.inc.php is only relevant for legacy password hashes which haven’t been upgraded yet (because the user hasn’t logged in).

Questions of our CISO:

  • What is the modern hash method now used by OJS ?
  • How do we manage old account which haven’t been upgraded yet ? Do we have to keep in database their old encrypted password and possibly leave a security breach and do we have to wait they log in to change the encryption of their password with the new method ?

Thanks in advance for all your answers.
Best regards
Helene

2

Hi,
If you don’t have time to answer to all of my questions, could you give an answer to question number 4 ?
Thanks in advance.
Kind Regards.
Helene

3

Hi @hcl ! @asmecher and others were in a PKP Sprint event when your original message was sent and have only returned back home yesterday I think. I am sure you will get an answer to the questions. I have my own views on the matters, but since I am no representative of OJS it is better to leave the answering for PKP.

4

Hi @hcl,

User self-registration

  • 6 characters for a password is too low to have strong password. It would be also better to obligation to have a combination of lower/upper case, numeric/letter, special character

If you’re hosting several journals, go to the Administration area as Site Administration. It’s possible there to set a minimum password length.

We don’t currently enforce special characters etc. in the password, but if you want to add them, you can do so by adding the constraints to…

  • lib/pkp/classes/user/form/ChangePasswordForm.inc.php
  • lib/pkp/classes/user/form/RegistrationForm.inc.php
  • lib/pkp/classes/user/form/LoginChangePasswordForm.inc.php
  • lib/pkp/controllers/grid/settings/user/form/UserDetailsForm.inc.php

Editor registration of user

  • It’s not logical that required fields are not the same than for self registration

Affiliation and country are important fields, and a self-registering user will always know them, but a journal manager who is registering on a user’s behalf or editing a user imported from another source may not.

  • It’s no secured to send a “plain-text” password by email to the user. It would be better to send to the user an email with a non-replayable link with a link to validate his email account like for self-registration.

Plain-text passwords are almost never emailed, and in the case that they are, the user is forced to change the password upon next login. This makes it effectively the same as a one-time-use link, as you suggest. There are further improvements already filed for implementation: Improve password reset to use one-use, time-limited hash · Issue #2135 · pkp/pkp-lib · GitHub

  • User hasn’t the opportunity to agree to have his data collected and stored according to the Policy Statement to complete his registration and he should have it like for self-registration.

I assume this is related to GDPR? Privacy legislation like GDPR is as much about managerial/editorial policy as it is about software, and you are correct that currently manually adding a user does not require them to agree to the privacy policy. I would suggest emailing an invitation to a user to create their own registration rather than having the manager do it on their behalf.

Password reset

  • It’s no secured to send a “plain-text” password by email to the user. It would be better to send to the user an email with a non-replayable link that allows him to complete a new password online

As above.

Password encryption

  • What is the modern hash method now used by OJS ?

Recent releases of OJS use PHP’s password hashing functions. The supported algorythms are documented under crypt. Site-specific salting is permitted via a config.inc.php setting.

  • How do we manage old account which haven’t been upgraded yet ?
    Do we have to keep in database their old encrypted password and possibly leave a security breach and do we have to wait they log in to change the encryption of their password with the new method ?

The previous encryption algorithm isn’t “broken”, it’s just a less modern, less secure algorithm. The risk of it being breached is quite low. Because it is also a one-way hashing algorithm, it’s not possible to retrieve the password and re-hash it into the new algorithm. Instead, it’s necessary to wait until the user logs in, at which point the plain-text password is available to OJS and the password can be converted.

If you consider this a risk, you’d need to either delete all accounts that still use the old password algorithm, or set their password hashes to something meaningless, which would force them to use the password reset process.

Regards,
Alec Smecher
Public Knowledge Project Team

5

Hi @asmecher,

You know if OJS has a new feature or some news about special character in password or something like that?

I’m using OJS version 3.2.

Thank you!

6

Hi @cicerobcastro,

No – you can see the list of checks e.g. in the registration form ( lib/pkp/classes/user/form/RegistrationForm.inc.php) in the constructor. The ones related to passwords are:

$this->addCheck(new FormValidator($this, 'password', 'required', 'user.profile.form.passwordRequired'));
$this->addCheck(new FormValidatorLength($this, 'password', 'required', 'user.register.form.passwordLengthRestriction', '>=', $site->getMinPasswordLength()));
$this->addCheck(new FormValidatorCustom($this, 'password', 'required', 'user.register.form.passwordsDoNotMatch', function($password) use ($form) {
    return $password == $form->getData('password2');
}));

I.e., the password must be specified, must be at least the configured minimum length, and must match the password confirm field.

Regards,
Alec Smecher
Public Knowledge Project Team