Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
According to Forms API reference, #default_value should work with password fields (#type => 'password') but there is no value="xyz" in the rendered HTML.
Comment | File | Size | Author |
---|---|---|---|
#1 | password_default_value.patch.txt | 1.31 KB | DeFr |
Comments
Comment #1
DeFr CreditAttribution: DeFr commentedThis patch actually uses the (default-)value of the password fields and put it in the html.
Comment #2
webchickHm. I would call this "by design" and update the documentation accordingly. Storing passwords in plaintext is just a horrible idea.
Comment #3
DeFr CreditAttribution: DeFr commentedIn fact, being able to actually show the value in the field doesn't mean the password is stored as plaintext, but that the module is responsible of applying an encryption of the value - using mcrypt for example.
The main reason for that is that in some case, a hash simply can't be used. Concrete example : I want my users to be able to set in their profile their login / password information for a remote imap server, and then allow them to check their mail... I can't do that if I don't encrypt the password in some reversible way.
For the main reason of the patch now : in the current situation, if in a module one does
then everything works as expected and you get the value stored automatically, but should you switch to
then the next time you validate the form without re-filling the password field, $edit['foo'] will be blanked and the value lost. Of course, I'm not advocating using directly such a code, something around the lines of :
would be more suitable.
Comment #4
Borek-1 CreditAttribution: Borek-1 commented2 webchick: Horrible or not, developer should be in control. There are scenarios where I just need #default_value even in password fields.
Comment #5
webchick@DeFr:
"In fact, being able to actually show the value in the field doesn't mean the password is stored as plaintext, but that the module is responsible of applying an encryption of the value - using mcrypt for example."
#default_value means that value="mypassword" gets stuck in the HTML src. That's plaintext. And that happens regardless of what encryption method is ultimately used on the server. I imagine it probably gets cached in the browser as well which means it's available long after the form has been submitted.
If you still REALLY want to do this for some reason, then I would create a new element type using hook_elements called '#type' => 'insecure_password' and hook_form_alter the user login form and others to use your password field instead of the default one.
I'll leave this open for chx or one of the security people to give a final ruling, but that's my (very strong) feeling on it. No web application worth its salt should EVER put this value in plaintext, imo, and Drupal should not make it easier for people to violate this rule.
Comment #6
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedno, thanks.
Comment #7
yang_yi_cn CreditAttribution: yang_yi_cn commentedIt's a really old issue, but I still feel it's not user friendly to always empty the password field when loading a form.
Think about a very common scenario, user account editing:
1. The user created an account with a name, password, and some other personal information, no problem.
2. The user logged in and try to change some personal information, with no intention to change password.
- Here comes the problem, the password field is emptied and the user cannot save the form!
We don't necessarily show the old password in plain text. In many sites, the common practice will be showing the password field with some asterisks, indicating there's a default value, and if you just save it, it will not change the value. However, in the current Drupal implementation of the password field, it's just impossible.
Comment #8
yang_yi_cn CreditAttribution: yang_yi_cn commentedComment #9
Damien Tournoud CreditAttribution: Damien Tournoud commented@yang_yi_cn: the user is never forced to enter something in the password fields. I'm not seeing how this is an issue.
Comment #10
yang_yi_cn CreditAttribution: yang_yi_cn commented@Damien Tournoud
It's interesting. I didn't notice that because I was writing my own form and trying to use a '#type' => 'password' field. Drupal core user functionality does do some special treatment, at user.module,
It seems that I have to do my own handling to the password filed if I want to use it.
Comment #11
dopry CreditAttribution: dopry commentedAlernative use case would be unsetting the titles and using the default values as labels.... And that isn't all that dirty in my opinion.
Comment #12
ngroupp CreditAttribution: ngroupp commentedSetting the "value" attribute of a password input field is perfectly valid XHTML. There are plenty of situations where this is acceptable. Regarding the security implications, simple password authentication is, by its very nature, insecure. In addition, without SSL there should be no expectation of security whatsoever. Obfuscating user input in the password field only protects against casual shoulder-surfers. In no way, does this "feature" improve security. It should be patched in core, as DeFr suggested above, with appropriate warnings about the perceived security risks. BTW, here is a simple workaround:
(...)
While the password should be encrypted before being stored in the db, unless the form is secured with SSL, it will have already been broadcast in the clear so it doesn't matter all that much.
p.s. You might consider an 'annoying' option in the Priority menu. :)