Tag Info

New answers tagged

0

What I would do, besides the measures mentioned in the other answers, is to read the username/password from a file to be retrieved from the web server and to have this file explicitly blacklisted for all but the server itself.


3

Defence in depth is the keyword: Instead of just securing the credentials, ensure that even knowing the credentials is (almost) useless for an attacker. That means, use a dedicated user with the least required privileges (principle of least privilege) and restrict access with that user from the web server only. Then it doesn’t really matter where you keep ...


2

I good way to protect your keys is to put the php file with the credentials outside of the webroot. Even when the 'raw' php files are then served to a client, none of them include the database credentials. (does not protect against someone with file access on the server). Another defensive measure you can take is limiting the connections the Database ...


0

When do I escape the data? Basically, as late as possible. The database is somewhere to store data, it is not a place to encode (escape) data. Of course use parameterised prepared statements to prevent any SQL injection attacks, but that should be as far as you take it. Your goal for writing to the database is simply to store the data successfully and ...


0

See MySQL BACKRONYM attack (more info here). Basically older versions of MySQL (before the latest MySQL preview release 5.7.3) were vulnerable to a man-in-the-middle SSL-stripping attack where a network attacker could capture your authentication data and login to your database. So all the network attacker (some rogue party at an ISP) just needs to run a ...


0

The first answer told many things. But as long as your connection to the mysql database is possible, you can be hacked. [My off-topic advice: keep searching for info about exploits and vulnerabilties for mysql actively]. Can any expert programmers out there tell me if allowing access from any IP address would compromise security unduly? Actually, I ...


1

An attacker would need one of the following: No known user / password A vulnerability for the mysql version you use. the IP of your mysql server (if it runs on a default port chances are its already known to the criminal world) Sniffed User name / password / ip Nothing, he has all he needs. The difference between the 2 scenario's is that 1 is a ...


1

The answer seems quite simple to me. The final decision however, depending on the context, may not be as simple as it implies the notion of trust. SSL is a protocol allowing you to establish a secure connection over an untrusted network. The usefulness of SSL in your case therefore lies in this question: Do you trust the network between the web server and ...


7

Well, let's dissect it: CONCAT_WS - Concatenate with separator. version() - Returns the version of MySQL. FLOOR(rand(0)*2) - Emits the following sequence of numbers: 0, 1, 1, 0, 1, ... having min(0) - By itself, this is illegal, as the HAVING clause requires a condition. This, and the fact that there's no ; -- on the end, implies that the injection is ...


-1

Simply storing password using sha1/md5 or any hashing function is not a good practice. Many sites are providing dictionary to crack these password. Solution is to use a powerful salt to add in password, then convert it to sha1 hash. You are using very basic or a kind of simple padding. You can use rand, time stamp, double hashing as salt. Performance wise ...


6

There are two things wrong with what you are doing with what you are doing: your algorithm in it's simple form is fast and thus not suited for password hashing. (the properties you want in a password hashing algorithm is it being fast enough to run once, but slow if you need to run it several times as well as being unfriendly when being run on FPGA/ASICs ...


15

No a salt should not be derrived from other known parameters, a salt should be globally unique. So the best you can do is to generate a really random salt for each password. Todays operating systems have a "random source", on a deterministic computer it is the best you can do to read form this random source (DEV_URANDOM). Beside this, the SHA-* hash family ...


4

A drawback of SHA1 is that it is fast, so it is easier to create rainbow tables and brute-force it. Adding a salt helps, but if the password is weak, then "number + weak password" may well be in the rainbow tables along with the password. PHP provides built-in password mechanisms. When you use these, the crypt function automatically generates a salt for you ...


0

This allows for (potentially malicious) actions that are contrary to the intended use of the application, so yes it is a security flaw that you should be worried about. Just because you have found limited use cases / attack vectors does not mean that others don't exist. Ideally you should take a "defense in depth" approach whereby you mitigate the concern ...



Top 50 recent answers are included