Daniel0

Uh... yeah it does. You cannot do echo printf. printf already does output it and it returns the length of the outputted string, which is what you are then echoing.

That's something you're outputting somewhere else. Right now <?php $start = '2009-05-29 12:00:48'; $end = '2009-06-01 12:00:48'; $start = strtotime($start); $end = strtotime($end); if (!$end || !$start) { throw new Exception('Invalid dates.'); } else if ($start > $end) { throw new Exception('Start date is larger than end date.'); } $diff = $end - $start; $current = time(); $cdiff = $current - $start; if ($cdiff > $diff) { $percentage = 1.0; } else if ($current < $start) { $percentage = 0.0; } else { $percentage = $cdiff / $diff; } printf('%.2f%%', $percentage * 100); outputs 1.88%, but that will of course change.

Will this affect embedding. I get a large amount of incomming traffic from other sites from embedded videos No. The request will come from the end user, not the site that embeds it (that is if you're talking about YouTube style embedding). So unless there is a page with a lot of embedded videos on one page it shouldn't be a problem.

What did you expect the result to be? It wasn't before your edit.

Well, those two date inputs are all in the past. You need to explain what you are trying to do. Otherwise we cannot really help you. We have all been trying to guess what you are trying to do, but all the times you simply just come back and say you aren't getting the correct results. That's like walking in saying that you're trying to get the number 5. I can provide you millions of ways you can get the number 5, but unless you tell me how you plan on getting to that number I can't give you the solution you're looking for.

What is your greatest concern? CPU time and memory consumption, or bandwidth? Half the hits are curl bots. Have no idea how to block them If you can tell that it's being done using curl then why can't you block it? I suppose you could check the speed at which a given IP address makes requests. If they make requests too far then they're probably bots. You can use something like denyhosts and add bot IP address to /etc/hosts.deny. Doing that will drop all packets coming from those IP addresses.

May I have 5.2^114 guesses? Sure, as long as you can prove that it isn't a collision

Actually, you completely missed the point. Hashing truly is one-way. You cannot know if the match you found is the original plain text value or one of the colliding values. All you know is that what you found shares the same hash as the original value has. Hashing is not encryption, and there is no such thing as cracking a hash nor brute-forcing a hash. I'll send you $50 over PayPal if you tell me what the what the plaintext value I used for this hash is: 9f65f29197e64cef1f862f359866c3abdc473da40a0efd1f6bca32fb13cfb5da It's not enough finding a string that matches the hash. You must prove that what you got is the same as what I originally had. Anyone else who wants to try can claim the $50 as well.

Assuming the brute forcing is made using your login form in which case the choice of hashing algorithm and the usage of salts is actually irrelevant. If they get the hash the lockout is irrelevant, but the choice of hashing algorithm and salting isn't. Either way, a lockout mechanism is obviously a good idea. That being said, I use SHA-256 or SHA-512.

I think what he means that if start is 2009-05-28, current is 2009-05-29 and end is 2009-05-30 then the result should be 50%. I.e. something like this: <?php $start = '2009-05-28'; $end = '2009-05-30'; $start = strtotime($start); $end = strtotime($end); if (!$end || !$start) { throw new Exception('Invalid dates.'); } else if ($start > $end) { throw new Exception('Start date is larger than end date.'); } $diff = $end - $start; $current = time(); $cdiff = $current - $start; if ($cdiff > $diff) { $percentage = 1.0; } else if ($current < $start) { $percentage = 0.0; } else { $percentage = $cdiff / $diff; } printf('%.2f%%', $percentage * 100);

Another way that you could say it is that the cardinality of the domain is infinite, but the cardinality of the range if finite. MD5 will always output a 32 digit hexadecimal number. There are 16 different hexadecimal digits, so that means 1632≈8.7*1040 distinct outputs. It's a lot, but clearly much lower than the infinite number of possible inputs. Incidentally it also means that there is a fixed upper limit on the number of checks you have to perform before you will get a match*. You say that if x1 ≠ x2 and f is a hashing function then if f(x1)=f(x2) you have a hash collision. There is an infinite number of hash collisions. As GingerRobot said, this means you cannot reverse it. However, in terms of checking the hash of an entered password with the stored hash of the real password, it is irrelevant whether or not you can reverse it because one of the colliding inputs will also match and log you in. This is also why doing things like md5(md5()) is a bad idea. Doing that you are drastically decreasing both the final domain and range and thus increasing the chance of a hash collision. * I'm not 100% sure this last statement is true.

No, because obscurity is not security.

What are you studying and at what level? Just to get an idea of what could be potential interesting subjects.

Maybe see this as well: http://www.phpfreaks.com/tutorial/php-security

Which is one of the reasons shared hosting sucks. You could easily write a custom session handler to store session data in the database instead of files on the server though.

You needn't store anything other than the user ID (or username if you prefer that). As for "remember me", you can, as previously mentioned, just set an expiration date on the session cookie. When someone requests a page with a valid session active you just get the user info based on the ID/username.

Why not redirect the old links to the new links instead? In that way you won't lose any traffic.

I think 1000 PS3s would be regarded as a supercomputer by most computer scientists. In this article they refer to a cluster of eight PS3s as a small supercomputer.

Well yeah, you obviously has to store the salt somewhere. I tend to use two salts. One that's per-user and one that's per-application. The per-user is stored with the user's row in the database and I'll change it whenever I have the chance (i.e. whenever I have the user's password in plaintext). The per-application is statically defined in a config file.

Or you could like use the built-in session functionality that takes care of doing things like generating a high entropy ID, storing all the info for you, etc. All you have to do is alter the cookie persistence using session_set_cookie_params. Also see: http://www.phpfreaks.com/tutorial/sessions-and-cookies-adding-state-to-a-stateless-protocol

And even then you run into the common pitfalls of non-normalized database schemas. You risk that someone makes a type such that it says New Yok instead of New York. You'll then have anomalies in your code. Searching for New York won't get the one with the typo. The reason why you call something good practice is because it's the good way of doing it.

Well, if we turn the question around, how would you do it and what would you need the password for? Answering that question would probably help you along the way.

Right, of course some people just have rich parents which makes their possibilities for success far greater. Complete equality obviously isn't possible. Not even in so-called communist countries does total equality exist. Some people are satisfied not being super wealthy though. Some people are satisfied with being trash men, cleaning staff, etc. and to be honest, that is a good thing. A society consisting solely on academics and executives wouldn't work.

Because they're amateurs.

What prevents you from posting the details here? Generally we do not delete anything that doesn't violate our terms of service.