I am checking out aMember as a posibilty for the base of a system to centralise memberships over a network of vbulletin forums after seeing it recommended on vbulletin.org. I have installed the trial on a test site and am initially impressed with its clean design and functionality. I have only been messing around with it for a couple of hours, but one thing does concern me: storing user passwords as plain text. I have several user account on sites all over the internet, and like many other people (i assume), I use the same password(s) often. As a customer, it worries me that site admins (and their host) have the ability to easily read my password, and, as a site admin, I want to have my arse covered by not being able to read them. So the questions are: why does aMember need to store the user passwords as plain text? And are there any options to using password hashes instead?
Unfortunately, that is currently impossible to change. The reason why we don't use hashes is http://www.amember.com/integration.php Almost every script tries to be original and stores passwords in its own format, so aMember needs clear-text password for integration. Unfortunately, it is currently impossible to avoid. We have ideas how to fix it, and it will be done in aMember4, but no ways yet.
I ditto that. Storing passwords in plain text is not a very good idea IMHO, but I understand the reasons. I think the admins should be able to choose whether they want to have passwords stored in plain text, or crypted at the cost of 3rd party plugins integration problems. Well, yes, to a degree. But the vast majority of 3rd party scripts will either use MD5 hash, crypted MD5, Standard DES, Extended DES, or BlowFish. In fact 98%+ of them will probably need just MD5 hash or crypted MD5. One possibility I can imagine is having passwords in all of these formats created at the user signup time in separate DB table fields and update all of them when the user changes the password in her/his admin panel. Then in each of the plugins you choose which of the password format table field should be used by that plugin for the password verification. I think it would be doable for just about any plugin except for those that require the password in plain text format. But that would be an acceptable compromise in my opinion. I have to say I am indeed somewhat concerned about this issue because I will be using Amember on a privacy related membership website and some of my customers will be somewhat...paranoid Tomas
Quite a lot of system actually use salts and multiple MD5 passes of the password string. I seriously do not like password in the clear anywhere, almost made me pass up aMember and we seriously love it. Doing a reversible encryption (rather than a digest) with a strong key would at least make it a 'bit' hard and non-obvious.
tomfra, I agree completely, it is what we planned for aMember4 and it will be done. However, it is too late to implement it in aMember3 - too many things will be broken.
Alex, I've decided to purchase for my moodle integration. Should I wait for v4 for this updated password security features. When this new version is likely to be introduced.
I think there are some options to help increase the security of the amember password and other member data which are stored in session variables on the server. Whilst this won't help with the security of passwords INSIDE the database, it aims to increase security by making it more difficult for hackers to get hold of passwords and other member data which are stored temporarily OUTSIDE of the database, in the session variable file. Options I've found to work in my trialling are: OPTION A By default, session variable files are normally stored in some folder on the server (which is is a server setting, not an amember setting, and that folder is not normally directly accessible). However, if members do not log out properly, the session variable information can remain on the server. Perhaps there is the possibility, even though it may be remote, of member details in the session variable file being hacked into by someone else with a web hosting account on the same server. It is possible to specify where the amember session variable data is to be stored by adding the following single line to the top of the config.inc.php file, before any other actual code: session_save_path('/path/to/newsessionfolder'); ...replace '/path/to/newsessionfolder' above with the real, full path to the folder to be used and don't call the folder 'newsessionfolder' ! The folder used has to be writeable (or it won't work) and for security it MUST be above, and definitely not in, the web directory (so others can't access it via the web). In my evaluations, this works fine, however anyone interested should trial it and satisfy themselves that it is all OK on their installation, before actually using it. An ftp client can be used to check that the session variable file is now being stored and updated in the new location. Specifying where the amember session variable data is stored gives the amember administrator a degree of control over what happens to that information. For instance, old session variable files can be deleted manually using an ftp client, or automatically with a cron removing all session variable files in that folder that are older than a specified age. OPTION B INSTEAD of the above, (so no changes to the original config.inc.php file are necessary) an .htaccess file (file named .htaccess) can be created and the following line included in it: php_value session.save_path /path/to/newsessionfolder/ .....replacing '/path/to/newsessionfolder' above with the real, full path to the folder to be used. Put this .htaccess file in the main amember folder, if there isn't a .htaccess file already there. If there is one already, simply modify it with the changes above. Note: php_value directives in an .htaccess will not work with some servers. Again check it's working via an ftp client, and check it is all OK with your installation. OPTION C Alternatively, instead of storing session variables in the session variable file, they can be stored in a mysql table - there are various scripts available on the web to do this. Regards Davido
location of the session storage is one thing related to the pw security and it is a good to keep it in a safe location. my suggestion with respect to the overall security picture though is to keep the pw stored clear text in the session and protect the storage path in whatever way is most feasible (the current session storage method not actually being entirely so bad since a few pw's maybe be compromised one at a time at worst as opposed to an entire database). but to better protect the clear text pw's in the db (which is really the bigger security problem), just encrypt them using md5 or crypt for the aMember storage. but make sure the password source for plugin integration authentication is the clear text pw stored in the user's session. and make sure the internal program logic used by amember to authenticate within amember itself uses clear text pw stored in the session such that it is hashed appropriately for comparison against amember db pw storage (or any other integrated plug for that matter when bridging a product). the clear text pw in the user session serves as the perfect method to source authenticate for all applications rather than clear text in all of db. the main reason is that sessions are more spread out and still hard enough to snoop out and even if they get snooped outone by one over time, you don't lose your entire userbase as if the hacker snooped your clear text db.
Fred, it is nice idea, but unfortunately, access to password is needed not only from the customer session.
The idea of the password stored as plain text really... REALLY... concerns me. As far as my site is concerned, I do not use any of the add-ons. For plug-ins I am using: - authorize.net - htpassword - new_rewrite - php_include can you tell me if it would cause a problem if I just md5 the passwords in my database, considering how I am using the program?
i'm almost positive that would still cause massive authentication problems for your users. there is lots of program logic throughout aMember that would need to be re-engineered with respect to the correct hash comparisons and also retrieving a clear text version of the pass from an appropriate source where relevant (temp $_SESSION storage being one partially encompassing method to do this). i still think password storage strengthening can be accomplished in aMember -- it would just require a lot of overhaul combined with a user table update on a future revision. clear text pw can always be taken from the $_POST data initially then stored for persistency in the php $_SESSION variable and for other program logic such as "create new pw" or "send pw" (where $_SESSION might not be available), those functions would need to be adjusted to better carry the source pw through the program logic rather than depend on db storage. I don't imagine the situations for the latter are numerous, nor would the source pw carrying process be too much burden to recode in those few special cases. But $_SESSION storage of the clear text version could suffice for most of the software's usage of passwords as far as I have seen. heck, even using the existing (but weaker) aMember crypt and decrypt functions for pw storage and retrieval conversion can offer better protection w/o the concern of losing the original clear text version where and when needed in the program logic. The db would just pull the encrypted pass that is stored (instead of pulling a clear text) and simple decrypt to get the clear text. This is still leagues better than clear text storage and plus I know Alex probably did a good job of privately seeding the crypt functions too, so it is not a decryption technique that is overly vulnerable unless someone owned an aMember license (maybe even a specific aMember license too depending on the hidden private seed logic ). It'd be the same way those crypt and decrypt functions are already being used in aMember to protect and retrieve credit card numbers where and when needed. Strong enough for that security and possibly even stronger than some hash comparison techniques depending on the way the seed or salt is privately obtained or generated.
Hi, This post of mine is very beneficial and informative, however there are some specific facts or information that I require. If anyone can help me in this matter then please send me a private message. Best Regards, Pakistan Property | Wholesale Suppliers Wholesale Canadian Directory | All UK Wholesalers
Sorry to waken up this thread again, but we're almost 2 years past the original post, and 1 year since the last reply with still no v4 in sight. Any word of when we can expect secure password storage?
Password encryption This is also of concern to me. I am studying implementation of an aMember system without necessarily any implementation of 3rd party integration plugins. It looks viable to me that registration and login forms could both use javascript crypt functions to hash the password a user entered before it is sent to server to be stored or compared with password field in user's account, right? Or is aMember version 4 close so I shouldn't bother with trying above approach? (I realise 3rd party integration plugins create complexity often since they mix in their own app folders or domain names etc. into the hash function.) Thanks in advance for feedback ...
damion, I agree with you. We will make it selectable so customer can choose to have passwords hashed, but then any plugins cannot be added later. And it will be done in v.3, in near releases.
Alex, maybe you've been working too hard this week and it was Friday when you typed this -- do you mean v.4??
Alex, can you also elaborate on what you mean by "plugins can not be added later".. does this mean that if an Admin enabled hashing, they can not use single signon for 3rd party plugins?
skippybosco: I am not Alex but I am pretty sure that if you store the passwords in the aMember database in hashed-only form, and if the 3rd party plugin normally uses plain text or encrypted passwords in the respective software database, it will not work without modifing that software to use hashed passwords instead. Hashing is a one way process, it cannot be decrypted. A probably better idea would be, in my opinion, to store the passwords in the aMember database in encrypted form making it possible to decrypt them using some kind of a "master password" and then modify all of the plugins, or the plugin engine, to decrypt the password before sending it to the plugged-in software. Tomas
Thanks for the response Tomas.. I came to the same conclusion from his response and was hoping a creative solution like what you have suggested was in the works.
When I was talking to Alex about this before he was going to use an encryption rather than a hash. Doing a one way hash is NOT going to work for most everyone. Though once a hash system is made I will be able to change it to something else fairly easily. Although the built in php mcypt is not 100% secure (what really is if it is reversible) a good key will stop most everyone from just being able to browse passwords. Which I think is the main concern. It is on my list of things to do ..