Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
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.
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.
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.
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.
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.
