Hi, Is there a way to encrypt the data that is stored in the user's cookies? I can go in and read the username and password in the cookie and that is bad. A website or hacker can gain access to the cookie and obtain a member's username and password. Matt
Matt, only your website can get access to cookie - not others. about hackers - do you really think they are looking for access to paid sites? I believe they looking for something else. Anyway, I will think about it - will make it encrypted.
Hi Alex, The reason why we would prefer encryption is because we keep some sensitive data on the site and we are trying to keep people out that don't belong. I figure some people would go as far as to send a trojan to members and grab the cookie. We don't run a paid site, instead it is a private site that uses the amember program for user management. Matt
also, from a security standpoint... the passwords should be encrypted. There is no reason for the admin to view passwords. Most good, responsible scripts that deal with passwords have secured this breach. Notice how Invision board does not allow you to view our passwords. Also, vBulletin secured itself a long time ago. If there is a way to block access to any viewing of any passwords, that would be great. Not just in cookies. Brian
Ah.... I found an older post about MD5. Looks like you took care of this and it's in the Pro version. You might want to 'market' that, and set Pro up as encrypted by default. As I dig deeper into the Pro version, I'm impressed with all the options. pretty cool Brian
Sage, it is impossible to deal with encrypted passwords. For example, we have to create .htpasswd - how can we use encrypted passwords for that. There are different methods for encryption, and aMember must have plain-text password to be source database for all dependent databases. P.S. Why admin shouldn't know members passwords? What can he do with it? If he wans, he will know it anyway, even if passwords stored in encypted form!
Encrypted Passwords Hi Alex Has the issue of encrypted passwords moved on at all? while I realise this could limit some options for some people, having the option for md5 hashed user passwords (stored in mySQL) would be useful. - .htpasswd automatically encrypts the password when the user : passwd string is written to the file, so there is no problem here, only with the password being stored as plain text in the mySQL database. Simply pass $user_pass to .htpasswd, then md5($user_pass) to mySQL. It's simple to deal with encrypted passwords through mySQL logins; when a user logs in the variable (say $user_pass) is hashed before it is processed. If the database contains md5($user_pass) and you hash the password entered, then the two will match. The most common for passwords seems to be the md5() function; however, allowing owners the option of storing encrypted user passwords in mySQL would greatly improve the security. I know the question will be raised about lost passwords or auto-generated passwords. The common solution to lost passwords is to generate a new one, update .htpasswd, email plain text password to the user and then hash it and store in mySQL. Again, I acknowledge the compatability issues with other dependent databases; again, here I would say the option of encrypted user passwords is what is needed. Unless you've managed to 'unhash' md5 hashes, the admin won't know the password. They can't be decrypted - you just compare the two. Why shouldn't the admin know? - does you're bank manager know your ATM card's pin number? Ok, so maybe we're not talking about Swiss bank accounts here, but as has been said earlier: best regards Paul
Paul, no - nothing has moved. 1. Sometimes (I have to say - often) it is necessary to rebuild .htpasswd file. How to do it with MD5 passwords? We just loose users database in this case. 2. Yes, I agree, MD5 is most common. But have you seen, just for example, how PerlDesk encrypts their passwords: PHP: $pass = crypt($member['pass'], perldesk_get_salt()); Beleieve me, almost any script makes it differently, so integration could be impossible with these scripts. If I design my script to be "a box" without necessarity of external integration, I would make passwords MD5 encrypted - it is right decision. However, specific of aMember doesn't allow to do this. Next major version will be able to encrypt/decrypt passwords before save to database. It is not 100% protection, but something.
Though most admins might be responsible, there are those that can be swayed to play with the info they find. Unfortunately, a lot of people use the same login/password combo on different sites. Just because they are being lazy, doesn't mean they should be open to potential abuse. How many times have you gone to different forums and find the same people you know from other sites? Even the same usernames, etc. If you happen to go on a forum that doesn't encrypt passwords, any moderators might be able to 'play' and go to all the other sites pretending to be the poor sap with the lazy logins. They can flame the forums to their heart's content, destroying that persons reputation. Also, these same people might use the same login for banking. Though YOU might not abuse passwords, we need to always make it harder for those that are, uh, weaker, and succumb to the temptation. As for HOW it can be done... I don't know. But... how does vBulletin do it? They secured it way way back. And it's not an option. An admin can always reset a password if necessary to login to someone elses account. They can also ask the user what it is if they want. Again, no need for an admin to know someone's password, unless they need to use it without the users knowledge. Brian
Brian, there is nothing COMPLICATED to encrypt passwords. But any integration will be then impossible. It is not important for vBulletin, but it is not-acceptable for aMember! We will remove any password displaying from aMember Pro CP in next version. It is not quick to make passwords encrypted in database, but we will do it someday too. However, it anyway will be two-way encryption, in fact it is just illusion of security.
Just get rid of the "two-way" security illusion in the 1st place. Make it so that the password is stored "encrypted-only" so there is never a clear text password. The software can and should be redesigned so that hashes are compared for authentication. For s/w as robust and professional as aMember, this type of security is almost implicitly assumed in today's world of growing privacy & security concerns. The source for the actual password should not be the database... it should be when the user types it into the a login box or an update-password field (be it aMember's login or the relevant integration plugin). Just use the appropriate encrypter for hash comparisons of the respective stored hashes (ie. md5 in aMember, crypt in PerlDesk, or whatever for the respective login). The point is that the password source should not come from the database, it should come from the user. The database should just be for master/parent authentication into aMember (as needed). Encrypting passwords in the database is a very important added layer of security in the event of a mysql admin password breach or aMember CP breach. That way, if someone gets the mysql admin password or aMember CP pw, it would mean that they have only breached one account instead of all the accounts of your users as well. This type of layered security structure saves from the need for a massive password reset in the event of a recovery from a mysql admin password breach or aMember CP breach (eliminating a single point of breach).
First, there is no illusion. There are real troubles that will happen. However, I agree with you, and future version of aMember will use hashing. It will not be soon, but it will be done.
Perhaps this could be an easier way to implement a more secure form of encryption in the interim. I do understand the problem with strong encryption from the standpoint of how it could break integration plugins. However, there is a form of weak encryption that aMember already uses for the ccbill datalink password. aMember encrypts the ccbill password but is able to decrypt it back for when it sends it to the ccbill server. This should be a relatively easy modification to implement where aMember program logic inputs or accesses the password (it's just a matter of adding the encrypt or decrypt function to the code regions where user password is used) I believe this same simple encryption should be used for user/member passwords and decrypted by aMember when needed. This adds a huge layer of security over clear text. I understand it is decryptable, but a person would need the decryption logic to do that. That would mean they'd need to compromise the aMember source code too (in addition to just the database) if they really wanted to obtain the member passwords. In most cases they probably wouldn't even bother just because they see jibberish for the password. It is much less inviting than clear text. This could be the case when you give a new webmaster or installer temporary trusted access to your site just to do some sort of maintenance. If they have access to your db, it's good if they can't readily see passwords in clear text. Rudimentary encryption is better than none at all, and I believe aMember is capable of implementing rudimentary encryptioin (just like it already does for the ccbill datalink password) without breaking integration with other components. I hope to see this on the horizon sooner than later Alex. Maybe a simple encryption schema will allow this security concern to be addressed much better than it currently is. Strong encryption could be put off to later, but weak encryption is viable for aMember now (and much much better than clear text).
Fred, we have implemented this once by a user request, and it works. However, we cannot do this globally, because it potentially affects too much things in existing plugins that peoples have installed and modififed for their needs.