I think the quoted section is more about how passwords are stored in the
database itself than about how they're communicated during login. I
read http://dev.mysql.com/doc/refman/5.5/en/secure-connections.html to
suggest that there isn't much encryption going on at all, particularly
The standard configuration of MySQL is intended to be as fast as possible, so
encrypted connections are not used by default.
I think they can get away with that attitude because (1) SSL is
available if you really want it and (2) "localhost" is a special case
for MySQL. From http://dev.mysql.com/doc/refman/5.5/en/connecting.html:
On Unix, MySQL programs treat the host name localhost specially, in a way that
is likely different from what you expect compared to other network-based
programs. For connections to localhost, MySQL programs attempt to connect to
the local server by using a Unix socket file.
So for the special case of localhost, there's no "over the network" to
worry about. But if you're connecting to a remote machine, I think you
_should_ be at least a little concerned about passwords.
I'd be quite happy to be wrong, though. I'm pretty sure DBD::MySQL
isn't encrypting the password for transmission, but the underlying calls
to the MySQL client software might be.
dave
Paul DuBois wrote:
http://dev.mysql.com/doc/refman/5.1/en/user-names.html:
"
MySQL encrypts passwords using its own algorithm. This encryption is the same
as that implemented by thePASSWORD() SQL function but differs from that used
during the Unix login process. Unix password encryption is the same as that
implemented by the ENCRYPT() SQL function. See the descriptions of the
PASSWORD() andENCRYPT() functions in Section 11.13, “Encryption and Compression
Functions”.
From version 4.1 on, MySQL employs a stronger authentication method that has
better password protection during the connection process than in earlier
versions. It is secure even if TCP/IP packets are sniffed or the mysqldatabase
is captured. (In earlier versions, even though passwords are stored in
encrypted form in the user table, knowledge of the encrypted password value
could be used to connect to the MySQL server.) Section 5.3.2.3, “Password
Hashing in MySQL”, discusses password encryption further.
"
On Jul 6, 2010, at 5:42 AM, John Scoles wrote:
andrew...@yahoo.com wrote:
Not a 100% sure for MySql but I would think it is.
What happens first is the connection to the server is made in this case
'$database:localhost:3306' and then internally the username and password are
sent.
If someone can 'sniff' the connection between the perl program and the Server and if it is not encoded then yes it is in the clear.
I know with DBD::Oracle this connection is encrypted (at least the Pw and UID) that same should be true of MySql as I think that is part of the SQL standard is it not??
cheers
John
When connecting to a MySql server with DBI->connect:
$dsn = "dbi:mysql:$database:localhost:3306";
$dbh = DBI->connect($dsn, $username, $password)
is the password sent in the clear? If so, how can this be dealt with?
I actually don't care about hiding the plaintext password in the perl
source file or encrypting the connection with the database, I just
don't want the world to see my password when it goes out over the
network. Is that so much to ask for? I would think this would be an
obvious issue but as far as I can tell, nobody has ever asked this
question before in the history of the internet. Apparently a direct
command line connection to a MySql server will not send the password
in the clear:
mysql -u andrew732 -p -h 123.456.789.876
but even that took me several hours of googling to figure out. I'm
not new to Perl but I'm new to databases; is there a good reason that
nobody seems to care about password security when it comes to
databases? I would love to be enlightened! Thanks~
