Opened 11 years ago

Closed 7 years ago

Last modified 7 years ago

#364 closed bug (wontfix)

Way to use password in query at login

Reported by: jeanyves Owned by: fake51
Priority: major Milestone: Legacy Resolved
Component: FrameWork Keywords: security password


In bwauthlib there is the following query (a similar one was in old BW)

$query = "SELECT id,Status,Username FROM members WHERE Username='" . $this->dao->escape($handle) . "' AND PassWord? = PASSWORD('".$this->dao->escape($password)."')";

the nasty effect if that if the Query is log because it is delay (it has happen yesterday), the password is recorded in plain text in the log

Change History (7)

comment:1 Changed 11 years ago by jeanyves

  • follow_up changed from none to review code

I have done a partial improvment

I now realize that these password should be md5() or similar, I don't find way to do a proper test "is the entered password corresponding to the one mysql PASSWORD() function will compute" without risking a query log.

I propose an improvment wich will reduce the risk of slow log recording the password in plain text

Please comment

Last edited 8 years ago by jeanyves (previous) (diff)

comment:2 Changed 11 years ago by feuerdaemon

  • freq_reported set to 1
  • show_on_bw set to 0

The Passwords arn't stored crypted in the DB?

I thought the DB has only the crypted pwd. The SM- and PHPBB3-Forum use it like this:

Someone has transmitted the password 'test'. After you checked, that the transmitted string isn't any risk to use (spoof-free, code-free, etc. = it just means it's save to handle)- you encrypt it (in that case with md5() ) and hold it in the var (in the var is the md5 value for the string 'test' -> 81dc9bdb52d04dc20036dbd8313ed055). And with that, you can work -> Put it in the DB, compare it, etc.

Cause in the DB is only the md5 value for your password you can just compare the (crypted) var with the (also crypted) DB value. Then there is also no problem to log the (crypted) pwd somewhere. Sure, you should try to NOT log any (also crypted) pwd somewhere.

But while this is a problem with a querry to the DB - it seems to me that, we don't use a crypt. If we would do, a log would't be very risky.

comment:3 Changed 9 years ago by globetrotter_tt

  • Component changed from unknown to FrameWork

Is this ticket still valid?

comment:4 Changed 9 years ago by fake51

  • Owner changed from jeanyves to fake51

Yes, it's still valid: BW still uses incredibly poor password encryption and still sends off the passwords to the database in the clear

I'll see what I can do about changing the password system.

comment:5 Changed 8 years ago by jeanyves

Still Existing

The point is not that BW has a poor or rich password encryption.

The problem is that the query to check the passwod against what the user has filled use directly what the user has filled and, if the server has an overload (which doesn't occur for now, but could happen some day) a log of the mysql query can occur, and if (another if) a sysadmin looks to the log he could see the password of the user. If (a third if) the sysadmin is not a fair guy he could try to misuse this knowledge.

This riskk in fact is a general one, each time you fill a password on internet how can you be sure than noone will read it ? (For this the best is to have a password for each different web site you are using)

This said, that this is low risk, but since in BW we want to protect members privacy, since we are open source, we are to solve this issue (which probably affects 99% of the web site in the world)

comment:6 Changed 7 years ago by TimLoal

  • Resolution set to wontfix
  • Status changed from new to closed

comment:7 Changed 7 years ago by TimLoal

  • Milestone changed from Future to Legacy Resolved
Note: See TracTickets for help on using tickets.