The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

PHP PITA

Sorry wasn't really sure when to post this!

Just done a PHP/Apache/Mysql install on a machine.

Mysql Clinet API is 3.x but my Mysql install is 4.1. So i'm getting an error when connecting.

Does anybody know how to upgrade the client api for PHP? I've found pages that say you should just set up the old password but I didn't solve the problem that way before and I can't remember now :|

Thanks
Talib Kweli
Tuesday, May 30, 2006
 
 
REad the docs :)
Mysql 4.1 has a new autentication system. You can do 2 things

1.- change the passwords for the user you are connecting from to use the old password protocol (set password for user = OLD_PASSWORD('password')

2.- Use the mysqli extension, i think it has the new autorization protocol

http://dev.mysql.com/doc/refman/5.0/en/old-client.html
Masiosare Send private email
Tuesday, May 30, 2006
 
 
"Mysql Clinet API is 3.x but my Mysql install is 4.1. So i'm getting an error when connecting."

That's the same setup I have...  as Masiosare said, there are few hoops to jump through to alter the authentication.  There's also a MySQL setting that makes the old authentication the default.  You might need to do some work there.

If you are using PHP5, then use the mysqli (i for improved) extension for connecting to MySQL.  I'm not sure how well it's supported on PHP4, so I just use the old client API for that version.
Almost H. Anonymous Send private email
Tuesday, May 30, 2006
 
 
Cheers guys.

:)
Talib Kweli
Wednesday, May 31, 2006
 
 
Going around in circles here.

I can't get into mysql on the command line to SET PASSWORD gives me the same client error.

I've told mysql to use old-passwords in the my.ini file.

ARG
Talib Kweli
Wednesday, May 31, 2006
 
 
Ignore my retarded outbursts, I have managed to resolve it now. Very much appreicated
Talib Kweli
Wednesday, May 31, 2006
 
 
Talib,

What did you do? I might need to do this in the future, and I'm saving this thread in my knowledge bank.
slartibartfast Send private email
Wednesday, May 31, 2006
 
 
<rant>

So let me get this straight since I haven't touched a post-3 version of mysql.

They CHANGED THE OUTPUT FORMAT of a function that creates a ONE WAY HASH OF A PASSWORD!!!??? 

What the FUCK are these idiots thinking?  What if you based application on the PASSWORD() function and want to upgrade?  How the hell are you supposed to migrate potentially MILLIONS of UNRECOVERABLE, ONE-WAY HASHED passwords into a new "extra secure" scheme!?  Oh wait.  I'll just use OLD_PASSWORD() instead...  Great.  That is one awesome migration plan you've got there!

Pardon my language but fuck mySQL, seriously.  What a bunch of amateurs.  I'm glad I've migrated over to a real database.

</rant>
Cory R. King
Wednesday, May 31, 2006
 
 
"What the FUCK are these idiots thinking?"

Security.

"What if you based application on the PASSWORD() function and want to upgrade?"

Use the "--old-passwords" option or, as you said, change your code to OLD_PASSWORD() instead.  You can even slowly migrate your passwords to improve the security of your application: The new password hashes begin with '*' so you can determine if your looking at an old password or a new password and use the appropriate function.

I don't know, seems like they covered all the bases...  what are you ranting about again?
Almost H. Anonymous Send private email
Wednesday, May 31, 2006
 
 
Should also say that PASSWORD() has the following note about it:

"The PASSWORD() function is used by the authentication system in MySQL Server, you should NOT use it in your own applications. For that purpose, use MD5() or SHA1() instead."
Almost H. Anonymous Send private email
Wednesday, May 31, 2006
 
 
I stand by my assertion of retardedness.  You just dont *get* to change the algorithm you use for a one-way password hash function.  Period.  It is one of those things you better figure out before you write a line of code because, hon, you are stuck with it for the rest of eternity.  You can't go back.

The minute people start writing code against PASSWORD(), they are locked in.  You've written a contract with those people that you'll ALWAYS return the right value.  Now you've gone and broke something that is damn hard to easily fix.  You can't "upgrade" tens of thousands of one-way hashes unless you've got the real password.

If you think that mySQL isn't secure enough and needs a new authenticaion mechanism, that is fine.  Create a new function, SECURE_PASSWORD(), for new applications to code against.  Make the default mechanism for client authentication use the old hash algorithm and force me, via a compile option or command line switch, to turn on the new algorithm.  See?  By default, nothing breaks.  I've got to *think* about using the new stuff.  I dont have to think to keep things the same.
Cory R. King
Thursday, June 01, 2006
 
 
PS:  Sorry for the derail & rant.  I'm just bitter after having to migrate an old-school mysql app to postgres.  The code was based around the MySQL 3.0 philosophy of "Hey, JOINS are expensive so lets just put a bunch of select statements in a for-loop!".

All this hash-talk does beg the question though.  How *do* you migrate passwords into a new one-way hash algorithm?
Cory R. King
Thursday, June 01, 2006
 
 
PPS:  I checked the manuals.  Version 3.23 had no disclaimer for the PASSWORD() function.  In fact, this function can be used by at least two applications:

1) proftpd's database authentication hooks.
2) pam_mysql lets you use it too.

Bah...
Cory R. King
Thursday, June 01, 2006
 
 
"You just dont *get* to change the algorithm you use for a one-way password hash function.  Period."

Come on, it's the *internal* password hash function.  The documentation even states you're not supposed to write code against it.  Furthermore, they give you tonnes of options if you were stupid enough to do that.

It's as if you didn't read my post at all.  None of what you said really makes any sense given that I've outlined all the alternatives!

"I've got to *think* about using the new stuff.  I dont have to think to keep things the same."

I think the point was to make it the new default so people don't by-default use a password hash that is less secure.

"The code was based around the MySQL 3.0 philosophy of "Hey, JOINS are expensive so lets just put a bunch of select statements in a for-loop!"."

Ummm...  JOINs aren't expensive in any database platform including MySQL 3.0 (well certainly not compared to a bunch of selects in a for-loop).  I'm not sure how you can blame the database platform, as it sounds like you are doing, for stupid developers.

"How *do* you migrate passwords into a new one-way hash algorithm?"

I begin hashing new passwords with the algorithm immediately.  For testing passwords, I check for the asterisk in front and use the PASSWORD() or OLD_PASSWORD() depending on the result.  I could even force people with the old password to enter a new password "for security reasons" after they login but I could just as easily not bother.

Of course, this is all pretty moot since one wouldn't use PASSWORD() for hashing application passwords anyway.  I, for one, use MD5() for hashing passwords in my application with a random salt and all the stuff you're supposed to do.
Almost H. Anonymous Send private email
Thursday, June 01, 2006
 
 
slartibartfast

I just logged into mysql from the command line and SET PASSWORD as Massionaires links told me :) Works very well.

I was confused because the last time I had set this up I'm 100% sure I didn't use SET PASSWORD.

All well anyway :)

Cheers
Talib Kweli
Thursday, June 01, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz