I have a basic web application where users can login and edit their profile. In the profile they can submit an username and a password for a different application. I'd like to take that password and encrypt it. Later, when I want to connect to that different application I need to decrypt the password.

Is there a common pattern for this scenario? Or some other advice you might have? Just in case it matters, I want to connect to JIRA without having the user have to submit his password on every request / login to the page.

Thanks, Sven

Update To make it more clear, I have a web appliction where users can signup/login/etc, this uses a authentication/authorization library (friend) and its all well. However, from my webapp I want users to connect to a jira instance that they can choose and where they have to provide a username/pw combo which I cannot hash, because I need to send them unhashed to the JIRA instance.

What I am thinking of right now is to display a login dialog to the user as soon as he wants to request his JIRA instance. There he provides his username/password combo for JIRA and I send a REST request to JIRA from the client side, so no user/password is sent to my server. I get a sessionid back then, which I can use for further requests. What do you think about that approach?

2 Answers 2


I would suggest two things.

  1. Don't do security yourself unless you really know what you are doing, or are experimenting on a trivial application that real strangers / customers are not going to use.

  2. You should not be storing passwords, even encrypted passwords. Look into 'hashes' and 'salts', 'rainbow tables' and password security. When a user tries to connect, the password they enter should be securely hashed and compared against the hash of the originally set password. As a hash function is one way, even if an attacker got hold of the list of users's hashed passwords they could not recover the original passwords (I say could not, that depends on your implementation of this theory and the compute power of the attacker).


In response to the comments: I'm not aware of patterns for that, sorry. In which case I guess you need to be holding the passwords so encrypting them is the best you can do. You could save the encrypted passwords on the users machine, send them to your server encrypted, decrypt them and send them on to authenticate against JIRA using a secure connection. That way even if your server was hacked you wouldn't be storing passwords at your end. If a user's machine is compromised there are worse things that they could do than try to crack your encryption for just one password. When chrome stores user's passwords they aren't that secure but Google have said that they don't want to give people a false sense of security and so they have no plans to improve it.

  • 2
    Both things are good advice™, but they neglect the aspect that the OP wants to be able to login "on behalf" of his users to a third party service.
    – guntbert
    Mar 15, 2014 at 13:09
  • Yep, what gunrbert says is absolutely true.
    – sveri
    Mar 15, 2014 at 13:57
  • Thats a nice idea too, this way the user does not have to log explicitely in again as soon as his session expired and as long as the password remains encrypted on the client side. I am thinking about that too :-)
    – sveri
    Mar 15, 2014 at 16:01

Your ammended approach sounds better -- see the caveats below.

Saving passwords on behalf of another application is a really big no no. First, if your encryption keys or datastore are compromised, then you've not only exposed the users of your app, but the users of the other app as well. And because people tend to re-use passwords, odds are you've compromised their security on other systems too. So saving user passwords to other systems is bad, bad, bad.

  • OAuth was developed for exactly this reason -- so two systems could share authorization without exposing user credentials to each other.

  • In fact, the constraints around passwords are so strict that usually even an application isn't allowed to save encrypted passwords itself. Rather, it salts and hashes the password and saves the salted hash. That way the best a hacker can do is get the hashes. However, remember when LinkedIn got hacked and released just their hashes? Even hashed passwords are like gold to hackers. That in itself was a big deal -- a bad security breach.

Your ammended solution is better -- where you hang on to the session ID rather than the client credentials.

The caveat is that users are still giving their username/password to your application, and trusting you to do the right thing. Phishing sites do pretty much the same thing, with bad intentions. Really the best thing to do would be to have users log in to Jira in a separate window, and then redirect over to your site with the session ID. That way they only ever send their password to Jira and you're not in the loop at all, until you get a session ID.

You might investigate and see if Jira supports OAuth, which would handle this case (full disclosure: it feels like I should know that). Or if they have some other mechanism for doing what you want. It may be that they've already provided a hook to do what you want to do.

... and if they haven't, then it raises a serious question of if you should ...

If this is an internal app within an organization, you have more leeway, because it's less likely someone inside the firewall will try to compromise the system (unless you are paranoid, or you work at Target).

But if this is an external, public-facing app exposed to the Internet, then ... hmmmm ... you'd want to get out of the business of handling people's external credentials as soon as you could.

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.