PDA

View Full Version : User Passwords Viewable in CP



jimbo
Mon 1st May '00, 2:46pm
I don't like this one bit. I don't want to know what my users passwords are. There have been instances of admins going nuts, and since they had access to everybody's passwords they disabled the whole board. I don't want anyone who I might give CP access to know my password. This is a major security flaw that is definitly not cool. I know there are hacks so you can view passwords, but why do you want to know them anyway?

Previously, whenever I had to hack into UBB members directory to change a username (in order to maintain status) or to clear post counts (to keep user name) I always made the user make a new password.

Please put this at the top of the priority list to change.

Thank you.

werehere
Mon 1st May '00, 3:01pm
It is more secure than the UBB, and quite honestly is one of my favorite features.

I now can search by username and pull up all their info to change as necessary from the control panel, from post counts, to special status, to email, password retreival, and more.

This alone saves me hours from downloading memberlist files, looking up member files after that, and then downloading them to change/retrieve and mail their passwords to them, or tell them their own email.:)

jimbo
Mon 1st May '00, 3:08pm
Email, fine. That is definitly a good thing to have, but what about: ../forum/member.php?action=lostpw??? they can just enter their email and have the password sent to them. Why do I (as an admin) need to give it to them?

But I'm more concerned from an Admin point of view. God forbid one day someone who I appoint as a co-admin decides to go postal and completely sabotage my board? With access to everyone's passwords, that person could easily change mine, therefore blocking me from being able to do anything on the admin side.

This feature was the *ONLY* decent aspect of the UBB from the security side of things.

werehere
Mon 1st May '00, 3:18pm
Yes if you have a co-admin then that could be a bad thing.

But as far as that being the only good thing about the UBB, well anyone can just mail all the passwords to every member in your forum to themselves anyway;) ----->j/k

jimbo
Mon 1st May '00, 3:29pm
lol, note I said "ONLY"... :p

John
Mon 1st May '00, 4:43pm
OK - so should the password field be removed completely, or should it be a password field with asterisks in?

John

Menno
Mon 1st May '00, 4:51pm
I'd say asterisks.
Only if a postal co-webmaster does come along, you're still screwed.
So maybe removing it would be the best thing.

Or, a webmaster could set an option wether it's viewable, or not, and seal that option with a special password, so that it can be put on at a later time :)

doron
Mon 1st May '00, 9:08pm
how about several admin levels - where one can view passwords and the other not.

evoir
Tue 2nd May '00, 2:37am
I think that would be cool. I think that Discus allows this. In other words, the ADMINISTRATOR can allow or disallow certain priveleges to other admins and moderators and such.

Mike Sullivan
Tue 2nd May '00, 5:25am
Well, there are probably 2 ways in which you could do it:
1. Add more options to the 'user permission' thing with specifics to within the CP.
2. How about just adding a line to config.php ?

jimbo
Tue 2nd May '00, 8:18am
...to have options for everything in the CP, it will be increasingly difficult to navigate around in the CP. I'm not saying making it an option is a bad thing, but I would keep it in mind.

I suppose another level of Admin would do the trick, a "Super Admin" so to speak. That way only one person could view passwords, but allowing others to have CP privelages.

This might not be very good for a company that uses a balance of power, and likes to have more than one person in the "Super Admin" position.

That is why I say it should be eliminated totally from the standard version, and a hack made so that those who want to be able to see passwords would be able to if they want. The choice should have to be MADE to view the passwords on an individual basis. As it is now, we're forced to see them and that is NOT a good practice by any means.

JMHO

Brian
Tue 2nd May '00, 8:44am
Personally I do not see the need to have anyone other than the admin to have access to the CP. Moderators moderate etc, not controll the board, so I dont see it as an issue?

-Brian

werehere
Tue 2nd May '00, 10:02am
I have to agree with you Brian:)

jimbo
Tue 2nd May '00, 10:23am
I'm not talking about moderators, I'm talking about Admins. You may not have more than one (and I don't right now either) but I can think of dozens of sites off the top of my head that do have more than one admin.

No large company would only give one person access to the administrative functions. That is beyond the scope of common sense. If you have one admin and they go nuts, you're still screwed. That's why the majority of companies would grant more than one user Admin privelages. It's called checks and balances.

There is one main incedent I remember hearing about; it was at webmasterforums.com, I think. They used UB or something like that, and one of the Admins decided he was going to be an a-hole, and consequently shut down the board, deleted all posts and users, and locked the other admins out. ALL BECAUSE HE HAD ACCESS TO THE OTHER'S PASSWORDS.

I really don't care if you don't have a need for more than one Admin, that is not the issue at hand. The issue is that having passwords viewable by anyone who can get into the CP is UNSAFE. Period.

And it's not even like you have to enter your password to make changes. If someone were to get access to my computer, all they'd have to do is go to the CP, and my password would be stored. Convenience, yes, but not if it isn't required at least ONCE in order for someone to make changes.

WebStyles
Tue 2nd May '00, 10:33am
There is one main incedent I remember hearing about; it was at webmasterforums.com, I think. They used UB or something like that, and one of the Admins decided he was going to be an a-hole, and consequently shut down the board, deleted all posts and users, and locked the other admins out. ALL BECAUSE HE HAD ACCESS TO THE OTHER'S PASSWORDS.

I think what happened there was one of the admins used the same password on another board, and the admin there used his password to get in and do all that nasty stuff to the board. They had a couple incidents like that, though, so I may be wrong. :)

Brian
Tue 2nd May '00, 10:33am
Yes I see your point.

doron
Tue 2nd May '00, 8:40pm
another option would be to password protect the password-viewing (does that sound right?). You would be asked to enter a password before viewing a member's password from the CP.

Stallion
Wed 3rd May '00, 3:38am
Good news!

I've created a hack that will make the password field non-existant when editing, but you can still change it by typing something other than nothing in the password field :)

And, I've made it available only to vBulletin members through some l33t php coding which verifies the user/pass against the vB member database.

Check it out and enjoy -- I'll be adding more hacks soon.

(the reasoning for the password protection is so that we'll be able to distribute already hacked files without breaching any licensing agreements :)

doh...forgot that URL ;)

http://unreal2.net/vb

[Edited by Stallion on 05-03-2000 at 02:41 PM]

Michael Kizer
Wed 3rd May '00, 8:23am
Just a few comments on passwords. I am used to how they are used on UBB (stored as plain text), not so sure about how they are used in vB, but...
IMO, passwords should never be viewable by anyone, even admins. Once the user creates a password it should be stored in an encrypted format and never revealed via any screen (although I suppose the "I forgot my password, so email it back to me" type of process is a fair compromise). Since most people use the same password for multiple systems, I as an admin do not want the liability of "knowing" all of my user's passwords. Maybe this fear comes from programming stuff for defense contractors for too long. ;)

jimbo
Wed 3rd May '00, 8:53am
Amen, brother! I don't want to know my users passwords. "Liability" is a good word for it...

risestar
Wed 3rd May '00, 10:56am
I like the password in control panel feature. Wasted a lot of time in my UBB version with people claiming theirs did not work.

If you are concerned with moderators getting the info, why not have it so its not viewable or in asterisks unless an admin.?

That way if you are concerned with security, don't have a co-admin and then theres no prob.

Either that or have an option when installing or upgrading to show or not show that way we can choose?

Thanks

John
Wed 3rd May '00, 7:16pm
What I think I will do is have an option in your config.php file - that way you will need ftp access to be able to change it. Something like $showpasswords, and if it is not set or set to 0, passwords will not appear (default), but if you set it to 1, passwords will appear in an password type (****) field.

Sound good?

John

Brian
Wed 3rd May '00, 8:21pm
I like the option of seing the password if I need to easily from the web cp. Perhaps have three options.

1. Plain View
2. **********
3. Not Displayed

-Brian

Mike Sullivan
Thu 4th May '00, 5:43am
John - unfortunately, unless you add another check, any admin will still be able to edit another user's password regardless if it's in *****. If you have multiple admins and one goes postal, you're still screwed.

As Brian just mentioned, a 0,1,2 style option may be best.

Stallion
Thu 4th May '00, 6:47am
Originally posted by Ed Sullivan
If you have multiple admins and one goes postal, you're still screwed.
But wouldn't he be more interested in doing something permenant...such as deleting posts?

jimbo
Thu 4th May '00, 7:16am
Yes John, I think that is a great way to go about doing it. Thank you!

ed
Fri 5th May '00, 6:36am
Hey all!

Here is my general gripe about passwords in vBulletin. They are simple not secure enough. I assume user information is being stored in mysql which is good, but from what i can see, they are not being encrypted properly. Additionally it looks like vBulletin is parsing through the url encrypted passwords. This is a step in the right direction, however, i again assume that if i read the code long enough i will get the algorhythem and be able to decrypt any one's password. I could even do this by examining the log of the browser. This is a major problem if you are selling this product, because it simple isn't secure. I love the speed, the features, and the user backing. There simple isn't enough security. What needs to be done is this. First, if you need to pass things through the url do it with userid's. In order for you to be hacked then, you have to login to the mysql database and retrieve the id in the right table. Also, store in the cookie the id. You can even encrypt that number to make it even harder. Use sessions and cookies to prevent such attempts and also, log everything. You can never be too paraniod when it comes to security. I have to look into a few other aspects to make sure their up to ubb par. Hope some of my comments get taken into consideration when revisions are done:)

wandrer
Fri 5th May '00, 7:47am
Not to start a flame war or anything, but:


This is a major problem if you are selling this product, because it simple isn't secure.

Define 'secure' ... 'Secure' as in UBB plaintext passwords ? ... 'Secure' as in ROT-13 ? ... 'Secure' as in DES ? 'Secure' as in if root is hacked they still wouldn't be able to get/decrypt the password ?

How secure does the user forum passwords need to be?

For reference: http://www.scriptkeeper.com/ubb/Forum2/HTML/003807.html


http://www.scriptkeeper.com/ubb/Forum16/HTML/000943.html

[Edited by wandrer on 05-05-2000 at 05:51 PM]

werehere
Fri 5th May '00, 7:56am
Yeah you are referring to this as less secure than the UBB?

Well considering that most UBB's that have been out there for ages had some of the most blatent security flaws I have seen. Well then I would not say this is that insecure, and also would not compare security here.

Not that I am complaining about the possibility to have it more secure either.

BTW- What is "up to par" with the UBB really supposed to mean, since I have found it very "under par"!

[Edited by werehere on 05-05-2000 at 07:01 PM]

ed
Fri 5th May '00, 12:54pm
Hey

I had no means of starting a flames war with anyone. When you start developing a piece of software from scratch there are bound to be advantages and disadvantages from your work. UBB was one of the first, if not the first, to have such an extensive board. I see vBulletin, is being a php rewrite which improves upon many of ubb's features. However, it is my strong opinion, that password security, in general perhaps in both scripts, need's to be improved. As an admin, you SHOULD NOT have the ability to read anyone elses password. Perhaps reassign it, or mail it, but not read it. This can lead to many problems that simply are not worth it. Encryption, in my view should be something standard, be in the mysql password incryption, or any of the unix standards. I believe that at least one works. That way, if soem one where to try to penetrate the mysql server, or if root on a shared system were to access your database, your passwords would not be revealed to the entire world. I doubt that everyone who uses this script has their own dedicated server. I guess then my baseline for secure, would be somethign that protects against most of the odds of accessing and reading, be it in a browser, text file, database or anywhere else. I don't mean to be negative, but I hope that the development team does take some of this under consideration in their next or future releases.

werehere
Fri 5th May '00, 2:30pm
Oh I did not take it as that at all:)

I know you were just giving your point of view, and that is why this is the suggestions forum. I was just referring to your referrence of not being up to par with the UBB security, and I just dont see that to be true. I want my forum to be just as secure as it can be, so suggest away. I am happy to hear everyones comments on how to make this a more secure BBS.

wandrer
Fri 5th May '00, 8:30pm
As an admin, you SHOULD NOT have the ability to read anyone elses password. Perhaps reassign it, or mail it, but not read it.

Agreed.

So what is the best way to get more security into the passwords ?

John
Fri 5th May '00, 11:12pm
I have too been following this thread and similar ones at UBB.

There have been a few suggestions:
1) Encrypt, encrypt, encrypt! Store that passwords in a non reversible encrypted form in the database, and don't have cookies for username / password.
Advantages - more secure I guess.
Disadvantages - user cannot retrieve password if it is lost. User must filling username and password

2) Encrypt a bit! The password in the cookie is encrypted in a non reversible way, but they are stored in text in the db.
Advantages - still fairly secure. User can get password emailed to him
Disadvantages - Passwords can be retrieved with root access to the db

3) Don't encrypt at all! Straight text everywhere!
Advantages - easily hacked? :) Helpful for some!
Disadvantages - easy to retrieve password from history, cookie, etc

vBulletin is basically at about 2. However secure you try to be though, cookies are still going to be insecure. Even with an encrypted password there, the hacker (or whatever!) can still send this password cookie and get access. Passwords are stored using the MD5 non-reversible algorithm, so it is not possible to get the password out. The cookie stores this encrypted password. This encrypted password can be user to get access to everything that the proper password can, except for 'modify profile'. You MUST have the proper password to access this page. You will note that the boxes are not filled in when you try to access this page - that is why.

I agree that showing passwords openly in the control panel is not secure. I will be making the neccessary modifications soon to hide them as default, and optionally make them visible.

Short of going to (1) on the list above, passwords will always be visible to a root hacker. And then there's the users with passwords like sex or god or password! 'Nuff said about them.

ed: all the user cookie things are passed using the userid and password (encrypted). I do hope that the security is not up to UBB par in places. I would be very worried if it was ;)

John

ed
Fri 5th May '00, 11:44pm
Dear John and Everyone else.
Thanks for all the information. It helps tremendously. As you can see I do not own a working copy of the board. I am however the network administrator for a very large web site that's primary use is its bulletin board. We get over a million hits per month and that is why we are constantly looking for solutions that are more efficient. I personally love php and have been looking for a bbs that was up to par with ubb so that our users would not notice the difference, but would be more efficient. We are finding that it takes a lot of cpu usage and ram to keep our web server ticking away at optimal speed, largely because of ubb.

Regarding security again, I would love to see the option similar to number one. This is because, if some one loses his or her password. I prefer to have either, an admin, mail the user a newone radomly generated. Or have the common pratice of the question for lost passwords. and then having the user select a new one. I thank you for all your time and help. John, when are you guys planning to release the next version?

thanks again!

Brian
Sat 6th May '00, 3:37am
Perhaps encrypt passwords, and if they loose theirs they can fill out a form to get a new url sent that they can click on to enter in their new desired password etc.

-Brian

risestar
Sat 6th May '00, 10:26am
John, perhaps release an ultra secure, less functional version for those that want it.

Most of us are happy to have a moderatly secure, yet functional (email pw, cookies etc) BB.

Personally doing away with the cookies and email password would be a deficit.

Anyone that runs a site knows likely 25-30% of users lose password from time to time and that would just increase the admins jobs if he has to hunt or re-issue one himself.

Having to re-enter the user and pass everytime you want to post would discourage use of it as others on UBB and such would be able to post easier.

Brian
Sat 6th May '00, 11:58am
Yes a cookie is a must to keep people coming...

Menno
Sat 6th May '00, 5:10pm
leaving it up to the admin?
a CP function to choose one of the three?
(or a variable in one of the files (instead of the CP), for extre security)

TotalBS
Sun 7th May '00, 12:19am
No one, not even a 'self-appointed' admin, should have access to anyone's password.

Human nature has people use the same password on different sites, and the same ids. Having access to the passwords opens you up to a lot of liability.

As Admins (and even SuperAdmins), we should NEVER be able to see their passwords. If someone loses their password, they should be able to request a new one from the system without bothering the Admin.

And it should make the 'loser' feel better when an Admin says, "I don't have access to your password, but I can clear it for you".

====
Another thing brought up here is co-admins. There are serveral here that think it's unlikely to have co-admins, but co-admins make a lot of sense and should be more common.

I have one instance right now where it is needed. I'm the webmaster for a site, but I am not the owner of the site. The owner doesn't know anything about the web, but he has a right to have admin access and to slowly learn. The problem with him is that he is the type that wants to be able to read people's email on the server, and I can just imagine what he would think about having access to passwords.

When designing this program, realize that not everyone who is going to use it has good intentions. Or if they do, they might be tempted by access to that information. Here's an example...

Let's say Menno mentions on my board that he does his banking at WingspanBank. Hmmmm. Let me see, I go see what his password is in the CP and try logging in to his account at Wingspan. What are the chances that I can get in? What can I do with access to his bank account info? Way too much potential for misuse.

This was a major flaw in UBB's design, I thought. It made me change all my passwords to different ones across the web. (I now use Gator to remember my passwords, and a separate database)

Look at the problems that Microsoft is 'causing' with security issues in their software. They are trying to use the excuse that "Software doesn't kill computers, people do."

Please do away with ALL access to the passwords. Though we like to think so - not all of us a trustworthy. And don't make it an option either. We have no real valid reason to ever see or know another person's password, ever. Ability to reset it, yes. To know it, no.

ed
Sun 7th May '00, 12:30am
Agreed :)

jimbo
Mon 8th May '00, 7:26am
I agree that showing passwords openly in the control panel is not secure. I will be making the neccessary modifications soon to hide them as default, and optionally make them visible.

Thank you John! I love the democratic world of vBulletin!! The fact that you follow these threads and our concerns, and make changes according to what you read is a very, very good thing, and makes me even happier with a product that I was already 150% happy with.

Keep up the good work, and I will surely keep up the good word! :)

Regards,
Jim

Kenn
Sun 4th Jun '00, 2:17pm
I actually thought this being dropped was a bug till I found this thread. I've been having to do a mysqldump on the data base to find out my moderators passwords in an attempt to debug the forum permissons. I almost hate to say this, but maybe its a matter of choosing admins that you can trust. We have 3 on our site. They can get the passwords in at least two ways I can think of off the top of my head.

Admins can change email addy of the users, and request it, or just go and do the mysqldump. Hopefully those features aren't going to be dropped because someone might have to deal with a nut case admin. If the ability to backup my data base was dropped (which I don't think it can be) that would really suck.

How about adding back the feature to allow the users who want this feature to set it. Ie. the showpassword in the global.php or something?

JimF
Sun 4th Jun '00, 2:28pm
but maybe its a matter of choosing admins that you can trust


Aside from the fact that I don't think ANYONE should have the ability to view passwords in the Control Panel, it is really not your concern whom I choose as an Admin. In fact, it shouldn't concern you one bit. If you want to run an insecure bulletin board, fine. But the majority of users want security.

There is not one reason I can think of to have passwords viewable in the CP. I hate to say it, but if your users can't remember their passwords, and can't figure out how to get it once they've lost it, maybe you should consider getting smarter users. There is a link called "Forgotten your password?" on every page that requires a password.

Kenn
Sun 4th Jun '00, 4:05pm
Point Taken!!!

My only point was that blocking them from the control panel in no way increases security if you are on a dedicated server where admins have telnet and ftp access to it. If you have a decicated server, and need to find passwords to do things like testing out changes to forumpermissions, this is a hinderance, that I really think adds no securtiy whatsoever. I have no desire whatsover to tell anyone else how to run their site or their board. But the fact that people can request their passwords with the link, and the fact that admins can change email address even temporarily is a security hole. So blocking passwords from CP does absolutely nothing to protect from a postal admin. Not even to mention again the fact that doing a dump, dumps the passwords in plain text.





[Edited by Kenn on 06-05-2000 at 01:22 AM]

TotalBS
Mon 5th Jun '00, 8:57am
Kenn,

Your points are good, but I still don't know why you need a user's password. If it is to check "need to find passwords to do things like testing out changes to forumpermissions" then I wonder why you don't have some test accounts setup. Simply setup a 'User1' with a password you and your trusted admins can remember, and use that to test.

If the passwords are still available in the database, that's still a security issue, but at least it's not easily obtainable... unless you allow multiple people into the server. :)

As for the other holes, like Not even to mention again the fact that doing a dump, dumps the passwords in plain text, perhaps these could be plugged eventually.