AJAX vs regular POST security

[totl]

My question is how secure is AJAX.

I am thinking of transferring my registration form from standard HTML+PHP to ExtJS and want to use AJAX. However I am not sure how secure it is.

Generally I understand(correct me if I'm wrong) that there's no difference for the web server, whether it is an AJAX request or a regular HTTP POST request.

All the form needs to do is submit the data to the server and based on the server-side validation, display an error or redirect to a log-in page.

Will it be the same security-wise if I substitute my present registration form with the AJAX powered one.

P.S.

I tried searching this forum and found this thread here:
http://extjs.com/forum/showthread.php?t=3932&highlight=ajax+security

however I didn't find it informative.

[hendricd]

It depends really on wether your current auth page uses HTTP Auth or Application-based Auth.
If it's based-on/coupled-with HTTPAuth, you'll need this (http://extjs.com/forum/showthread.php?t=10672), as Ext does not support passing HTTPAuth:userid, password on each AJAX request.

Otherwise, it should make little difference, but offer a bit more flexibility in you login presentation.

[totl]

Well, basically, as I have tried to explain this previosly, the page just submist the information over to the server side script and then the latter either registers the user or throughs out an error.

The reason, I want to use AJAX is simply to keep the users from filling-in the form again if say the username they want to have is already taken.

[hendricd]

I understand what you want to do.



Otherwise, it should make little difference, but offer a bit more flexibility in you login presentation.

I'm just not sure there's still a question on your previous post \:D/

[BernardChhun]

hey totl,

Most stuff on the net isn't secure to the point where no one can't decipher it sooner or later. Ajax calls and normal POSTs are both "sniffable" and "reverse-engineerable" by various tools.

The good thing is you can slow them down by encrypting the data that goes on the wire. So with that said, I'd probably put your login form under the https protocol to make it more secure than on normal http

[dantheman]

I'd probably put your login form under the https protocol to make it more secure than on normal httpThe best advice.

If you can't use HTTPS, you might check out the CHAP (http://en.wikipedia.org/wiki/Challenge-handshake_authentication_protocol) pattern for login processing.

A quick overview:

Server sets up the login form with 2 things:

a random hash (as random as practical :D )
a JS function to hash the uname/pw and then hash that w/the random hash

once the user enters their uname/pw, the JS function performs the above hash and substitutes it for the actual password form value (ie the password never leaves the browser)
the server can look up the hashed value (stored locally) of the uname and pw and then do its own hash w/the random value.
the result should match what came over from the client.
additionally, the server can/should keep the random hash in a periodically expiring table, to ensure that the login-form is fresh, etc.


This will prevent even a network-omniscient 3d party from discovering the password,
but will not prevent such a person from impersonating the client, if the subsquent action
to verifying the login is to use simple cookie-stored authentication hashes... /:)

--dan

[totl]

Where did the login form come from? :)

I was talking about registration. However thanks for all your comments.

[BernardChhun]

Where did the login form come from? :)

I was talking about registration. However thanks for all your comments.

:)) I misinterpreted your initial post I guess...but the HTTPS protocol is still the way to go.

[dantheman]

And I just followed Bernard off the cliff . . . :D

--dan