I have been integrating aMember recently and I am shocked to see that the passwords are stored in plaintext! I thought this was supposed to be a secure payment processing script. Yet if any unforseen exploits in future allow someone access to my admin panel, they will get all of the passwords in plaintext. After reading this thread I was hardly reassured either. Is there anything I can do to protect my users passwords more?
Do you use integration plugins? If no this will be easy enough to modify aMember code and encrypt passwords in database using md5 for example.
Unfortunately, yes. I use the vBulletin integration plugin and I understand that this means I won't be able to change things as they stand. I would like to ask however, why plaintext is required when you install the two scripts totally fresh with no users? Surely aMember can encode every password it recieves twice (once for aMember user tables and again for the plugin). When the user updates their password it can do the same again. As far as I can see, if you start with two empty user tables (as I am) you do not need to store the passwords in plaintext. The only way I could see this being a problem is if aMember is designed so that it first adds the password to the database, then retrieves it and tries to re-encode it. If that is the case, would it not be easily solved by placing the plugin password encoding before the insert?
We have more then 100 integration plugins for different scripts, some of them are use md5 for passwords encryption, but there are many scripts that not just use simple md5, and have own algorythm, so this will require to store password for each algorythm. What if user will decide to install forum for example when he already have big user's database in aMember. That's why passwords were not encoded, but we will fix this in aMember 4. For your exact situation, you can use any two-way encryption algorythm and modify just few functions. So password will be encoded when stored in database and not encoded inside script.
In the instance of a fresh install you would only have to generate the hash once on insert and then store it in the appropriate script database. What if we have a payment script handling sensitive personal information exposing its user passwords? That's more alarming than whether or not a forum can be retrospectively integrated with said script. In that case, why did you ever do it the way it is? The only legitimate reason would be that selling plugin scripts is a higher priority than security to aMember.