File Self Secure? is it avaible

[haitamlong 0]

I just learn php. We store the pass word of Mysql in a file right. So is there any way to may a pass protect that file . i mean they could hack and find out the place of the file (ex like in forum) and drop all sercure data

[toby 0]

Unless it's in a text file, it is already secure. They will need the four pieces of MySQL login to get to any sql data.If it's a text file, put it in the same folder as public html, or chmode it to lower numbers.

[yordan 10]

We store the pass word of Mysql in a file right.

No, we don't really store the password in a file. This is the main principle of passwording.The database administrator assigns a password.
This password is enkrypted somewhere and is never read.
The algorithm is made in such a way, that there is no real "reverse function" allowing to know the real password from the stored value.
And, of course, the password is not a word in a file. It's part of the binary files, the bytes lying along the file from offseen XXXX to offset YYYY. The database manager knows he has to go from offset XXXX to YYYY while reading, but you don't know.
So, the only way of coming in is asking the database manager to connect you.
And the database manager accepts your password, or refuses it.
Generally, if you try three times, it was your last chance, sometimes the IP address is blacklisted, sometimes the user is simply locked until the admin enables it again.
Of course, you can try using a computer to try to guess the password of another computer, but usually this needs time, and the admins are warned that something is occuring.
And have a look here, at Xisto, there are peoples from all around the world. You can easily imagine that one admin is not sleeping right now, somewhere in the word.

[CrazyPensil 0]

Mostly, I agree with yordan, but... just why don't you create a PHP-file that declares a variable($pass, for example), and assignes it md5() value of the pass. then, while checking password, you md5() input of user, include the file with password, then compare $pass&$input, and if they match, let the user in.

 

2yordan:

What did ya mean by these "reading binar data from file, with offsets..." do you mean that you insert some odd data to the encrypted pass value, and then take out the part needed with constant offsets? A good idea against the hackers! Also, the encrypted variable may be changed(mixed) with respect to some rules, such as 1st byte is in place of last, etc...

 

[iGuest 3]

I think what he's actually referring to is what he's learnt about PHP.He's talking about the connection method used in PHP to connect to a MySQL database, not the actual storage of a password. If you do mean the actual storage of the password, it is most likely never stored in plain text in your database. Usually it has been converted into a one way hash in which it is near impossible to break the encryption. The only viable checking method you have is whatever plain text they entered when converted into the hash can be compared and if the hash doesn't match, it's the wrong password.But what I think you're talking about is the PHP way for connecting to a database. Usually your password is in plain text but it's within a PHP file. As long as the file extension is of that of PHP, the connection code exists within PHP tags and the server is configured correctly, they should not be able to gain the password, however there are many ways they could gain the password but this is no easy task and I would not want you to be paranoid about it either.Some best practises is to create multiple users with specific tasks for managing only specific database commands, never use a root or a user who has full access (GRANT ALL) for connections. My beliefs however is root users should never be able to do what normal users do (well more specifically in the same way), that's for anything, including forums, tagboards, etc. I think they should be designated in their own administration place, where they can control what they do, but can not log into a user/member area and be just like a regular user.If you can only have one user, then restrict him the minimal actions he's allowed to perform and restrict him to only a database he can access. The easiest way to do this is to create a user with no actions allowed and add him to a certain database only, then test a script out with that user and you'll get an error stating what the user can't do, adjust that user to be able to do that, and continue testing until there's no more complaints/warnings. Hopefully that will discover all the actions early, but sometimes you'll discover them later on down the track but hopefully by then you'd know enough PHP to understand what commands are needed so you can stop with the trial and error testing.If you are concerned, then there's also PHP encoding software, but I don't know of any that are available freely (there could be though). What this does is scramble your text but still makes it possible for the server to decode it and read it as if it were plain text. That way if a password was stored in plain text, the actual file when encoded would look like goobly gook to anyone who managed to get hold of it, though if they spend enough time with it, it's possible they could managed to decode it because the algorithmn is usually a 2 way encryption which means it can be decoded, so if they understood how it was encoded, they'd definitely understand how to decode it too.And just while thinking about it, you can also encode everything in MySQL, so if they did get into it, it would appear the same.But the most important thing, don't store sensitive data in MySQL. There's no reason to store whole credit card numbers, or even part of the number, validation of the card should be done straight away with a reputatable credit company and the purchase done at that time, so there's no reason to store it. Once used get rid of it, the user is going to have to insert that number again if they want to make another purchase.Other things is, if you have to store sensitive data, then store it in a network that can't be connected to via the internet, though not possible for everything, then store the information in a different database with a different user to the one controlling the other database. If possible, make sure to change passwords on a regular basis too.There's actually so many things you could do to make it harder for such an attacker to get in, but the more things you introduce, you could make it difficult for yourself to keep up with, so don't go overboard with it unless you want to spend a large deal of your time with it. Trust me, the best thing you want to do is be 1 step ahead of an attacker not 100s of steps.Cheers,MC

[yordan 10]

What did ya mean by these "reading binar data from file, with offsets..."

What I mean is that a database manager, like mysql or like Oracle, do not put the data in a readable mode. It has a definition of the data (it's a number, it's a character, it's a date, it's a time, it's a floating point) and a place to store it (XXX bits from the beginning of the file). So, if you simply read the file, you have no real info, the username is somewhere, then you have anoter user's age, then you have my mother's cat name, and then you have the first user's password. So, nothing really smart, only useless bits unless you are connected to the database.Of course, I'm talking about databases because the first question in the post concerned databases. If you store the passwords in your own files using php, you have to create your own security mechanism, and an entruder would eventually have to guess what you did. Edited October 5, 2006 by yordan (see edit history)

[CrazyPensil 0]

What I mean is that a database manager, like mysql or like Oracle, do not put the data in a readable mode. It has a definition of the data (it's a number, it's a character, it's a date, it's a time, it's a floating point) and a place to store it (XXX bits from the beginning of the file).

 

Wow=)

Nice, i didn't know the mechanisms all those ready databases store info)

I was always using my own mechanism, that was including my method of encrypting and all those splitters etc... I developed my own engine. And now i found that the algorithms of those brands are not so far from mine)

Actually, they're almost the same, but i don't have the 'date'&'time' datatype....

Eventually, i don't accept these to be so implortant and use to store these as floats)

 

Anyway, it seems that the problem our friend haitamlong raised up is already over and he got his answers(right, man? ).

 

With the best wishes.....

 

Me, just a russian lad;)