The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Anyway, if you just submit an sha1() version of the plaintext version to the server, that's no good, since an attacker can just do the same.

We need to have a salt together with the password so that the value changes every time and the attacker can't do a replay attack.

So create a $_SESSION['login_salt'] = //random string func();

However, I can't do: hex_sha1(hex_sha1(form.password.value) + my_session_salt); since I can't compare the client input on the server side with the db password (my db password is not plaintext, which would be needed to compare in this way)

which would mean: replace all '2' chars by 'f', and add "352" from position 10 in the string. Obviously all those parts would be randomly server generated on each visit. Since the attacker doesn't have the same session salt, if he replayed the attack it would not let him in the system.

Now I'm not really a 'cryptologist' or whatever you call it so I don't know if this is safe at all.

i just reread your post and realized i misread it.
i cant think of a solution.

basically your concerned with possibly someone intercepting the data between the client and your webserver.

as far using an algorithm like 2f,352:10

maybe i dont understand, but if you dont want the password sent as plaintext, then you need to feed this 2f,352:10 to the client, so javascript could encode the password with it and then send it back. but if they intercept the data coming to the user, and they intercept the data coming from the user, they can still figure it out, because your algorithm is available to them in the javascript code. they can just use the 2f,352:10 to reverse the encrypted password. it would work only if you knew the attacker could not get a hold of the current 2f,352:10 routine.

I think you should take a look at Challenge-response authentication. Also, performing a sha1 (or any hashing method) on the same data twice (or more) is useless - it doesn't improve strength of the hashed data in any way.

I once coded up something similar that used a one-time salt per session. This salt is then also passed to the login page, and used in the sha1 encryption. I figured it would be safer as each salt was only used once. I'm not too sure anymore, and decided to drop it.

I think that if someone wants extra security, they should use SSL
(Pity it can be so expensive though...)

It's indirectly exposed, since it has to be properly calculated to hash the password. But I don't think this isn't a big security problem, looking from the right perspective: it allows you not to send a plain-text password and you still have the password hashed in db. Speaking of which, you may want to use SHA256 rather than SHA1, it's more secure.

Don't worry too much about exposing the algorithm, after all, even algorithm for hashing linux passwords is "open-source", but this in itself isn't insecure.