best way to protect database logins

Hi all,
I have a php website and for every page obviously I need to access to
the database before to manage any query.
The access is made by including for each page a file (config.inc.php)
with this content:

<?php
$add='xxx.xxx.xxx.xxx';
$idb='user';
$lgn='password';
$ldb=mysql_connect($add,$idb,$lgn) or die ("logins errati");
mysql_select_db("xxx",$ldb) or die ("accesso impossible");
?>


The problem is this:

how can I hide or protect these two lines

$idb='user';
$lgn='password';

from an attacker?

Some friends have suggested me to leave 'unencrypted' these two lines
and of don't put the config.inc.php on the same folder of my website
(httpdocs) but in different folder with restricted chmod values.

What do you think?

Other tips?

Thanks

Max (ITALY)

>I have a php website and for every page obviously I need to access to
>the database before to manage any query.
>The access is made by including for each page a file (config.inc.php)
>with this content:
>
><?php
>$add='xxx.xxx.xxx.xxx';
>$idb='user';
>$lgn='password';
>$ldb=mysql_connect($add,$idb,$lgn) or die ("logins errati");
>mysql_select_db("xxx",$ldb) or die ("accesso impossible");
>?>
>
>
>The problem is this:
>
>how can I hide or protect these two lines
>
>$idb='user';
>$lgn='password';
>
>from an attacker?

First, figure out *WHAT* attacker.

The sysadmins of your (hosting company) server? Forget it. Change hosting
companies if you don't trust them.

Another customer on your shared server? Very difficult problem. The
web server and PHP probably run with the same UID for his pages AND yours.

Someone with a browser? Conventional wisdom says you put the include
file with the database info OUTSIDE the web document tree. Why? If PHP
is running, you'll see only the output of the code. If PHP is broken
(not configured correctly in Apache, sometimes happens in the middle of
code upgrades if you don't shut down the web server), it's outside the
web tree, so it won't get served. As far as chmod goes, PHP still has
to be able to read it.
>
>Some friends have suggested me to leave 'unencrypted' these two lines
>and of don't put the config.inc.php on the same folder of my website
>(httpdocs) but in different folder with restricted chmod values.

Encryption doesn't really help that much since PHP has to be able to
decrypt it.

"Fly Peter" <flypeter@alice.it> wrote in message
news:45db842f$0$37203$4fafbaef@reader3.news.tin.it ...
> Hi all,
> I have a php website and for every page obviously I need to access to the
> database before to manage any query.
> The access is made by including for each page a file (config.inc.php) with
> this content:
>
> <?php
> $add='xxx.xxx.xxx.xxx';
> $idb='user';
> $lgn='password';
> $ldb=mysql_connect($add,$idb,$lgn) or die ("logins errati");
> mysql_select_db("xxx",$ldb) or die ("accesso impossible");
> ?>
>
>


How bout you store the password's hash instead of the actual password. This
way it is very unlikely that any user can recover the true password that
produces the hash. You can do this for the login name too. That is, you
never deal directly with the username and password except when converting to
there hash's to look up.

You store the hashes in the database and when you need to check for
permissions you just compute the hash and check and see if it matches. If
they need to change there password then you just compute the hash and check
and see if its the same hash in the database.

There is a slight issue because of collisions but that shouldn't be a real
issue. Ofcourse this method might become a huge issue in a few years but it
should be easy to change. (just require the user to change his password when
the time has come and use a different algorithm)

You could even do some serious hashing that would make it very complicated
for the user. (don't just use the out of the box hashing algorithms but
modify them so they variants. (such as using the login name to randomize the
hash. Or every user that has the letters s and q in the log in name will use
a different hash. )

Ofcourse you'll need to somehow keep that code as hidden as possible so that
server admins can't see it unless you really trust them. (If it has to be
100% secure then you'll have to host the server yourself).

I think its a very bad idea to store the exact username and password because
many people use the same logins across different sites. You can use a hash
that accomplishes the same feat that is essentially an encryption that is
very hard to unencrypt. Luckily you don't need to unencrypt to check for a
valid user.

Jon

Jon Slaughter wrote:
> "Fly Peter" <flypeter@alice.it> wrote in message
> news:45db842f$0$37203$4fafbaef@reader3.news.tin.it ...
>> Hi all,
>> I have a php website and for every page obviously I need to access to the
>> database before to manage any query.
>> The access is made by including for each page a file (config.inc.php) with
>> this content:
>>
>> <?php
>> $add='xxx.xxx.xxx.xxx';
>> $idb='user';
>> $lgn='password';
>> $ldb=mysql_connect($add,$idb,$lgn) or die ("logins errati");
>> mysql_select_db("xxx",$ldb) or die ("accesso impossible");
>> ?>
>>
>>
>
>
> How bout you store the password's hash instead of the actual password. This
> way it is very unlikely that any user can recover the true password that
> produces the hash. You can do this for the login name too. That is, you
> never deal directly with the username and password except when converting to
> there hash's to look up.
>
> You store the hashes in the database and when you need to check for
> permissions you just compute the hash and check and see if it matches. If
> they need to change there password then you just compute the hash and check
> and see if its the same hash in the database.
>
> There is a slight issue because of collisions but that shouldn't be a real
> issue. Ofcourse this method might become a huge issue in a few years but it
> should be easy to change. (just require the user to change his password when
> the time has come and use a different algorithm)
>
> You could even do some serious hashing that would make it very complicated
> for the user. (don't just use the out of the box hashing algorithms but
> modify them so they variants. (such as using the login name to randomize the
> hash. Or every user that has the letters s and q in the log in name will use
> a different hash. )
>
> Ofcourse you'll need to somehow keep that code as hidden as possible so that
> server admins can't see it unless you really trust them. (If it has to be
> 100% secure then you'll have to host the server yourself).
>
> I think its a very bad idea to store the exact username and password because
> many people use the same logins across different sites. You can use a hash
> that accomplishes the same feat that is essentially an encryption that is
> very hard to unencrypt. Luckily you don't need to unencrypt to check for a
> valid user.
>
> Jon
>
>

Jon,

You're missing the point here. He isn't talking about one of his user's
userids/passwords - he's talking about the one to access MySQL. These
cannot be hashed when he sends them to MySQL. And if they're encrypted,
PHP needs to be able do decrypt them - so the decrypt code will be
there, also.

The best way is to keep the file in a directory below the document_root.
Even on a shared server this will not be accessible by other users if
the hosting company has set up their security properly.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:4oCdnfWA84VDKUbYnZ2dnUVZ_oDinZ2d@comcast.com. ..
> Jon Slaughter wrote:
>> "Fly Peter" <flypeter@alice.it> wrote in message
>> news:45db842f$0$37203$4fafbaef@reader3.news.tin.it ...
>>> Hi all,
>>> I have a php website and for every page obviously I need to access to
>>> the database before to manage any query.
>>> The access is made by including for each page a file (config.inc.php)
>>> with this content:
>>>
>>> <?php
>>> $add='xxx.xxx.xxx.xxx';
>>> $idb='user';
>>> $lgn='password';
>>> $ldb=mysql_connect($add,$idb,$lgn) or die ("logins errati");
>>> mysql_select_db("xxx",$ldb) or die ("accesso impossible");
>>> ?>
>>>
>>>
>>
>>
>> How bout you store the password's hash instead of the actual password.
>> This way it is very unlikely that any user can recover the true password
>> that produces the hash. You can do this for the login name too. That is,
>> you never deal directly with the username and password except when
>> converting to there hash's to look up.
>>
>> You store the hashes in the database and when you need to check for
>> permissions you just compute the hash and check and see if it matches. If
>> they need to change there password then you just compute the hash and
>> check and see if its the same hash in the database.
>>
>> There is a slight issue because of collisions but that shouldn't be a
>> real issue. Ofcourse this method might become a huge issue in a few years
>> but it should be easy to change. (just require the user to change his
>> password when the time has come and use a different algorithm)
>>
>> You could even do some serious hashing that would make it very
>> complicated for the user. (don't just use the out of the box hashing
>> algorithms but modify them so they variants. (such as using the login
>> name to randomize the hash. Or every user that has the letters s and q in
>> the log in name will use a different hash. )
>>
>> Ofcourse you'll need to somehow keep that code as hidden as possible so
>> that server admins can't see it unless you really trust them. (If it has
>> to be 100% secure then you'll have to host the server yourself).
>>
>> I think its a very bad idea to store the exact username and password
>> because many people use the same logins across different sites. You can
>> use a hash that accomplishes the same feat that is essentially an
>> encryption that is very hard to unencrypt. Luckily you don't need to
>> unencrypt to check for a valid user.
>>
>> Jon
>
> Jon,
>
> You're missing the point here. He isn't talking about one of his user's
> userids/passwords - he's talking about the one to access MySQL. These
> cannot be hashed when he sends them to MySQL. And if they're encrypted,
> PHP needs to be able do decrypt them - so the decrypt code will be there,
> also.
>

No, you don' t have to decrypt anything. You are only comparing hashes.
You cannot descript a hash.

---
User creates account wtih name "Joe"
Hash algorithm converts "Joe" to "3dfieif"
Hash is checked for existance in DB
Hash is stored in DB if it doesn't exist

Password is "MyNuts" and hashed as "394892" and stored in DB.

--
User logs in with "Joe"
Hash algorithm converts "Joe" to "3dfieif"
Hash is checked for existance in DB
If found then that means the user Joe exists in the DB.
Password is "MyNuts" and hashed as "394892" and checked against the hashed
password in the DB.

The only thing in the database are hashes.

"3dfieif", "394892"

This would mean "Joe", "MyNuts" but since there is no practical way to know
that know one can know determine this. They cannot even enter those as the
name and password because they will be hashed and converted to something
else. The only way for the user name and password to get stolen would be for
someone to do something at the moment of login.

You can even give someone the DB of hashes. They won't be able to do much
with it.

I could hash my username and password for all my accounts and then give the
to you and you won't be able to do a damn thing with them. First off you
don't know what hash I used. Even if you did it is impractical for you to
recover there meaning. Ofcourse you might get lucky and the hash algorithms
are not perfect but chances are you won't be able to do anything. (and one
can make it much more secure by using dynamic hashing. The only way you
could even get close is if you had access to the hashing algorithms)


> The best way is to keep the file in a directory below the document_root.
> Even on a shared server this will not be accessible by other users if the
> hosting company has set up their security properly.
>

Yeah, but even if this is true then it doesn't matter much because its never
100% secure and the hosting company can easily get the passwords of people
and use them. (do you really want your password sitting on some database
when there is no reason?)

Its not passwords that are important for security rights but checking
passwords. Since a hasing algorithm is one-to-one you can do this without
having to actually check the real password.
i.e.

if phi(x) is your hashing algorithm

then phi("Joe") = y

you just store y. If you need to check then later on you just do phi("Joe")
again and check in the database for y. "Joe" is not stored in the database.

Its sorta like PGP but no messaging is sent. It would be much more secure
if the hash was done on the client side(although it would be easier for
people to hack because they could then easily get at the code) because then
the actual login information is never sent across the wire. Even if someone
sniffed the tranmission they would not be able to do much with it. (Sorta
like PGP)

Obviously its a good idea to keep the DB information and scripts secure but
thats only part of it.

Jon

On 21 Feb, 07:46, "Jon Slaughter" <Jon_Slaugh...@Hotmail.com> wrote:
> "Jerry Stuckle" <jstuck...@attglobal.net> wrote in message
>
> news:4oCdnfWA84VDKUbYnZ2dnUVZ_oDinZ2d@comcast.com. ..
>
>
>
>
>
> > Jon Slaughter wrote:
> >> "Fly Peter" <flype...@alice.it> wrote in message
> >>news:45db842f$0$37203$4fafbaef@reader3.news.tin. it...
> >>> Hi all,
> >>> I have a php website and for every page obviously I need to access to
> >>> the database before to manage any query.
> >>> The access is made by including for each page a file (config.inc.php)
> >>> with this content:
>
> >>> <?php
> >>> $add='xxx.xxx.xxx.xxx';
> >>> $idb='user';
> >>> $lgn='password';
> >>> $ldb=mysql_connect($add,$idb,$lgn) or die ("logins errati");
> >>> mysql_select_db("xxx",$ldb) or die ("accesso impossible");
> >>> ?>
>
> >> How bout you store the password's hash instead of the actual password.
> >> This way it is very unlikely that any user can recover the true password
> >> that produces the hash. You can do this for the login name too. That is,
> >> you never deal directly with the username and password except when
> >> converting to there hash's to look up.
>
> >> You store the hashes in the database and when you need to check for
> >> permissions you just compute the hash and check and see if it matches. If
> >> they need to change there password then you just compute the hash and
> >> check and see if its the same hash in the database.
>
> >> There is a slight issue because of collisions but that shouldn't be a
> >> real issue. Ofcourse this method might become a huge issue in a few years
> >> but it should be easy to change. (just require the user to change his
> >> password when the time has come and use a different algorithm)
>
> >> You could even do some serious hashing that would make it very
> >> complicated for the user. (don't just use the out of the box hashing
> >> algorithms but modify them so they variants. (such as using the login
> >> name to randomize the hash. Or every user that has the letters s and q in
> >> the log in name will use a different hash. )
>
> >> Ofcourse you'll need to somehow keep that code as hidden as possible so
> >> that server admins can't see it unless you really trust them. (If it has
> >> to be 100% secure then you'll have to host the server yourself).
>
> >> I think its a very bad idea to store the exact username and password
> >> because many people use the same logins across different sites. You can
> >> use a hash that accomplishes the same feat that is essentially an
> >> encryption that is very hard to unencrypt. Luckily you don't need to
> >> unencrypt to check for a valid user.
>
> >> Jon
>
> > Jon,
>
> > You're missing the point here. He isn't talking about one of his user's
> > userids/passwords - he's talking about the one to access MySQL. These
> > cannot be hashed when he sends them to MySQL. And if they're encrypted,
> > PHP needs to be able do decrypt them - so the decrypt code will be there,
> > also.
>
> No, you don' t have to decrypt anything. You are only comparing hashes.
> You cannot descript a hash.
>
> ---
> User creates account wtih name "Joe"
> Hash algorithm converts "Joe" to "3dfieif"
> Hash is checked for existance in DB
> Hash is stored in DB if it doesn't exist
>
> Password is "MyNuts" and hashed as "394892" and stored in DB.
>
> --
> User logs in with "Joe"
> Hash algorithm converts "Joe" to "3dfieif"
> Hash is checked for existance in DB
> If found then that means the user Joe exists in the DB.
> Password is "MyNuts" and hashed as "394892" and checked against the hashed
> password in the DB.
>
> The only thing in the database are hashes.
>
> "3dfieif", "394892"
>
> This would mean "Joe", "MyNuts" but since there is no practical way to know
> that know one can know determine this. They cannot even enter those as the
> name and password because they will be hashed and converted to something
> else. The only way for the user name and password to get stolen would be for
> someone to do something at the moment of login.
>
> You can even give someone the DB of hashes. They won't be able to do much
> with it.
>
> I could hash my username and password for all my accounts and then give the
> to you and you won't be able to do a damn thing with them. First off you
> don't know what hash I used. Even if you did it is impractical for you to
> recover there meaning. Ofcourse you might get lucky and the hash algorithms
> are not perfect but chances are you won't be able to do anything. (and one
> can make it much more secure by using dynamic hashing. The only way you
> could even get close is if you had access to the hashing algorithms)
>
> > The best way is to keep the file in a directory below the document_root.
> > Even on a shared server this will not be accessible by other users if the
> > hosting company has set up their security properly.
>
> Yeah, but even if this is true then it doesn't matter much because its never
> 100% secure and the hosting company can easily get the passwords of people
> and use them. (do you really want your password sitting on some database
> when there is no reason?)
>
> Its not passwords that are important for security rights but checking
> passwords. Since a hasing algorithm is one-to-one you can do this without
> having to actually check the real password.
> i.e.
>
> if phi(x) is your hashing algorithm
>
> then phi("Joe") = y
>
> you just store y. If you need to check then later on you just do phi("Joe")
> again and check in the database for y. "Joe" is not stored in the database.
>
> Its sorta like PGP but no messaging is sent. It would be much more secure
> if the hash was done on the client side(although it would be easier for
> people to hack because they could then easily get at the code) because then
> the actual login information is never sent across the wire. Even if someone
> sniffed the tranmission they would not be able to do much with it. (Sorta
> like PGP)
>
> Obviously its a good idea to keep the DB information and scripts secure but
> thats only part of it.
>
> Jon- Hide quoted text -
>
> - Show quoted text -

Jon, did you actually bother to read Jerry's post?

How can the OP check for the existance of the hash in the DB (table
might be a better word) if he hasn't logged into MySQL yet?
How can he log into MySQL if he doesn't have a userid and password for
it?
MySQL will NOT accept the hash of a userid and password as login
credentials to MySQL, it wants the MySQL userid and password.

You would do well to follow the advice of Mark Twain:
"It is better to keep your mouth closed and let people think you are a
fool than to open it and remove all doubt."

"Captain Paralytic" <paul_lautman@yahoo.com> wrote in message
news:1172051269.266088.91210@s48g2000cws.googlegro ups.com...
> On 21 Feb, 07:46, "Jon Slaughter" <Jon_Slaugh...@Hotmail.com> wrote:
>> "Jerry Stuckle" <jstuck...@attglobal.net> wrote in message
>>
>> news:4oCdnfWA84VDKUbYnZ2dnUVZ_oDinZ2d@comcast.com. ..
>>
>>
>>
>>
>>
>> > Jon Slaughter wrote:
>> >> "Fly Peter" <flype...@alice.it> wrote in message
>> >>news:45db842f$0$37203$4fafbaef@reader3.news.tin. it...
>> >>> Hi all,
>> >>> I have a php website and for every page obviously I need to access to
>> >>> the database before to manage any query.
>> >>> The access is made by including for each page a file (config.inc.php)
>> >>> with this content:
>>
>> >>> <?php
>> >>> $add='xxx.xxx.xxx.xxx';
>> >>> $idb='user';
>> >>> $lgn='password';
>> >>> $ldb=mysql_connect($add,$idb,$lgn) or die ("logins errati");
>> >>> mysql_select_db("xxx",$ldb) or die ("accesso impossible");
>> >>> ?>
>>
>> >> How bout you store the password's hash instead of the actual password.
>> >> This way it is very unlikely that any user can recover the true
>> >> password
>> >> that produces the hash. You can do this for the login name too. That
>> >> is,
>> >> you never deal directly with the username and password except when
>> >> converting to there hash's to look up.
>>
>> >> You store the hashes in the database and when you need to check for
>> >> permissions you just compute the hash and check and see if it matches.
>> >> If
>> >> they need to change there password then you just compute the hash and
>> >> check and see if its the same hash in the database.
>>
>> >> There is a slight issue because of collisions but that shouldn't be a
>> >> real issue. Ofcourse this method might become a huge issue in a few
>> >> years
>> >> but it should be easy to change. (just require the user to change his
>> >> password when the time has come and use a different algorithm)
>>
>> >> You could even do some serious hashing that would make it very
>> >> complicated for the user. (don't just use the out of the box hashing
>> >> algorithms but modify them so they variants. (such as using the login
>> >> name to randomize the hash. Or every user that has the letters s and q
>> >> in
>> >> the log in name will use a different hash. )
>>
>> >> Ofcourse you'll need to somehow keep that code as hidden as possible
>> >> so
>> >> that server admins can't see it unless you really trust them. (If it
>> >> has
>> >> to be 100% secure then you'll have to host the server yourself).
>>
>> >> I think its a very bad idea to store the exact username and password
>> >> because many people use the same logins across different sites. You
>> >> can
>> >> use a hash that accomplishes the same feat that is essentially an
>> >> encryption that is very hard to unencrypt. Luckily you don't need to
>> >> unencrypt to check for a valid user.
>>
>> >> Jon
>>
>> > Jon,
>>
>> > You're missing the point here. He isn't talking about one of his
>> > user's
>> > userids/passwords - he's talking about the one to access MySQL. These
>> > cannot be hashed when he sends them to MySQL. And if they're
>> > encrypted,
>> > PHP needs to be able do decrypt them - so the decrypt code will be
>> > there,
>> > also.
>>
>> No, you don' t have to decrypt anything. You are only comparing hashes.
>> You cannot descript a hash.
>>
>> ---
>> User creates account wtih name "Joe"
>> Hash algorithm converts "Joe" to "3dfieif"
>> Hash is checked for existance in DB
>> Hash is stored in DB if it doesn't exist
>>
>> Password is "MyNuts" and hashed as "394892" and stored in DB.
>>
>> --
>> User logs in with "Joe"
>> Hash algorithm converts "Joe" to "3dfieif"
>> Hash is checked for existance in DB
>> If found then that means the user Joe exists in the DB.
>> Password is "MyNuts" and hashed as "394892" and checked against the
>> hashed
>> password in the DB.
>>
>> The only thing in the database are hashes.
>>
>> "3dfieif", "394892"
>>
>> This would mean "Joe", "MyNuts" but since there is no practical way to
>> know
>> that know one can know determine this. They cannot even enter those as
>> the
>> name and password because they will be hashed and converted to something
>> else. The only way for the user name and password to get stolen would be
>> for
>> someone to do something at the moment of login.
>>
>> You can even give someone the DB of hashes. They won't be able to do much
>> with it.
>>
>> I could hash my username and password for all my accounts and then give
>> the
>> to you and you won't be able to do a damn thing with them. First off you
>> don't know what hash I used. Even if you did it is impractical for you to
>> recover there meaning. Ofcourse you might get lucky and the hash
>> algorithms
>> are not perfect but chances are you won't be able to do anything. (and
>> one
>> can make it much more secure by using dynamic hashing. The only way you
>> could even get close is if you had access to the hashing algorithms)
>>
>> > The best way is to keep the file in a directory below the
>> > document_root.
>> > Even on a shared server this will not be accessible by other users if
>> > the
>> > hosting company has set up their security properly.
>>
>> Yeah, but even if this is true then it doesn't matter much because its
>> never
>> 100% secure and the hosting company can easily get the passwords of
>> people
>> and use them. (do you really want your password sitting on some database
>> when there is no reason?)
>>
>> Its not passwords that are important for security rights but checking
>> passwords. Since a hasing algorithm is one-to-one you can do this without
>> having to actually check the real password.
>> i.e.
>>
>> if phi(x) is your hashing algorithm
>>
>> then phi("Joe") = y
>>
>> you just store y. If you need to check then later on you just do
>> phi("Joe")
>> again and check in the database for y. "Joe" is not stored in the
>> database.
>>
>> Its sorta like PGP but no messaging is sent. It would be much more
>> secure
>> if the hash was done on the client side(although it would be easier for
>> people to hack because they could then easily get at the code) because
>> then
>> the actual login information is never sent across the wire. Even if
>> someone
>> sniffed the tranmission they would not be able to do much with it.
>> (Sorta
>> like PGP)
>>
>> Obviously its a good idea to keep the DB information and scripts secure
>> but
>> thats only part of it.
>>
>> Jon- Hide quoted text -
>>
>> - Show quoted text -
>
> Jon, did you actually bother to read Jerry's post?
>
> How can the OP check for the existance of the hash in the DB (table
> might be a better word) if he hasn't logged into MySQL yet?
> How can he log into MySQL if he doesn't have a userid and password for
> it?
> MySQL will NOT accept the hash of a userid and password as login
> credentials to MySQL, it wants the MySQL userid and password.
>

Um, so your saying that he will allow remote users to access the DB
directly? Thats nonsense. If he is using a web interface to the DB then do
you think that the DB cannot viewed by the administrators? No matter where
he hides files or whatever he does with permissions they can get it. Theres
no way to secure anything from the admin. So whats your point?

Even if I'm mis-interpreted the OP this does not mean that the idea is wrong
or bad. I never said MySQL took hash values for log in information. I
assume since he is doing a php web site that he is writing a database for
use on his web site. His security issues are only with the remote users. He
cannot secure it from the admin(well, maybe in some ways but nothing that is
normally done).

> You would do well to follow the advice of Mark Twain:
> "It is better to keep your mouth closed and let people think you are a
> fool than to open it and remove all doubt."
>

And you might want to follow the quote:

"Arrogance diminishes wisdom."

or even

"The truest characters of ignorance are vanity, and pride and arrogance."

>>> > You're missing the point here. He isn't talking about one of his
>>> > user's
>>> > userids/passwords - he's talking about the one to access MySQL. These
>>> > cannot be hashed when he sends them to MySQL. And if they're
>>> > encrypted,
>>> > PHP needs to be able do decrypt them - so the decrypt code will be
>>> > there,
>>> > also.
>>>
>>> No, you don' t have to decrypt anything. You are only comparing hashes.
>>> You cannot descript a hash.
>>>
>>> ---
>>> User creates account wtih name "Joe"
>>> Hash algorithm converts "Joe" to "3dfieif"
>>> Hash is checked for existance in DB
>>> Hash is stored in DB if it doesn't exist
>>>
>>> Password is "MyNuts" and hashed as "394892" and stored in DB.
>>>
>>> --
>>> User logs in with "Joe"
>>> Hash algorithm converts "Joe" to "3dfieif"
>>> Hash is checked for existance in DB
>>> If found then that means the user Joe exists in the DB.
>>> Password is "MyNuts" and hashed as "394892" and checked against the
>>> hashed
>>> password in the DB.
>>>
>>> The only thing in the database are hashes.
>>>
>>> "3dfieif", "394892"
>>>
>>> This would mean "Joe", "MyNuts" but since there is no practical way to
>>> know
>>> that know one can know determine this. They cannot even enter those as
>>> the
>>> name and password because they will be hashed and converted to something
>>> else. The only way for the user name and password to get stolen would be
>>> for
>>> someone to do something at the moment of login.
>>>
>>> You can even give someone the DB of hashes. They won't be able to do much
>>> with it.
>>>
>>> I could hash my username and password for all my accounts and then give
>>> the
>>> to you and you won't be able to do a damn thing with them. First off you
>>> don't know what hash I used. Even if you did it is impractical for you to
>>> recover there meaning. Ofcourse you might get lucky and the hash
>>> algorithms
>>> are not perfect but chances are you won't be able to do anything. (and
>>> one
>>> can make it much more secure by using dynamic hashing. The only way you
>>> could even get close is if you had access to the hashing algorithms)
>>>
>>> > The best way is to keep the file in a directory below the
>>> > document_root.
>>> > Even on a shared server this will not be accessible by other users if
>>> > the
>>> > hosting company has set up their security properly.
>>>
>>> Yeah, but even if this is true then it doesn't matter much because its
>>> never
>>> 100% secure and the hosting company can easily get the passwords of
>>> people
>>> and use them. (do you really want your password sitting on some database
>>> when there is no reason?)
>>>
>>> Its not passwords that are important for security rights but checking
>>> passwords. Since a hasing algorithm is one-to-one you can do this without
>>> having to actually check the real password.
>>> i.e.
>>>
>>> if phi(x) is your hashing algorithm
>>>
>>> then phi("Joe") = y
>>>
>>> you just store y. If you need to check then later on you just do
>>> phi("Joe")
>>> again and check in the database for y. "Joe" is not stored in the
>>> database.
>>>
>>> Its sorta like PGP but no messaging is sent. It would be much more
>>> secure
>>> if the hash was done on the client side(although it would be easier for
>>> people to hack because they could then easily get at the code) because
>>> then
>>> the actual login information is never sent across the wire. Even if
>>> someone
>>> sniffed the tranmission they would not be able to do much with it.
>>> (Sorta
>>> like PGP)
>>>
>>> Obviously its a good idea to keep the DB information and scripts secure
>>> but
>>> thats only part of it.
>>>
>>> Jon- Hide quoted text -
>>>
>>> - Show quoted text -
>>
>> Jon, did you actually bother to read Jerry's post?
>>
>> How can the OP check for the existance of the hash in the DB (table
>> might be a better word) if he hasn't logged into MySQL yet?
>> How can he log into MySQL if he doesn't have a userid and password for
>> it?
>> MySQL will NOT accept the hash of a userid and password as login
>> credentials to MySQL, it wants the MySQL userid and password.
>>
>
>Um, so your saying that he will allow remote users to access the DB
>directly? Thats nonsense. If he is using a web interface to the DB then do
>you think that the DB cannot viewed by the administrators? No matter where
>he hides files or whatever he does with permissions they can get it. Theres
>no way to secure anything from the admin. So whats your point?

You still want a way to secure the MySQL passwords from users with
browsers.

>Even if I'm mis-interpreted the OP this does not mean that the idea is wrong
>or bad. I never said MySQL took hash values for log in information. I
>assume since he is doing a php web site that he is writing a database for
>use on his web site. His security issues are only with the remote users. He
>cannot secure it from the admin(well, maybe in some ways but nothing that is
>normally done).

It hasn't been established that this site will even *HAVE* individual
user logins. Many search engines don't. However, search engines
are likely to use databases and they don't want random users altering
the data.

>> You would do well to follow the advice of Mark Twain:
>> "It is better to keep your mouth closed and let people think you are a
>> fool than to open it and remove all doubt."
>>
>
>And you might want to follow the quote:
>
>"Arrogance diminishes wisdom."
>
>or even
>
>"The truest characters of ignorance are vanity, and pride and arrogance."

On 21 Feb, 10:13, "Jon Slaughter" <Jon_Slaugh...@Hotmail.com> wrote:
> "Captain Paralytic" <paul_laut...@yahoo.com> wrote in message
>
> news:1172051269.266088.91210@s48g2000cws.googlegro ups.com...
>
>
>
>
>
> > On 21 Feb, 07:46, "Jon Slaughter" <Jon_Slaugh...@Hotmail.com> wrote:
> >> "Jerry Stuckle" <jstuck...@attglobal.net> wrote in message
>
> >>news:4oCdnfWA84VDKUbYnZ2dnUVZ_oDinZ2d@comcast.co m...
>
> >> > Jon Slaughter wrote:
> >> >> "Fly Peter" <flype...@alice.it> wrote in message
> >> >>news:45db842f$0$37203$4fafbaef@reader3.news.tin. it...
> >> >>> Hi all,
> >> >>> I have a php website and for every page obviously I need to access to
> >> >>> the database before to manage any query.
> >> >>> The access is made by including for each page a file (config.inc.php)
> >> >>> with this content:
>
> >> >>> <?php
> >> >>> $add='xxx.xxx.xxx.xxx';
> >> >>> $idb='user';
> >> >>> $lgn='password';
> >> >>> $ldb=mysql_connect($add,$idb,$lgn) or die ("logins errati");
> >> >>> mysql_select_db("xxx",$ldb) or die ("accesso impossible");
> >> >>> ?>
>
> >> >> How bout you store the password's hash instead of the actual password.
> >> >> This way it is very unlikely that any user can recover the true
> >> >> password
> >> >> that produces the hash. You can do this for the login name too. That
> >> >> is,
> >> >> you never deal directly with the username and password except when
> >> >> converting to there hash's to look up.
>
> >> >> You store the hashes in the database and when you need to check for
> >> >> permissions you just compute the hash and check and see if it matches.
> >> >> If
> >> >> they need to change there password then you just compute the hash and
> >> >> check and see if its the same hash in the database.
>
> >> >> There is a slight issue because of collisions but that shouldn't be a
> >> >> real issue. Ofcourse this method might become a huge issue in a few
> >> >> years
> >> >> but it should be easy to change. (just require the user to change his
> >> >> password when the time has come and use a different algorithm)
>
> >> >> You could even do some serious hashing that would make it very
> >> >> complicated for the user. (don't just use the out of the box hashing
> >> >> algorithms but modify them so they variants. (such as using the login
> >> >> name to randomize the hash. Or every user that has the letters s and q
> >> >> in
> >> >> the log in name will use a different hash. )
>
> >> >> Ofcourse you'll need to somehow keep that code as hidden as possible
> >> >> so
> >> >> that server admins can't see it unless you really trust them. (If it
> >> >> has
> >> >> to be 100% secure then you'll have to host the server yourself).
>
> >> >> I think its a very bad idea to store the exact username and password
> >> >> because many people use the same logins across different sites. You
> >> >> can
> >> >> use a hash that accomplishes the same feat that is essentially an
> >> >> encryption that is very hard to unencrypt. Luckily you don't need to
> >> >> unencrypt to check for a valid user.
>
> >> >> Jon
>
> >> > Jon,
>
> >> > You're missing the point here. He isn't talking about one of his
> >> > user's
> >> > userids/passwords - he's talking about the one to access MySQL. These
> >> > cannot be hashed when he sends them to MySQL. And if they're
> >> > encrypted,
> >> > PHP needs to be able do decrypt them - so the decrypt code will be
> >> > there,
> >> > also.
>
> >> No, you don' t have to decrypt anything. You are only comparing hashes.
> >> You cannot descript a hash.
>
> >> ---
> >> User creates account wtih name "Joe"
> >> Hash algorithm converts "Joe" to "3dfieif"
> >> Hash is checked for existance in DB
> >> Hash is stored in DB if it doesn't exist
>
> >> Password is "MyNuts" and hashed as "394892" and stored in DB.
>
> >> --
> >> User logs in with "Joe"
> >> Hash algorithm converts "Joe" to "3dfieif"
> >> Hash is checked for existance in DB
> >> If found then that means the user Joe exists in the DB.
> >> Password is "MyNuts" and hashed as "394892" and checked against the
> >> hashed
> >> password in the DB.
>
> >> The only thing in the database are hashes.
>
> >> "3dfieif", "394892"
>
> >> This would mean "Joe", "MyNuts" but since there is no practical way to
> >> know
> >> that know one can know determine this. They cannot even enter those as
> >> the
> >> name and password because they will be hashed and converted to something
> >> else. The only way for the user name and password to get stolen would be
> >> for
> >> someone to do something at the moment of login.
>
> >> You can even give someone the DB of hashes. They won't be able to do much
> >> with it.
>
> >> I could hash my username and password for all my accounts and then give
> >> the
> >> to you and you won't be able to do a damn thing with them. First off you
> >> don't know what hash I used. Even if you did it is impractical for you to
> >> recover there meaning. Ofcourse you might get lucky and the hash
> >> algorithms
> >> are not perfect but chances are you won't be able to do anything. (and
> >> one
> >> can make it much more secure by using dynamic hashing. The only way you
> >> could even get close is if you had access to the hashing algorithms)
>
> >> > The best way is to keep the file in a directory below the
> >> > document_root.
> >> > Even on a shared server this will not be accessible by other users if
> >> > the
> >> > hosting company has set up their security properly.
>
> >> Yeah, but even if this is true then it doesn't matter much because its
> >> never
> >> 100% secure and the hosting company can easily get the passwords of
> >> people
> >> and use them. (do you really want your password sitting on some database
> >> when there is no reason?)
>
> >> Its not passwords that are important for security rights but checking
> >> passwords. Since a hasing algorithm is one-to-one you can do this without
> >> having to actually check the real password.
> >> i.e.
>
> >> if phi(x) is your hashing algorithm
>
> >> then phi("Joe") = y
>
> >> you just store y. If you need to check then later on you just do
> >> phi("Joe")
> >> again and check in the database for y. "Joe" is not stored in the
> >> database.
>
> >> Its sorta like PGP but no messaging is sent. It would be much more
> >> secure
> >> if the hash was done on the client side(although it would be easier for
> >> people to hack because they could then easily get at the code) because
> >> then
> >> the actual login information is never sent across the wire. Even if
> >> someone
> >> sniffed the tranmission they would not be able to do much with it.
> >> (Sorta
> >> like PGP)
>
> >> Obviously its a good idea to keep the DB information and scripts secure
> >> but
> >> thats only part of it.
>
> >> Jon- Hide quoted text -
>
> >> - Show quoted text -
>
> > Jon, did you actually bother to read Jerry's post?
>
> > How can the OP check for the existance of the hash in the DB (table
> > might be a better word) if he hasn't logged into MySQL yet?
> > How can he log into MySQL if he doesn't have a userid and password for
> > it?
> > MySQL will NOT accept the hash of a userid and password as login
> > credentials to MySQL, it wants the MySQL userid and password.
>
> Um, so your saying that he will allow remote users to access the DB
> directly? Thats nonsense. If he is using a web interface to the DB then do
> you think that the DB cannot viewed by the administrators? No matter where
> he hides files or whatever he does with permissions they can get it. Theres
> no way to secure anything from the admin. So whats your point?
>
> Even if I'm mis-interpreted the OP this does not mean that the idea is wrong
> or bad. I never said MySQL took hash values for log in information. I
> assume since he is doing a php web site that he is writing a database for
> use on his web site. His security issues are only with the remote users. He
> cannot secure it from the admin(well, maybe in some ways but nothing that is
> normally done).
>
> > You would do well to follow the advice of Mark Twain:
> > "It is better to keep your mouth closed and let people think you are a
> > fool than to open it and remove all doubt."
>
> And you might want to follow the quote:
>
> "Arrogance diminishes wisdom."
>
> or even
>
> "The truest characters of ignorance are vanity, and pride and arrogance."- Hide quoted text -
>
> - Show quoted text -

Gordon had already discussed the question of from whom the stuff was
to be "protected" in the second post in this thread.
The OP quite plainly explained and demonstrated with sample code, that
the uid/pw to which he was referring was the MySQL one.
However "right" your idea is/was, it has nothing to do with the OPs
question, a point that you seem intent on ignoring.

"Gordon Burditt" <gordon@hammy.burditt.org> wrote in message
news:12to7p75je3c216@corp.supernews.com...
>>>> > You're missing the point here. He isn't talking about one of his
>>>> > user's
>>>> > userids/passwords - he's talking about the one to access MySQL.
>>>> > These
>>>> > cannot be hashed when he sends them to MySQL. And if they're
>>>> > encrypted,
>>>> > PHP needs to be able do decrypt them - so the decrypt code will be
>>>> > there,
>>>> > also.
>>>>
>>>> No, you don' t have to decrypt anything. You are only comparing
>>>> hashes.
>>>> You cannot descript a hash.
>>>>
>>>> ---
>>>> User creates account wtih name "Joe"
>>>> Hash algorithm converts "Joe" to "3dfieif"
>>>> Hash is checked for existance in DB
>>>> Hash is stored in DB if it doesn't exist
>>>>
>>>> Password is "MyNuts" and hashed as "394892" and stored in DB.
>>>>
>>>> --
>>>> User logs in with "Joe"
>>>> Hash algorithm converts "Joe" to "3dfieif"
>>>> Hash is checked for existance in DB
>>>> If found then that means the user Joe exists in the DB.
>>>> Password is "MyNuts" and hashed as "394892" and checked against the
>>>> hashed
>>>> password in the DB.
>>>>
>>>> The only thing in the database are hashes.
>>>>
>>>> "3dfieif", "394892"
>>>>
>>>> This would mean "Joe", "MyNuts" but since there is no practical way to
>>>> know
>>>> that know one can know determine this. They cannot even enter those as
>>>> the
>>>> name and password because they will be hashed and converted to
>>>> something
>>>> else. The only way for the user name and password to get stolen would
>>>> be
>>>> for
>>>> someone to do something at the moment of login.
>>>>
>>>> You can even give someone the DB of hashes. They won't be able to do
>>>> much
>>>> with it.
>>>>
>>>> I could hash my username and password for all my accounts and then give
>>>> the
>>>> to you and you won't be able to do a damn thing with them. First off
>>>> you
>>>> don't know what hash I used. Even if you did it is impractical for you
>>>> to
>>>> recover there meaning. Ofcourse you might get lucky and the hash
>>>> algorithms
>>>> are not perfect but chances are you won't be able to do anything. (and
>>>> one
>>>> can make it much more secure by using dynamic hashing. The only way you
>>>> could even get close is if you had access to the hashing algorithms)
>>>>
>>>> > The best way is to keep the file in a directory below the
>>>> > document_root.
>>>> > Even on a shared server this will not be accessible by other users if
>>>> > the
>>>> > hosting company has set up their security properly.
>>>>
>>>> Yeah, but even if this is true then it doesn't matter much because its
>>>> never
>>>> 100% secure and the hosting company can easily get the passwords of
>>>> people
>>>> and use them. (do you really want your password sitting on some
>>>> database
>>>> when there is no reason?)
>>>>
>>>> Its not passwords that are important for security rights but checking
>>>> passwords. Since a hasing algorithm is one-to-one you can do this
>>>> without
>>>> having to actually check the real password.
>>>> i.e.
>>>>
>>>> if phi(x) is your hashing algorithm
>>>>
>>>> then phi("Joe") = y
>>>>
>>>> you just store y. If you need to check then later on you just do
>>>> phi("Joe")
>>>> again and check in the database for y. "Joe" is not stored in the
>>>> database.
>>>>
>>>> Its sorta like PGP but no messaging is sent. It would be much more
>>>> secure
>>>> if the hash was done on the client side(although it would be easier for
>>>> people to hack because they could then easily get at the code) because
>>>> then
>>>> the actual login information is never sent across the wire. Even if
>>>> someone
>>>> sniffed the tranmission they would not be able to do much with it.
>>>> (Sorta
>>>> like PGP)
>>>>
>>>> Obviously its a good idea to keep the DB information and scripts secure
>>>> but
>>>> thats only part of it.
>>>>
>>>> Jon- Hide quoted text -
>>>>
>>>> - Show quoted text -
>>>
>>> Jon, did you actually bother to read Jerry's post?
>>>
>>> How can the OP check for the existance of the hash in the DB (table
>>> might be a better word) if he hasn't logged into MySQL yet?
>>> How can he log into MySQL if he doesn't have a userid and password for
>>> it?
>>> MySQL will NOT accept the hash of a userid and password as login
>>> credentials to MySQL, it wants the MySQL userid and password.
>>>
>>
>>Um, so your saying that he will allow remote users to access the DB
>>directly? Thats nonsense. If he is using a web interface to the DB then do
>>you think that the DB cannot viewed by the administrators? No matter
>>where
>>he hides files or whatever he does with permissions they can get it.
>>Theres
>>no way to secure anything from the admin. So whats your point?
>
> You still want a way to secure the MySQL passwords from users with
> browsers.
>

Sure. I understand that. But thats by default? Every web hosting server I
have known didn't give permissions to the whole site by default. (and at the
very least you could move it to a non public_html dir and it would be secure
from remote users.

>>Even if I'm mis-interpreted the OP this does not mean that the idea is
>>wrong
>>or bad. I never said MySQL took hash values for log in information. I
>>assume since he is doing a php web site that he is writing a database for
>>use on his web site. His security issues are only with the remote users.
>>He
>>cannot secure it from the admin(well, maybe in some ways but nothing that
>>is
>>normally done).
>
> It hasn't been established that this site will even *HAVE* individual
> user logins. Many search engines don't. However, search engines
> are likely to use databases and they don't want random users altering
> the data.
>

Yes, I original misread what he wanted. I thought he just wanted a way to
secure remote user passwords. This can still be done using SQL by having an
extra layer of security using the idea I presented but you will have to have
atleast one account that can query the user database. It doesn't matter if
its secure or not. Except now you will have to store the passwords to be
used to log into the DB but you can have a level of indirection that will
prevent most people from getting ahold of the passwords. (ofcourse if you
let remote clients go snooping into your web files then your bound to have
some security issues.)