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.


  One of my employers told us that if we receive a suspicious email with links, we have to hover over the link (to check that it is not spoofed) before clicking it. 


When you mouseover a link, the value of the href attribute  is displayed in the status bar. Since this is the link target, it can give you an idea about where the link is going.


  would someone be able to spoof this action and try to do something funny?


Generally, yes. The actual link target can be "spoofed" using Javascript: It is quite common for websites to exchange the href value with another link as soon as the user clicks on it. For example, you can observe this when visiting Google search results. When you mouseover one of the links, it will be displayed as https://security.stackexchange.com/... but as soon as you click it, that event is captured and you visit an intermediate site first (https://www.google.com/url?...) which redirects you to the actual target.

But any well-designed (web-based) mail client will not execute any JS in HTML e-mails. Active script content in e-mails is  dangerous - not only because it potentially results in an XSS flaw in the mail client but because it can also be used to run JS-based exploits against the browser or simply inform the sender that you have opened the mail.

So, if your mail client disallows JS in e-mails -  which it most likely does -  then the link displayed on mouseover is indeed the correct link target. But you should be aware of other attempts to deceive you, such as homograph attacks or an overly long URL that disguises the actual target domain. It's not as easy to analyze an URL in the status bar as it is from looking at it in the address bar. In a more advanced attack, the attacker could also have compromised a legitimate site beforehand (e.g. through a persistend XSS flaw) and you won't be able to tell from the link at all that the site now actually hosts dangerous content.
