scootstah

$str = 'blah_blahblahblah'; preg_replace('/_.*/', '', $str);

CSS isn't going to make links not work. Do you have a live page we can view to see the page source?

For what purpose? You could use mcrypt to encrypt/decrypt parameters.

Like urlencode()? What are you trying to do?

In your login script you are trying to assign $_SESSION['username'] using ==, which is a comparison operator. So change $_SESSION['username'] == $username; To $_SESSION['username'] = $username;

You can use the ternary operator. $var = '<input name="First Name" type="text" maxlength="50" size="50" value="' . (!empty($var) ? $var : '') . '" />';

No, a collision is when two separate strings create the same hash. For example let's say the hash of "password1" is "7c6a180b36896a0a8c02787eeafb0e4c". A collision would be another value that also happens to have the hash "7c6a180b36896a0a8c02787eeafb0e4c". Because if an attacker can regenerate a hash with another value, they could use that value to login. If the user's password is really "password1", but "blurgablur" creates the same hash then they can use that to login with. As I said above that is not possible. Hashing is one way and you cannot reverse-engineer it. In this context it would be referred to as a "pepper". A salt is unique for each user, whereas a pepper is static. Moreover, they are not stored in the same location (one in the database, one in the filesystem) so both would have to be compromised. My apologies, I forgot to stick the salt in there. It would go here: $hash = hash_hmac('sha512', $password . $salt, $key);

No, you can't reverse-engineer a hash. It is one-way. Simply knowing the salt gives them no advantage at all. See, you are missing the point. You would need a rainbow table for every user. So therefore if you have 1000 users, you would need 5 petabytes to store all those rainbow tables. A (very fast) Google search puts the current hard drive market at $0.07/GB. So 5 petabytes would cost roughly $360,000 USD. Do you really think someone is going to invest that much money to hack your website? And then add on to the fact that it would take a very long time to compile all of those rainbow tables. Remember that when you use a salt, the rainbow table has to be constructed specifically for that specific salt. Yes. No. Yes. No, because you don't add the salt to the hash, you add the salt to the password and then hash both. So if your password was "password1" and the salt was "abcdef", you would hash the string "password1abcdef". It doesn't matter, the length of the hash would remain the same.

I still have no idea what you are talking about.

How about this? $str = '<h3><a href="/anyfolder/recording-1-week">link1</a></h3> <h3><a href="/anyfolder/recording-2-week">link2</a></h3> <h3><a href="/anyfolder/recording-3-week">link3</a></h3>'; preg_match_all('/<h3><a href="(.*)">.*<\/a><\/h3>/', $str, $matches); $files = array(); foreach($matches[1] as $match) { preg_match('/\/([a-z0-9-]+)$/i', $match, $file_matches); $files[] = $file_matches[1]; } $files will then contain an array of the end of the URL, IE: Array ( [0] => recording-1-week [1] => recording-2-week [2] => recording-3-week )

Keep in mind that if this is a CMS to be distributed publicly, an AV scanner is probably not going to work out. Number 1 that's probably going to consume a lot of resources and shared hosts get grumpy about that, and Number 2 unless you build an AV to include with your project, you can't guarantee every hosting setup has an AV that works in the same way.

You could band-aid it with a lot of .htaccess rewrite rules.

No, there are other ways an attacker could potentially recover a password. One way is to cause a collision. Collisions are more common and easy to find the smaller and faster the hash algorithm is. For example, MD5 is pretty easy to find collisions. A collision is basically another value creating the same hash. So an attacker would loop through endless amounts of permutations until something created the same hash. Using a stronger algorithm like sha256 or sha512 is going to significantly decrease the chances of this happening. The one and only role of a salt is to prevent rainbow table attacks. That's it. You would have to create a rainbow table for every user. If you have hundreds of thousands of users, you're talking an extremely high amount of storage for those rainbow tables. Not to mention the time it would take to create them. You would need a very dedicated attacker. Like kicken said, 10 sounds good. There's no need to go crazy with the salt and store like a 40 character string, you're just taking up unnecessary storage space. 10 (or less) characters will still do its job just fine. Basically, it is a static string (usually long and random, say 256 bit or so) that is used to compute the hash. It is just extra entropy that is required to have to reproduce the same hash. So even if an attacker got ahold of your hashes, they would also need the cryptographic key which means you would have to be compromised in two places instead one (database and the filesystem). Sorry, but this is simply not true. The amount of time it takes to break MD5 with modern hardware is laughable. After creating an inefficient looping function in 10 seconds and using a wordlist, I can generate 400,000 MD5 hashes in .5 seconds with 1 thread on my Core i5. Now think about people who actually care and have 4 CUDA cards running in unison. They're going to obliterate MD5. In fact there are websites that exist to search MD5 hashes and get back a plaintext result. Obviously salts would thwart that, but I'm just pointing out how broken MD5 is for anything security related.

Yes, which would be represented in hexadecimal by two hexadecimal digits.

I'm not sure what you mean by "goes beyond 0-F".

No, it takes two hexadecimal digits (since each digit is 4 bits) to represent 1 byte. Like the letter "a" in hexadecimal is "61". So therefore you should be able to see why it would take 64 hexadecimal digits to represent 32 characters (bytes).

You can get the file extension like this: echo pathinfo($filename, PATHINFO_EXTENSION);

It works fine for me. Try taking the @ out of @imagecreate, and make sure error reporting is on. error_reporting(-1); ini_set('display_errors', 1);

You can either have the form submit to the current page so that you don't actually leave (although there will still be a page re-load) or you can use AJAX to eliminate a page re-load all together.

Not really sure what you are asking here. Can you be more specific?

phpinfo() doesn't show every function known to PHP. Do you have "hash"? If so, that is referring to the hash package which contains hash_hmac, among other hashing functions. Once again if your PHP version is >= 5.1.2, you have hash_hmac().

Do I need hash_hmac installed on my virtual server or just hash()?? Debbie They are two completely different functions. EDIT: But if you have hash(), then you also have hash_hmac(). Because they are part of the same package and were introduced to PHP in the same version (5.1.2).

It's simple: What is happening vs what is supposed to happen.

Generally the manual will tell you these things. For hash_hmac, it is available since PHP 5.1.2. If you aren't running at leash 5.1.2 you could use the PECL module.

In what context? There are 8 bits in 1 byte. Most characters are 1 byte, though I think that depends on how it is stored in memory.