Password

[JackG]

When storing a password not sure how to do it. Managed to used SHA1 and MD5 to store as encrypted but then when attemtinp to login it would not work.

Do we need to decrypt it or something? If so how, do we do this in sql for Mysql?

Jack

[dannystommen]

SHA1 and MD5 are the most common ways to store a password. This is not 'encrypted', but 'hashed'. This hashed value cannot be decrypted or 'de-hashed'.

If you want to log in, first hash the value that is inserted by the user, and next, compare this value with the hashed value in de database

[JackG]

I've tried using MD5 and it seems to work. The password typed does not appear in the db table. I am unsure of one thing though; when you copy and paste the 32 character string into the login page, are we still suppose to be able to access the page? Should it be like that?

I place the md5 around the insert statement. I'm guessing we also place it onto the login page where the password will be entered? But that doesn't sound secure to me. Even if I placed MD5 on the login page as well, someone could just modify the code, right?

Jack

[Alsvha]

I've tried using MD5 and it seems to work. The password typed does not appear in the db table. I am unsure of one thing though; when you copy and paste the 32 character string into the login page, are we still suppose to be able to access the page? Should it be like that?
<snip>

No.

As danny says above you must compared the hashed values.

When the user is created with the password you hash the value and store the hashed value in the database.
When the user then logs on, he types his password (unhashed) in a log in form, you then hash the entered password and compare that hashed result with the hashed result in the database.
If those two match - you can log him in.

[olivthill2]

Store the hashed password, or the encrypted password in a field declared with char, and not varchar because you would have troubles if your string of characters contains non Ascii characters.

[JackG]

Thanks. Yeah, I think thats what I did.

The hashed string you mention, I think that is the 32 character string. The password typed is converted into this 32 character string, (so I don't see the password entered). And the password is entered, and later hashed(using MD5) when submitted, and is compared.

What I meant was, if the login page isn't hashed, and you copy and paste the hashed(32 character string), you gain access to the page. But this time the owner of the password would'nt have access, since he would not know the hashed equilavent of his password.

I know this is silly, but its just that, this doesn't seem secure to me. Hashed or not hashed, you can still gain access, by simply modifying code(removing hash conversion on login page) and simply copying and pasting the hashed value into the login form. So the only benefit seems to be, that you don't know what they typed as their password.

Jack

[olivthill2]

This is the reason why pages like that are often using https instead of http, because, you cannot, or it is very difficult, to see or alter the code called with https. You could also used certificates.

[Alsvha]

Thanks. Yeah, I think thats what I did.

The hashed string you mention, I think that is the 32 character string. The password typed is converted into this 32 character string, (so I don't see the password entered). And the password is entered, and later hashed(using MD5) when submitted, and is compared.

What I meant was, if the login page isn't hashed, and you copy and paste the hashed(32 character string), you gain access to the page. But this time the owner of the password would'nt have access, since he would not know the hashed equilavent of his password.

I know this is silly, but its just that, this doesn't seem secure to me. Hashed or not hashed, you can still gain access, by simply modifying code(removing hash conversion on login page) and simply copying and pasting the hashed value into the login form. So the only benefit seems to be, that you don't know what they typed as their password.

Jack

Well - no. Not at all.

If somebody enters the hashed values in the password box, then that hashed value would be hashed, and produce yet another value which wouldn't match.
(A hash of a hash does not produce the same hash).
Unless - of course - you plan on doing the hashing client side in which case you have much bigger problems, or unless you provide access to the source code on the server.
The log on functionality of course should be placed somewhere the client doesn't have access,

So the only way to get access is to enter the correct password or to hack your server. In both cases they, then, are much bigger problems then what you outline.

I think/hope you have some concepts mixed up here?