Jacques1

Because this appends the value of $town to the $get_available_towns array. If you remove the brackets, you just overwrite the $get_available_towns variable again and again. This has nothing to do with the PHP version, by the way.

I don't think this is good code. The general rule is that a file either contains declarations or has side-effects, not both. This is explictly specified in the PSR standards. Of course you're free to violate the rules. For example, many people do have function declarations within regular scripts. But a complete class? That's just spaghetti code and very confusing. He wants to restrict properties to one script. So other classes within the same file do have access, but not the classes in other files.

This is rather vague. Can you give an example of such a string? And how is the resulting array supposed to look like?

The Common Name should be the domain of your site. So in your case, it's simply “localhost” – unless you have a specific reason for why you need to bind the certificate to one particular IP address.

$test is just a local variable. It's only available in the constructor itself and thrown away afterwards. If you want to set the test attribute, you need to use $this->test = "4"; Just like in your test() method.

The OpenSSL function is exactly what the library uses internally. All good random number generators eventually use the randomness device of your operating system (like /dev/urandom), so the source is always the same. The difference is that openssl_random_pseudo_bytes() is a simple function, wheareas RandomLib is a big fat library with some extra features (like mixing multiple sources). Unless you have a specific reason for why you need the extra features of the library, just go with the simple function. In fact, the PHP security tutorial you're reading specifically says that the library is only needed as a fallback in case neither the OpenSSL extension nor the Mcrypt extension are available. You do have the OpenSSL extension, so no need for the fallback.

An internal modifier doesn't make a lot of sense in PHP, because you generally have only one class definition per file. In fact, auto-loaders expect this structure. At best, you might come up with a scenario where you have an auxiliary class which is only supposed to be used by another class in the same file. In that case, the modifier theoretically makes sense. But it would be very confusing and against all common practice. PHP simply isn't C#, and it won't become that in the near future.

If you remove the strrev() as well, I think everybody is happy. Like I said above, it's dangerous to mess with the password. How do you know you can safely take the last 56 bytes of it and throw everything else away? When I enter a password, I expect it to be processed from left to right. And you have to admit it's a bit silly. If an attacker sees “...$y2$”, don't you think they can figure out that it's actually “$2y$...”? Randomizing the cost factor also doesn't make a terrible lot of sense. The factor needs to be carefully chosen by you, the programmer. If you use a random number instead, that means a lot of hashes will be either weaker than necessary or too strong for your hardware. And there's absolutely no security benefit either. In the attack scenario bcrypt tries to protect against, the attacker knows all hash parameters. Instead, make the cost factor configurable so that it can be changed if the application is moved to different hardware. For example, use a constant in a configuration script: /* * The cost factor for the hashes of standard user accounts. * * Adjust this according to your hardware, the value of the user accounts and * the patience of your users. A high factor makes the hashes more robust * against brute force attacks, but it also stresses the CPU, slows down the * application and increases the risk of denial-of-service attacks. */ define('PASSWORD_STANDARD_COST', 12); You can then use this constant instead of hard-coding some specific value into your code: $password_hash = password_hash($password, PASSWORD_BCRYPT, array('cost' => PASSWORD_STANDARD_COST));

Richard, the problem is that you don't understand how bcrypt works, yet at the same time you think you can “improve” it and outsmart everybody else. This does not work. The only person you've outsmarted is yourself. By messing with the inner workings of bcrypt you've in fact massively weakened it: The cryptographic salt must be a purely random 128-bit string from a high-entropy source encoded with a special Base64 alphabet. Your “salt” isn't any of this. It's not purely random, it's not from an appropriate source, and it's not encoded at all. What happens is this: Let's say you end up with a “salt” length of 22 characters. From those 22 characters, the last 14 belong to your strange “|WordToTheWise” suffix and don't have any effect at all (you don't seem to understand the purpose of a salt). So only 8 characters are left. Even worse, since “|” is not a valid Base64 digit, the password_hash() function thinks your salt consists of raw bytes. But of course that's not the case, each character only carries ~6 bits. Long story short: You've reduced the salt from 128 random bits to roughly 51 halfway-random bits. That's a disaster. Playing around with the password, reverting it and adding characters is also a very bad idea in the case of bcrypt. Since bcrypt has a maximum input length of 56 bytes, you may experience truncation. It's somewhat logical to take the first 56 bytes of the password and throw away the rest (if you tell your users about it). But what you do instead is take the last 56 bytes and throw away the rest. No user would expect that, so this is the recipe for disaster. Imagine a password which is padded with whitespace: In the worst case, you take the whitespace and throw away the actual password. Apart from the severe technical mistakes, the entire approach is nonsense. This is a classical example of “security through obscurity”: You think you can improve security with confusing or even “secret” techniques. This does not work. First of all, the confusion mostly hurts you, the programmer. The more obscure your code, the bigger the risk of making a mistake. And indeed that's exactly what happened. Secondly, attackers are not stupid. They know all your super-creative obfuscation techniques. Do you honestly believe that nobody before you has thought of reverting a string? In security, we do not want obscurity. Quite the opposite: We want the code to be as clear and straightforward as possible to avoid bugs. If you spend your time coming up with obscure code, you're doing it wrong.

You need an autoloader (see test/bootstrap.php for an example) and the SecurityLib library. You can use Composer to handle that automatically. But why do you even want this library? There are much easier (and I'd say: more reliable) ways to get random bytes. You can directly access the random number generator of your operating system with mcrypt_create_iv() or openssl_random_pseudo_bytes(). No need for a big third-party library.

By all means, do use prepared statements. Yes, they are much more reliable than manual escaping (if used correctly), and, yes, they are a fantastic security feature. Don't let DavidAM's strange rant confuse you. I have no idea what he's trying to tell us. Whether or not the historical purpose of prepared statements was to improve the performance of repeated queries is entirely irrelevant here. The point is this: All values you pass to the parameters of a prepared statements cannot interfere with the query. This reliably prevents SQL injection attacks as well as unintentional errors. . Yes, you do have to pass the values to the parameters. If you circumvent the entire mechanism, then of course it cannot work. That doesn't mean it creates a “false sense of security”. Every tool eventually breaks if we don't use it correctly. I strongly advise against manual escaping with mysqli_real_escape_string(). In theory, it may work well. But in practice, it's far too fragile: Even experienced developers constantly forget to escape values. Just read the security announcements of any big PHP project. Many people think it's smart to only escape the values which they find “dangerous” (see Richard's post). This again leads to bugs or even security vulnerabilities. Escaping is vulnerable to character encoding issues. For example, many programmers use a SET NAMES query to change the encoding of the database connection. This is very, very wrong, because it doesn't update the encoding information within the MySQL API. As a result, mysqli_real_escape_string() still uses the original encoding and may cease to function entirely. Prepared statements are much more robust. You just have to understand the concept: Stop injecting variables into query string. Use one static query template with parameters, and then pass your values to those parameters. This eliminates any risk of those values causing trouble. Note that there's a pitfall in the PDO extension: By default, PDO does not use prepared statements. It just escapes the values and literally inserts them into the query string, which is effectively the same as using mysqli_real_escape_string(). To get actual prepared statements, you have to explicitly set PDO::ATTR_EMULATE_PREPARES to false.

There's a misplaced AND in the UPDATE query.

Did you read the manual?

PHPMailer works like any other PHP class, so you can use variables, constants, functions or whatever. Just try it. If you have concrete issues, post your code.

You output or omit the meta element depending on whether or not a certain URL parameter is present. For example: https://yoursite.com/some_page?compat=1 This would trigger the meta element. But this URL wouldn't: https://yoursite.com/some_page

You indeed should randomize the filename. In fact, relying on the user-provided name is a very bad idea: If you're not careful, people will upload malicious scripts. And you'll quickly run into issues with duplicate filenames. A common approach is to validate the file extension against a whitelist (e. g., only “.jpg”, “.png” and “.gif” are allowed), generate a random filename and then append the extension. To get a random string, you can use mcrypt_create_iv() or openssl_random_pseudo_bytes(), depending on which one is available.

The point of the “Like” button as I understand it is to mark excellent replies and allow knowledgeable users to build up a reputation. Whether you're thankful or not, happy with the post or not isn't really relevant. You simply acknowledge technical advice. Let's not forget this is a programming forum. It's not a social media platform.

Your file field is called “image”, not “file”. So it's $_FILES['image']['name'].

Using big blue letters doesn't increase the credibility of your replies. So please don't. I think we can talk without a loudspeaker here. I'd actually argue that your .htaccess files are less secure than simply keeping the credentials in a PHP configuration script: You put the sensitive data where people don't expect it (like the $_SERVER array). As a result, they may fail to protect the credentails. You automatically make the data available to every single script within the scope of the .htaccess file, which is entirely unnecessary and again increases the risk of leaking the credentials. Only the scripts which actually need the data should include it. Storing credentials in PHP scripts is perfectly fine and by far the simplest approach. If you want to go against that, you need better arguments than the size of your letters.

What? How are those weird digit sequences supposed to increase security? It's the exact opposite: I wouldn't be surprised if there's a bug somewhere. Please don't. I think you've put a lot of strange ideas into your head, and now it's time to get back to reality. Store the result of password_hash() in a CHAR(60) column like everybody else on this planet. I understand that you're into math and like to play around with different bases. But user passwords aren't the right thing to play with. Make this a separate project. I am referring to your last sentence where you stated that there are probably no collision in the space of typical passwords. Now, maybe you just meant that as a kind of “fun fact” with no relation to the previous text. But I read it as: The reason why collision attacks are not a problem for passwords is because there are no collision in that space. And that would be plain wrong.

So you're asking how to access an element of an associative array? $paypal_response = $PayFlow->getResponse(); var_dump($paypal_response['TRXRESULT']); If you're just confused because of the bracket syntax, use var_dump() instead of print_r(). There's actually no need to put all elements into separate variables. The values in the array are just as good as any other value.

Note that this is not a “binary string”. It's literally a sequence of the characters “0” and “1”, which means this takes 8 times as much space. It's entirely unclear why you would do this. There also seems to be some confusion regarding the number of bits in a byte. One byte is 8 bits (not 7). Just store the hash in a CHAR(60) column. It's generally a good idea to get the basic code done before you start implementing strange ideas.

What in God's name are you doing there? Seriously, what the fuck is this?

No. There's no such thing as “de-hashing”. The whole point of hash algorithms is that they cannot be reverted. The result of password_hash() contains all parameters of the original hash calculation: the algorithm (“2y” means bcrypt), the cost factor (in my case 10) and the salt (128 bits), followed by actual hash (184 bits). -------------------------------------------------------------------------------------------------------- $2y$10$4DD6Ts9Lw4gZOKoYCd3iferiRKfNGHuMIMgbBkRSHQyal0NqHvBKK -------------------------------------------------------------------------------------------------------- To verify a password, the function hashes it with the exact same parameters and then compares the result with the given hash. If the hashes match, then the password is correct, otherwise it's wrong. It's the same thing you did with MD5: To verify a password, you hash it and then compare the result with the MD5 hash in your database. If they match, then the password is correct.

There's still no JSON data anywhere. I guess your actual question is whether you can call your e-mail script with Ajax. Yes. Everything works like before, the only difference is that you replace the mail() function with PHPMailer.