I am developing a website and I would like to allow users to use XMPP for live chat. I would like users to have the option use an existing XMPP account if they wish and store their XMPP username and password with their other account details.

Obviously, there's a big issue with just storing passwords as plain text. Is two-way encryption sufficient here? I am just at a loss for a solution.

  • 2
    What do you mean by "sufficient"? What's your criteria for "sufficiency"? Without a precise, unambiguous, objectively measurable specification of what, exactly, you mean by "sufficient", you are more or less asking for opinions on what is or isn't "sufficient", and asking for opinions is off-topic. Oct 26, 2021 at 9:19
  • be ware that if you do it like this, you are potentially asking your users to violate the EULA of the chat program. Many EULAs state that the user is personal, and have some sort of lockout clause. at the least you would have to explain that this is a risk, and you need to explain that if your site is compromised their 3rd party chat account is also potentially compromised. Token exchange should be your prefered option
    – JoSSte
    Oct 26, 2021 at 20:34
  • Do you mean that you want to store passwords to repeat login operation and therefore hashing is not possible? Not using hashing is quite dangerous.
    – FluidCode
    Oct 26, 2021 at 21:11
  • 1
    I'll note that the security problems described in this question also plague any password manager which supports either cloud backup or multi-device sync. I suggest reading up on how password managers solve this problem; Reputable password managers are typically quite public about how they resolve these concerns.
    – Brian
    Oct 27, 2021 at 13:22

4 Answers 4


Your concerns are valid, and sadly external services don't always support desirable authentication options.

One possible method would be to encrypt the external service credentials using a key derived from your user's password with your service. When the user logs in to your service, you can decrypt the credentials and keep them in memory (with sufficient safety precautions to avoid swapping to disk etc.) while the user's session lasts. That way, the external password can only be used when the user has logged in, and database exports would be useless to hackers (at least regarding this facet.)

Of course, the user needs to trust you with their external password, as you would be able to easily store it somewhere else when they log in, and use it later for some mischief.

The devil might be in the details, so this is just an idea that you need to flesh out within the constraints of your application.

  • 2
    The external service is a red herring. If you're storing something that can be reliably turned into the user's password, you're storing their password. Storing their password in an encrypted manner that relies on an oracle to decrypt doesn't mean you're not storing their password, just that you've given yourself an extra hoop to jump through when it's convenient to have. The password is still stored in your DB; while the key is (theoretically) unique per-user, it's highly likely to be a really weak key for most users. At best, this buys a little obscurity, which isn't security at all.
    – minnmass
    Oct 26, 2021 at 19:29
  • 1
    I would simplify: Any form of coding you have that will result in a clear text password will be compromised if your server is compromised. don't do it!
    – JoSSte
    Oct 26, 2021 at 20:35
  • @minnmass saying the key is likely really weak, isn't that just the same as saying their 3rd party password is likely really weak. If they choose a weak key for your service wouldn't they choose a weak key for their service? Oct 27, 2021 at 2:37
  • The (additional) problem I would see with this is that the encryption may protect against a quick data theft break in. But if your service gets compromised for a long enough time - and depending on the service a couple hours might suffice - then for all users that logged in during that time, the other account is compromised too, as the attackers can snoop out the password they have on your service and then decrypt the other one. But on the other hand, that's a risk you won't fully eliminate, it's in the concept of being able to operate on their behalf on the 3rd party service. Oct 27, 2021 at 2:41
  • 1
    After some data collection I have determined that the userbase does not have a significant number of existing XMPP accounts to make this feature even beneficial, so in the end I will simply be creating an account for them on the local XMPP server.
    – Leo Grün
    Oct 27, 2021 at 8:02

You really don't want to be storing passwords on your server in a reversible manner, even with encryption - if your encryption key is compromised, all passwords will be exposed. OAuth is the standard solution for the use case you describe: users log in directly to the third-party service and your website gets back an access token for future use.

I'm not too familiar with XMPP, but a quick search shows that an OAuth over XMPP specification exists (it appears to be an experimental spec, but at least one major implementation supports it). There may also be other authentication mechanisms that let you achieve what you want without having to store the raw password.

  • 1
    Unfortunately, using Oauth in this case would rely on the user's server supporting it to be able to issue my platform a token. Although I use ejabberd as the local xmpp option, I can't quite rely on the user even knowing what their server supports.
    – Leo Grün
    Oct 26, 2021 at 8:33
  • 10
    @LeoGrün: It is not the user's responsibility to know what the server supports. You need to provide a user interface that allows them to choose their preferred means of authentication from a list that you support. The owners and operators of those servers, however, should know what authentication they support. If they do not, do not allow their users into your system. Oct 26, 2021 at 11:40
  • 1
    @LeoGrün: You might have to settle for only supporting specific servers that you know can support OAuth. And then tell your users that the other servers do not offer a secure way of integrating with your website. Storing raw passwords is too risky considering that even the origin server likely only has a hash and not the actual password.
    – casablanca
    Oct 27, 2021 at 6:31

Never store passwords, for any reason. Not in plaintext, not in reversible encryption. The answer to your question is that you need your third-party service to support a reasonable authentication process, and if they don't then you simply cannot use them.

  1. Storing passwords exposes yourself to liability. Normal password hashing prevents anyone, including you or a system administrator, from getting those passwords. If passwords are stored reversibly, then you have to trust everyone in your organization not to abuse that power, and users can credibly claim that you are a possible accomplice if they ever get hacked.

  2. Storing passwords poorly makes you a target. Thieves and hackers like easy targets, and failing to obey best practices paints a great big bullseye on you and your organization.

  3. Think about your reputation. It will also set off huge red flags when your security conscious users are asked to put their third-party password into your site.

  4. Storing passwords threatens your users. Users are notoriously bad at password security, so you're not just protecting their XMPP account, you're protecting their bank account and everything else.

The accepted way to do this is OAuth, as has been said. Some services will provide their own third party authentication solution. Outside of this, you're out of luck.


There's a big issue with storing passwords in this scenario, at all.

In this scenario you didn't issue their identity.

Likewise, you are not on the hook to verify their identity.

Additionally, you are only partially running on the user's computer.

Therefor you're assuming a liability that is traditionally managed only by the user and the issuer of the identity.

You've given anyone seeking to compromise that identity another line of attack, for little to no perceptible benefit other than perhaps moderate convenience.

This is not fundamentally impossible to do securely, but it is something you probably shouldn't be trying to do yourself without a lot of experience in the arena of cybersecurity systems design, and it's a lot of risk to take on for a convenience feature.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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