Ok, vizskywalker was finally able to solve the problem with my registration, but when I tried to login with my testaccount, it just continuously give me the "wrong username/password" error, i registered a new account and tried again, but still fails...

here's the authentication page...:

I don't know if it matters, but the registration also uses $password=md5($password), so the password is already encoded, like i said, i dont know if that matters.

also, since the error i get is displayed with maybe the problem is there..


[And again...sorry im bugging you guys..again ]

It does matter. Unless you can hash strings in MD5 in your head, I'm assuming you are entering your password in plain-text - so basically, the plain-text password is going to be compared to the hashed password, meaning they won't match.

Try using:

(assuming you haven't used a custom salt) after '$pass=addslashes($pass);'.

Also, just a tip - where possible, use a single quote instead of a double quote, as it is quicker and less memory intensive. Strings within double quotes are checked for variables, escape characters, special formatting etc, so it takes longer to process. You could also use urldecode() instead of checking for '%20'.

For example:


Oh, and you want to be careful when passing user-entered values directly to a MySQL query. It can create all sorts of problems of the security kind.

That it is to say, it's better to use single quotes if you can. There are obviously many situations in which the alternative is required.

(We need an edit button.)

I ám using that code ($pass=md($pass) look again

What I meant, was that with the registration, the password will come hashed into the table, and I thought with the login it would then require to insert the hashed password (a whole different password then the user wanted..), so basically, im using the md5 in the registration ánd with the login, and theres where my question earlier comes in, does thát matter?

and could you tell me what a custom salt is?
I've heard about it before, but i don't know what people mean by that

and thanks for the tip on single quotes and the urldecode()
??
Their values go through some stripping first don't they? Once stripped and secured from sql injection, then the values are send through a query, so why wouldn't this be secure?

Heh, I didn't notice the MD5 hashing. My apologies.

It goes through some stripping, but certainly not enough to be considered secure.

A 'salt' is bascially just a random generation used in conjunction with the cipher key, essentially causing the end result to be harder to break. If you are using the md5() function alone, then you shouldn't need to worry about it.

I not 100% sure what you're asking in regard to comparing hashed values. If you encrypt the password entered in registration and then store that encrypted value in the database, then yes, you need to encrypt it again when entered during login for comparison. The password entered by the user will obviously not be in an encrypted form, so you can't compare a raw value against an encrypted value and come out positive. I think that's what you're asking about.

Because there are no visible errors in the script shown here, I am going to assume that the problem lies either in the registration script, or your database structure. Try looking into both of these.

I've send you a PM, read and think about it please