Why would i want to put my mysql password in the yml file?


#1

hello - i’m new!

i don’t understand - the tutorial says to edit the database.yml file and
put in the username and password, so that RoR can connect to the
database.

am i MISSING something here??

how can it be secure to put my username and password in a TEXT file,
with no encryption or anything? i thought that the days of storing u/p
in a text file had kinda gone away a while ago…

obviously i’m missing something here…any advice would be great, and
like i said i’m new (as in about one hour!)

thanks / trevor


#2

trevor wrote:

hello - i’m new!

i don’t understand - the tutorial says to edit the database.yml file and
put in the username and password, so that RoR can connect to the
database.

am i MISSING something here??

You should ask on the Rails mailing list.

http://lists.rubyonrails.org/mailman/listinfo/rails


James B.

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff


#3

Wouldn’t you have to store the password SOMEWHERE? This comes up
periodically on the list so do a search to find what discussion has
already been had.

Anyway, if you encrypt the password then somehow it would have to be
decrypted, so you’d have to keep a readable key somewhere. Bottom
line is that as long as you have correct file permissions you’ll be
fine.

Pat


#4

On 2/10/06, trevor removed_email_address@domain.invalid wrote:

Pat
i’m not being sarcastic…i just don’t quite get it…

Typically the server component (like MySQL) doesn’t store your
password at all. It merely stores enough information to verify that
you’ve presented it with the correct password, but not enough to
actually figure out what the password is, if someone stole the hard
disk.

A better analogy is that the database.yml file is like your keyboard.
At some point, you have to punch the password in with your fingers,
and if someone is watching your, they can record what you typed.

MySQL is trying to verify the identity of the person connecting as
“root”. Since software is doing that on your behalf, the password has
to be available to the software. The other alternative is to stand by
the server and get ready to type whenever it wants to open a new
database connection.


#5

Pat M. wrote:

Wouldn’t you have to store the password SOMEWHERE? This comes up
periodically on the list so do a search to find what discussion has
already been had.

Anyway, if you encrypt the password then somehow it would have to be
decrypted, so you’d have to keep a readable key somewhere. Bottom
line is that as long as you have correct file permissions you’ll be
fine.

Pat

ok, again i’m a bit confused by this. (sorry if it has been discussed,
i did a search and could not find an answer)

so if that is the case, why does basically every other password
mechanism i can think of not just use plain text, and just rely on
having “correct file permissions”. I’m curious then, where does mysql
store its username and passwords? are they available in plaintext
somewhere on my harddrive too?

i’m not being sarcastic…i just don’t quite get it…

thanks,
trevor


#6

From: “Bill K.” removed_email_address@domain.invalid

It’s kind of a client vs. server issue. The server (the database in this
case) can indeed store passwords in some hashed representation.

Sorry for being unclear here. What I meant was what Wilson B.
wrote: “[The server] merely stores enough information to verify that
you’ve presented it with the correct password, but not enough to
actually figure out what the password is, if someone stole the hard
disk.”

Regards,

Bill


#7

thanks for the clear-up, i do follow that logic

this morning i just wanted to create a form on my website and have it be
emailed to me automatically, here i am 16 hours later, installed mysql,
ruby, rails…

tomorrow is gonna be great, maybe ceo of google…
/trevor


#8

From: “trevor” removed_email_address@domain.invalid

i’m not being sarcastic…i just don’t quite get it…
It’s kind of a client vs. server issue. The server (the database in
this
case) can indeed store passwords in some hashed representation.

But the client (rails in this case) has to connect to the database and
send the clear password to the database.

So, the best rails (as a client of the database) could do, is attempt
to obscure the password (as the CVS client does in its .cvspass files.)

But obscuring the password on the client side is not really secure,
because the client has to be able to turn the obscured password back
into cleartext in order to gain access to the server (the database.)

So if the passwords are merely obscured, and your file permissions
are wrong, then anybody who can see the obscured passwords can
turn them back into cleartext with the same algorithm the legitimate
client must use in order to supply the password to the server.

So file permissions are really the only real defense (that i know of)
against passwords on the client side being seen by unauthorized
entities.

Regards,

Bill


#9

You’d probably be way better off just making a quick PHP script. No
need to install and configure ralis/mysql.

Never made a simple Ruby CGI script but I’m sure you could do it
reasonably well there too. But for a simple mail submit form PHP
feels like the much more appropriate tool for the job.

Pat


#10

Using a DataSource (like in J2EE) you will still need to store the
password in the DS definition… Any pool conexion based system will
need a password.


#11

On 2/10/06, Wilson B. removed_email_address@domain.invalid wrote:

At some point, you have to punch the password in with your fingers,
and if someone is watching your, they can record what you typed.

Exactly. If you design an authentication system for your app, chances
are you don’t store the password in the db, but instead store a hashed
version of it. Then when your user logs in, your program will hash
the pass compare to what’s in the db. I don’t know the exact
implementation, but I imagine that’s roughly what goes on when you
authenticate to MySQL.

Every single password-based authentication mechanism is going to have
some place where the password is in plain text. What you should be
trying to do is ensure that only one layer of the system has the
unencrypted password, and that you the minimum layers necessary so you
don’t have many points of failure.

Pat


#12

On Feb 11, 2006, at 6:18 AM, Stefan A. wrote:

Most app servers or frameworks like Spring allow you to
use placeholders in configuration files. Like

and then simply start the app with -Dmy.password=g3h31m

This only works if a person is starting the app at a keyboard.
If your application is starting at boot time or via some sort
of automated process, then you’ll have to stuff the command line
(with password) in a script or config file somewhere and you are right
back where you started.

Gary W.


#13

On Feb 11, 2006, at 5:18 AM, Stefan A. wrote:

and then simply start the app with -Dmy.password=g3h31m

You can do this with Rails too.

The database.yml file can have ERB escapes in it, so you can set your
password to <%= … whatever … %>. You could have the Ruby code
inside read an environment variable, for example, then just set the
variable when you invoke.

James Edward G. II


#14

removed_email_address@domain.invalid writes:

Using a DataSource (like in J2EE) you will still need to store the
password in the DS definition… Any pool conexion based system will
need a password.

Most app servers or frameworks like Spring allow you to
use placeholders in configuration files. Like

and then simply start the app with -Dmy.password=g3h31m

S.


#15

On Saturday 11 February 2006 04:18, Stefan A. wrote:

Most app servers or frameworks like Spring allow you to
use placeholders in configuration files. Like

and then simply start the app with -Dmy.password=g3h31m

One thing to be very careful of with this kind of thing is that on every
operating system I’m familiar with, command line arguments are an
incredibly insecure place to have a password. Having it stored in a
file
with the correct permissions that is read during execution is far more
preferable.


#16

On 11/02/06, Pat M. removed_email_address@domain.invalid wrote:

You’d probably be way better off just making a quick PHP script. No
need to install and configure ralis/mysql.

Be sure to take note of how PHP stores your DB connection
details too…


#17

On 11/02/06, Stefan A. removed_email_address@domain.invalid wrote:

and then simply start the app with -Dmy.password=g3h31m

Then it will show up in ‘ps’ output.


#18

On 2/12/06, Dick D. removed_email_address@domain.invalid wrote:

I was just commenting on the scope of his project. Collects some
fields and shoots of an email…there’s no need to write a Rails app
for that. If he wanted to do a bunch of other things, then sure, go
for Rails. I got off topic a bit, and just wanted to point out that
Rails was perhaps not the best tool for this job.

Pat


#19

Dick D. wrote:


Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

… and be in the shell history file. Including passwords on the command
line is a bad idea.

cheers,
Tone.