How do I change my password with dbAuth

Get Help and Help Others
1

My project is using dbAuth for account management, I want to update the password change function, how do I do that?
I setup authentication from tutorial: Authentication | RedwoodJS Docs

1 Like
2

When you say “update the password change function” what do you mean? A way to let users change their password in their settings? Or change the way that the existing forgot/reset password logic works?

If you wanted to use the same code that Redwood does internally to create a salt/hashedPassword, you can use this codeblock:

const CryptoJS = require('crypto-js')
const salt = CryptoJS.lib.WordArray.random(128 / 8).toString()
const hashedPassword = CryptoJS.PBKDF2('password', salt, { keySize: 256 / 32 }).toString()

Where the string 'password' is the actual user’s password.

You can then store the hashedPassword and salt for the user. You should do this on the server side (in a service) so that the hashedPassword and salt are never available to the client.

3

Thanks @rob, I will try it

5

Hey @rob, is this still the recommended way to do this?

Thanks!

6

You mean that block of code up there? Yep! If you want to do it yourself, like in a Settings page, that works.

1 Like
7

I also see if we want to be more idiomatic we can also just import hashPassword directly from the source, making a full solution that promises to stay consistent with the dbAuth handler as follows:

import { hashPassword } from '@redwoodjs/auth-dbauth-api'
...
export const updateUserPassword: MutationResolvers['updateUserPassword'] =
  async ({ id, input }) => {
    requireChangeUserInfoAuth(id)

    const { newPassword } = input

    const [hashedPassword, salt] = hashPassword(newPassword)

    return db.user.update({
      data: {
        hashedPassword,
        salt,
      },
      where: { id },
    })
  }
1 Like
8

Oh yeah! I forgot we started exporting that directly! Yeah that’s even better. :slight_smile:

1 Like
9

yeah! :slight_smile: thanks as always for the help!

10

So is it safe to send the plaintext password from the client to the resolver where it’s hashed? HTTPS is great but I’m just wondering if this is an attack surface nonetheless.

11

Yup that’s what https is for. Just don’t log it on the api side or to send the password anywhere like to analytics services etc.

1 Like
12

Also there is no need to ever have the hashed password or salt in any of your sdl types. That way even if you query it it won’t be in the response. Also you can use Prisma omit to exclude those fields from any query.

2 Likes
13

to follow up on @dthyresson’s answer, i found this difficult to believe when i was first getting into all this — you can do a sanity check by looking at the network tab in devtools for any site when you log in, and you’ll see that it’s sending your password in plaintext over https

1 Like