Is passing password from server to browser in javascript variable over https secure?

Question

Following is our page flow,

1. User is at Login page accessing via https.
2. User enters password and page is submitted (POST method).
3. User credentials is not authenticated now instead server response with some polling page(https).
4. In order to retain the password on poll page, password is passed from server to browser via Javascript variable and onsubmit of poll page, password is passed via POST method. Now server authenticates the user credentials.

Question: Is passing password from server to browser in javascript variable over https secure?

My opinion

• Entire transaction between the browser and server is via https and password is passed via POST method - so password is SECURE.
• The password is visible via "view page source" since it is assigned to a javascript variable - NOT SECURE if browser plug-in has access to the page content. But if browser plug-in has access to page content then it can even access the password while user enters it, so NO new threat is introduced by this flow.

Note

• I know their is better way to handle this flow. But I am interested in whether our existing flow is secure or not.
• Any reference to security tips will be helpful.

Answer 1

The bigger issue is best practice - you just don't need to do it, and it's bad practice. This would indicate a poor understanding of security overall - it's a best practice to not store the password in plaintext ever. If your programmer coworkers do not give proper credence to this concept, then I would suggest they may have other areas they are lax in observing, security-wise.

Security is a mindset, not a lowest common denominator. It's about giving as few opportunities for compromise as possible, giving as little wedge room as possible.

Not storing plaintext passwords is what you should do, not "store them when we want unless someone can prove it's bad".

This interest in "harmless failures" – cases where an adversary can cause an anomalous but not directly harmful outcome – is another hallmark of the security mindset. Not all "harmless failures" lead to big trouble, but it's surprising how often a clever adversary can pile up a stack of seemingly harmless failures into a dangerous tower of trouble. Harmless failures are bad hygiene. We try to stamp them out when we can.

http://freedom-to-tinker.com/blog/felten/security-mindset-and-harmless-failures

Answer 2

Sure, the transactions themselves may be secure from some forms of interception, but you're opening yourself up to a number of other attacks that don't rely on intercepting the request/response activity. What if some page of your site is susceptible to cross side scripting and some malicious javascript gets on your page?

Answer 3

The transmission would be secure. But it would be inadvisable to send it with a response because browsers would cache the value with the page. Someone could maliciously view source of the page and view the password.

Could you do this by passing a server session key?