johnubc wrote:The misinformation here is surprising.
At long as you are using HTTPS, you will be ok wrt the username and password (as well as the data). Make sure that the site actually uses HTTPS for the login - most sites that use 'advanced' authentication will prompt for the password on a second web page, not on the initial page.
Unfortunately, this is true if and only if you're using HTTPS to connect to the actual site you think you're connecting to. It's not hard to set up a man-in-the-middle attack even for HTTPS, where the victim types "https://www.fidelity.com" in their browser, but because the domain name lookup has been compromised, their computer connects to "https://badsite.example.com" that has what looks like a valid certificate for "https://www.fidelity.com" (see how easy it was for criminals to get valid certs for sites like Hotmail, Google Mail, Yahoo, and Skype through a Comodo cert agent, for example). The browser will show the "lock" icon with the expected site name, but the details will differ (e.g., the certifying authority will be different than the one used by the real site). People I've worked with in the security industry say that this kind of compromise is actually surprisingly common, though mostly outside the US, and is usually either highly targeted or conducted by government agencies.
Some modern web browsers like Chrome implement "certificate pinning" so the browser itself will reject what are otherwise valid certs if they don't match some criteria. This is usually limited to a very small number of sites (e.g., Chrome uses it for Google's certs only, I believe) so it's not a general-purpose solution. The "chain of trust" model required by SSL certs is fundamentally broken.