0

I oversee a proprietary CMS with a headless Drupal back-end. We use Drupal to authenticate users, manage permissions and roles, and store HTML for almost 13, 000 pages. As our needs have grown, our custom code base has expanded, and Drupal's role in the project has diminished. Most of the app logic is now handled by a Node.js Express server. The Express app has access to the Drupal database and is already performing some read operations on Drupal tables.

I'd like to start migrating some features off of Drupal and onto the custom app. The one I'm most concerned about is authentication.

Authorization is currently setup as follows. User visits a non-Drupal app landing page. Submits username and password to the Express app, the app uses Drupal's rest login to check for a successful logon. If successful, the app uses standard Express practices to create a session and hand out a cookie.

I'm hoping that the express app can start checking passwords in the database directly, instead of using the Drupal API. I'd prefer that my users not have to reset their passwords and I'd prefer not to disrupt some relationships i have built with the Drupal user tables. In summary, my questions are these:

  1. How can i check that the hashed password in the DB matches the password submit by the user?

  2. Is the salt value in the settings.php file the one used encrypt passwords in the database or is that salt value somewhere else?

2a. NEW QUESTION: According to the Drupal Docs an unique salt is generated for every user and store in the database, possibly concatenated with the hashed password. Where are these unique salts stored and if they are concatenated with the hashed password, how can I separate them from the salted password? Are the salts concatenated on the end of the hashed password or the beginning. Are they always the same length? What is that length?

  1. What algorithm or module does Drupal use in combination with the salt value to created hashed passwords?

  2. If find the algorithm and salt values is it likely that this system is portable to node.js or are there php or Drupal idiosyncrasies that would prevent a migration.

Thank you in advance for you consideration. I realize it's a little tacky to ask questions about moving off of Drupal, but I'm still a big fan of the platform and the community. It's been very good for our operation.

Tony

Improve this question
7
  • I've had a number of these questions myself. Hopefully someone has some answers. – Jaypan Feb 25 '20 at 4:17
  • @Jaypan The answer to this other question, answers #2 & #3. – No Sssweat Feb 25 '20 at 9:00
  • Thanks, @no-sssweat. So, the salt in the settings file is not for user passwords. User passwords each get a unique salt that is stored along with the password in the database. In light of this I've updated the original question with a 2a question. – Tony Stecca Feb 25 '20 at 21:07
  • If you look in /core/modules/user/src/Form/UserLoginForm.php line 203 $uid = $this->userAuth->authenticate($form_state->getValue('name'), $password); this is how Drupal checks if the user name and pass is valid. So have a look at the UserAuth::authenticate method and keep going down the rabbit hole. – No Sssweat Feb 25 '20 at 23:20
  • Also have a look at PhpassHashedPassword::check might be what you need. – No Sssweat Feb 25 '20 at 23:35
0

A long time ago, I had to move from one system to another and there was a similar concern about migrating hashed passwords. I set up things to check for a password in the new system. If one exists, authenticate against it. If not authenticate against the old system, as it seems you're already doing with Drupal. However, instead of just handing out the cookie, use the opportunity to store whatever was sent in the new system, or physically take the user to a "verify your password" in the new system, and get it saved properly there.

Improve this answer
2
  • 1
    That's true. The user is giving you their password when the authenticate. You could take the password and encrypt it under the new system. When they attempt to authenticate you could check for the new one but fall back to the old one. Once all the users have logged in once the old system would be redundant and you could decommission it. That would work for me. I have a moderate number of users that all log in frequently. Is this kind of what you mean? – Tony Stecca Feb 26 '20 at 3:06
  • Precisely what I meant. – beltouche Feb 26 '20 at 3:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.