How bad are usernames and passwords stored in hidden form fields?

Question

Suppose you've got a webapp that's passing usernames and passwords around in hidden form fields.

I know it's a very bad idea, but I'm interested in enumerating why... any thoughts?

update - This is a hypothetical question.

I couldn't find a resource that just enumerated the reasons - I know of plenty of reasons why it's a bad idea, I'm looking to see if there are any other reasons I haven't thought of and create that resource I was looking for. Thanks!

Answer 1

interested in enumerating? You may be at a very serious risk !!

Answer 2

It's so easy for anyone with access to the current page ( might not necessarily be the same person who log into your application) to view the html source and get the user name and password.

If I log into my gmail, and leave my desk, and you come in and you can see all my email messages. But no matter what you can't see my gmail password. But if gmail passes the password around in hidden field format, then you can see my gmail password.

Answer 3

Wiretapping, especially if the transport layer is not encrypted

Answer 4

unless all your pages are served over https it's bad because usernames and password are sent in clear text over the network constantly and can sniffed. Even if all pages are served over https it's bad because if a user forgets to close his/her browser, anyone with access to the computer can view the source and read the password. It gives the users a false sense of security and I would recommend that you change it if at all possible.

Answer 5

Well, the dangers vary depending on what you mean by "usernames and passwords".

If you're referring to the usernames and passwords being validated against, I invite you to choose View->Source in your web browser. This is no security at all.

If you mean the username and password of the user logging in being placed in a hidden field before being sent, there's absolutely no difference between that and your standard text and password fields. The only security risk here are passwords being sent in-the-clear without a TLS/SSL connection to encrypt it, allowing for packet sniffing to see the credentials.

Answer 6

A number of reasons why it is a poor idea:

1) As pointed out, if you view source, inspect element, or anything similar, then the username/password is easily discovered.

2) Unless your transport layer is encrypted, they will be easily intercepted.

3) If the browser caches your html page, then that file with a username/password is now stored on that person's computer.

4) If that user saves the page to give to someone else, then their username/password goes with that page.

5) A POST method accidentally gets changed to a GET, now the password and username is stored in the server access logs....

Etc, etc.

There is no real reason to do it in my opinion, especially when you can use session cookies on the server, or some other method that doesn't expose private information to the client.

Edit: Come to think of it, I have done this once before. I put a password in a hidden field, however before doing so I encrypted it with a secret key known only to the server before printing it out, and then when I got the password posted back to the server, I decrypted it. Therefore the plaintext password is never with the client.

Edit 2: Should probably point out that the method described in the previous edit was not used for directly authenticating someone, as per hobbs point.

Answer 7

I don't think storing a username in plaintext is so bad, and in some cases it might be beneficial to do so.

Storing passwords, however, are a different story. It would be very easy for someone to packet sniff your data going across the network (there are many points on its journey that this could happen) and logon using your credentials.

A golden rule I follow is never store a plaintext password anywhere, ever.

Answer 8

I think the biggest risk here is that any XSS vulnerability now allows password stealing. XSS is much worse than it seems. There isn't really any excuse for XSS vulnerabilities, but people make decisions such that they become rather inevitable.

Perhaps the second biggest risk is caching. These passwords are going to end up on disk and be available to any malicious code trawling through files. Having said that, most passwords can end up on disk through swapping and hibernation - it becomes a matter of probabilities.

Answer 9

• The page could get cached in a user's browser.
• The page could get cached in a proxy server.
• Worst of all, the page could get cached by a search engine.

In all cases the content containing username and password might be served to a person who is not supposed to see it.

Answer 10

Typically when I need an official resource for listing possible attacks or weaknesses, I turn to:

Common Weakness Enumeration http://cwe.mitre.org/

Common Attack Pattern Enumeration and Classification http://capec.mitre.org/

Taxonomy of Software Security Errors http://www.fortify.com/vulncat/

Amazingly, storing username/password in a hidden form field is such an egregious error that it hits about 20 issues within the CWE.

Just to get you started:

http://cwe.mitre.org/data/definitions/352.html

http://cwe.mitre.org/data/slices/384.html

http://cwe.mitre.org/data/definitions/471.html

http://cwe.mitre.org/data/definitions/472.html

http://cwe.mitre.org/data/definitions/639.html

http://cwe.mitre.org/data/definitions/642.html

http://cwe.mitre.org/data/definitions/656.html