Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Jacques1

  1. If the date field has a proper type (DATE, DATETIME or TIMESTAMP), you simply use the date and time functions: http://dev.mysql.com/doc/refman/5.6/en/date-and-time-functions.html If it's some hard-coded VARCHAR (looks like it), you have a problem. Since MySQL doesn't know what to do with your strings, you first have to repair your database by turning all pseudo-dates into actual dates. SELECT DATE_FORMAT(date, '%M') AS month, COUNT(*) AS name_count FROM test GROUP BY EXTRACT(MONTH FROM date) ORDER BY EXTRACT(MONTH FROM date) ASC ;
  2. Hi, since you showed us the form and not the validation code, I have no idea how we're supposed to help you. However, your code has a bunch of serious security issues: First of all, it's probably vulnerable to cross-site scripting attacks through $_SERVER['PHP_SELF']. Depending on the configuration, Apache allows the user to append arbitrary pseudo-directories to the actual file path. For example, they could request your script like this: https://www.yourdomain.com/yourscript.php/<some JavaScript injection> Apache would accept it as a valid path for yourscript.php, and you would happily insert the JavaScript code into your markup. This again shows that you must escape any user-defined input before it can be inserted, no matter how restricted it may seem at first sight. While you do escape the $_POST values, you have totally forgotten to specify which character encoding should be used. This again can lead to cross-site scripting in some cases. If the default encoding of htmlspecialchars() simply isn't the one you actually use for your document, the escaping mechanism may fail to recognize the critical characters and let them through. For example, there's an infamous UTF-7 attack which takes advantage of an encoding mismatch. Last but not least, you must never send the password back to the client. Passwords are obviously very sensitive data, so the last thing you wanna do is send them back and forth around the globe. Apart from that, how exactly does this help the user? The passwords are masked, so the user can't just edit them. Wrapping it up: Never insert raw user input into your HTML markup. The request path is user-defined input. Escaping depends on the character encoding, so always specify the encoding when you use htmlspecialchars(). It has to match the charset attribute of the Content-Type header. If you do not have a Content-Type header with a charset attribute, add it now. Be very careful with passwords. Do not send them around.
  3. Hi, I guess even the author of the code doesn't know what it's for. Where on earth does this come from? The code is an extremely cumbersome way of writing md5(time()) Why would one hash the current Unix time? I have absolutely no idea. Maybe they wanted a fixed length. Or maybe it's a botched security feature.
  4. Hi, there is no direct equivalent to mysql_result(). You have to fetch the whole row and then extract the first value as shown by Ch0cu3r. A shorter solution would be list($num_items) = $items_query->fetch_row(); I strongly recommend that you actually learn how to use MySQLi and make use of its new features. Don't just run some tool to translate the old code. The new extension is very different in many aspects, and it's important to understand them.
  5. I know. What I mean is that we should leave cryptography to the people who actually understand it. Designing a hash algorithm is definitely an expert topic. And the result needs to be reviewed and tested by many people over a long period of time. If the algorithm has survived that, then it's ready for use. Right. That's why it's a good idea to expect the worst and make as few assumptions as possible. Password hashes should be secure even if the entire server has been compromised. They shouldn't depend on some secret data which might be stolen (be it a key, the salt, the algorithm itself or whatever). So am I. By the way, kudos for being open to critique.
  6. You mean the class you've just published on the Internet? Anyway, this is security through obscurity, a very common fallacy. People try it again and again, and it fails again and again. An algorithm that is only secure as long as it's kept secret isn't secure at all. A cost factor alone doesn't mean much. This is where it gets into the ugly details of cryptography, and I think none of us is qualified to talk about that. Again, security through obscurity. Very funny. AES is no magic spell to make systems secure. The server that manages the passwords needs access to the plaintext salts. That means you either have to store the AES keys right next to the encrypted salts, which would make the whole thing pretty silly. Or the authentication server needs to be able to fetch the plaintext salts from some external server, in which case the AES encryption is irrelevant for the attacker. Either way, the encryption doesn't really do anything. I mean, if you know how to build perfectly secure systems, why don't you simply protect the hashes? Nonsense. Sorry, but I have no idea why people keep perpetuating this myth. SHA-2, SHA-3 or whatever are in no way better for hashing passwords than MD5. They're all equally bad. The problem is that they were designed for digital signatures, not for password hashes. They're supposed to be very fast and efficient, which is the last thing you want when hashing a password. bcrypt, on the other hand, was specifically designed to be slow and expensive. Reality has proven that it's able to withstand brute-force attacks as long as the password is relatively strong. This is the de-facto standard for hashing passwords. And since PHP 5.5 got the new bcrypt API (see trq's post), there's really no excuse for not using it.
  7. You're missing the whole point of password hashing, phpzer. You do a lot of hashing and encrypting and encoding and whatnot, but you don't seem to understand why you're doing it. This is just an arbitrary collection of pseudo-cryptographic voodoo. The biggest threat for password hashes is a brute-force attack. To withstand those attacks, a hash algorithm has to be computationally expensive. That's the only counter-measure: To slow down the attacker so that it's impractical for them to break anything but the weakest passwords. Your algorithm isn't expensive at all. An average gamer PC can calculate billions(!) of SHA-2 hashes per second. Sure, you repeat the hashing a few times. But that only means an attacker might need, say, 2 minutes instead of 1 to break an average password. Great. Actually, how can you be so sure that your nested hashes and string magic don't introduce cryptographic weaknesses? Don't tell me you've written a mathematical proof for each function call. Encrypting the salt is also nonsensical. First of all, that's not what it's meant for. The purpose of the salt is to act as additional input so that the same password doesn't lead to the same hash. Secondly, if an attacker has already managed to obtain the password hashes, it's pretty naïve to assume that the salt is still perfectly secure. I mean, it's readable by the very server that has just been compromised. Long story short, this is in no way better than plain old MD5. It's actually much worse, because MD5 was intensively researched, and we know its strengths and weaknesses. Your stuff hasn't been researched by anybody. The only person who thinks it's good is: you.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.