Extend profile module with a password field and masqueraded display
MadHarold - July 8, 2008 - 12:30
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | profile.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
Description
Dear Devs,
For I project I have to store a plain text password in a user profile and use that password to log in to a webservice and retrieve some information for the user.
The current profile module doesn't support password fields, but that's easily fixed with a hook_form_alter(). The plain text password is however shown on the user's profile page, which is kinda annoying and quite a security 'issue'...
I've created a quick patch that adds support for password fields and masqueraded display on private profile pages. Before polishing the patch and adding tests for it, I'd like to ask your idea's on this subject, especially since the password is stored plain text in the database...
-tnx!-
| Attachment | Size |
|---|---|
| profile_password_field.patch | 5.12 KB |
#1
Subscribed
#2
I don't think this is really a task for profile.module - seems like a custom table would be fine for it to be honest. Also I doubt any kind of plain text password storage will get into core. So for me, this is won't fix, however I'll leave it active for a bit longer in case others disagree.
#3
@catch: I could store the password encrypted with the drupal_private_key, but if someone gets hold of the database, they can easily decrypt the password too...
AFAIK, there is no php/code based private key available in Drupal to make a cross-encryption, is there? (that way you'll need both the code and database to decrypt the password)
I need the password to be plain text to submit it to an other website, so hashing it is not an option...
#4
I agree that this should not be provided by Drupal core - so, that's a second vote for "won't fix".
Like catch, I suggest you create this in a separate module. My thought is that it would be good as a cck field and then you can use in a "node as profile" solution like bio or nodeprofile.
#5
Additionally - if done as a CCK field, it'll be more forward compatible with whatever profile.module looks like when it's dependent on fields in core (which is what CCK will eventually become) - and save yet another upgrade headache for whoever takes on the eventual conversion of profile's current nightmarish storage. Since that makes two of us, I'm going to go ahead and mark this won't fix.