Design Q about sending authentication information through a message queue

Question

I'm designing a webhook receiver to work with a third party (over whom I have no control). The third party sends events (HTTPS) on behalf of our users that are represented in our own database. It's difficult to tell from the event payload which user the event corresponds to, but the third party does have a system for specifying a username and password, and sending that information in the webhook event via Basic Auth. So we'd generate username/password, somehow convey that to our users, and ask them to set the username/password in the third party software. Note that this information would only be used for the webhook (which receives somewhat sensitive information, but does not return anything).

I'm wondering how best to handle authentication/authorization here. The third party has very limited retry capability, so my thinking has been:

1. instead of parsing the event data and saving the complex business entities to the database in the request, enqueue each event onto a message bus and handle in a worker
2. try to deploy the webhook receiver so that its only dependency is the message queue (SQS in my case).

However, I can't quite figure out how best to handle auth here. The simplest thing would be to just pass the Basic Auth headers over the queue with the event payload, and check them in the worker. Sending in plaintext seems kinda like bad practice, but on the other hand the consequences of leaking this don't really seem serious - there's very little incentive for an attacker to want to send malicious data to our webhook.

Another alternative would be to hash the username/password in the receiver, and save the hashed values in the database, and check they match in the worker. I'm a little reluctant to do this because our users are not very technically comfortable and I'd prefer to be able to read them out the password over the phone.

Would appreciate any advice here!