I have a web app that includes third party websites in iframes. The 3rd party websites require user to be logged in them. Option A is to require the user to login to each website individually via iframes and rely on cookies to remember the user. That however is quite inconvenient and some users would definitely prefer a one login for all websites so that's my option B:

It relies almost entirely on frontend security and encryption.

First, storing the password. Every user has a password (main password) to my web app. The password, besides being used for logging in to my website, would also be used to encrypt user credentials from user's websites. So credentials are encrypted using the main password on my server and only the user could decrypt them. This is where I have a question, would I just need to encrypt it using the password alone, or some magic secret keys or some stuff could be used to strengthen encryption?

Overall process:

  • User logs in to my web app.
  • Main password is stored in browser memory for further use
  • Pulling encrypted credentials from server and decrypting it on the frontend, using the main password

  • decrypted credentials are stored in browser memory

  • open login iframe and send credentials using postMessage to the login iframe (origin validation included)

  • log in automatically (I have integration plugin for the sites, that's why I would be able to do it).

Note that logging in to web app and decrypting credentials are 2 different processes. If the user refreshes website, is still logged in, he cannot access the credentials. He will be asked for the password again. That's not a problem, since the session from third party websites will be remembered by the browser anyway.

So the frontend data would be protected from iframes by web security and as long as I make sure there are no XSS sinks on the web app, there's no way these passwords are leaking, am I right? Even if the server was compromised.

The only way I see it, if the server was compromised and someone edited the frontend code to be malicious and grab the passwords. But that is something that would always be dangerous, even if I didn't implement autologin at all.

I just want your opinion if that's a secure way to store and use passwords and what could potentially go wrong. Especially, is it safe to store passwords in javascript memory and how to encrypt credentials - use just the user password or maybe add some secret token to that password (don't know if that makes sense). Anything that would make it more secure. Any help appreciated.

  • are you sure you can use login creds on the main page to login a website from an iframe? – MikeSchem Mar 3 '17 at 17:45
  • Yes, I have integration plugin for these websites. Meaning I can insert almost any code on this third party websites. But the web app itself can only send postMessages and the integration code on third party websites receives the message, populates login form with credentials and submits the form. – Maciej Krawczyk Mar 3 '17 at 17:50
  • Is it feasible to use some form of SSO instead? – Xiong Chiamiov Mar 4 '17 at 1:16

The best way to do this would be through oAuth. Check to the documentation on the websites to see if that is a viable option. If it is not, it is definitely not recommended to store user credentials in any form on a webserver, a browser, or anything else. Normally when you validate a login you are validating that the hash (plus a salt) of the password matches what is in the database. The password is never actually stored in the database not even in a encrypted form. In this scenario there is no way for an attacker to know what the password for the user is even if they are able to compromise the database (short of a brute force attack).

  • But if the encryption is strong, how the attacker could ever decrypt the data without having the password? – Maciej Krawczyk Mar 3 '17 at 17:52
  • If they own the server, they will have the encryption key uesd. Then you have to explain to your customers why their multiple accounts you have saved passwords for have been hacked. – MikeSchem Mar 3 '17 at 17:55
  • No, that was my point. The data is encrypted and decrypted on the frontend. The server only stores encrypted data, it doesn't decrypt it and encrypt it. Everything happens in user's browser. – Maciej Krawczyk Mar 3 '17 at 17:56
  • @MaciejKrawczyk And how do you know that you encrypted e.g. 5 character password in any secure way? – xmp125a Mar 3 '17 at 17:58
  • That's why I also asked about encryption, how could I make it more secure. And I would require passwords to be at least 16 characters. I don't know, maybe another, less convenient way would be to give users private keys. They would have to upload them every time they'd like to access passwords database. – Maciej Krawczyk Mar 3 '17 at 18:03

If I understand your question correctly, you want to present yourself as a trusted middleman, who will store THEIR logins on YOUR server.

Even if this is technically possible without raising red flags and warnings all over the place, you will have hard time to convince users to essentially blindly trust you with their passwords. Because, you will handle their passwords in plaintext when logging them in. You will impersonate them. Seriously BAD idea!

So, unless there is a comprehensive legal agreement that YOU are inherently trusted to handle the passwords, I would advise against that path due to legal problems alone.

Technically, it is always a bad idea storing passwords, even if encrypted, and is even worse idea to use those passwords to log users in just for the sake of convenience.

I assume you don't have control over those other sites, because then you could perhaps establish trust in some other way, not by shuffling passwords around.

  • I have some control over these sites, though an integration plugin. I'm open to other options, but I require that the user can log to all his websites with single login, how could I do this otherwise? – Maciej Krawczyk Mar 3 '17 at 18:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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