Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How safe is it to send a plain text password using AJAX?

Maybe the title is badly phrased but couldn't think of a better way of saying it.

I am working on a login system at the moment (nothing formal, just experimenting) and was planning on using PHPLiveX (an AJAX library) for some features. Basically you create some PHP functions which are then called via JavaScript. You can add parameters (getElementById) to the JavaScript that are transfered to the PHP function.

What I really wanted to know is whether it is safe to just call the function from JavaScript without encrypting the password first, then letting the PHP function encrypt it (SHA256 in this case). Can the data transfered via AJAX be intercepted? If so how likely is this?

like image 272
j82374823749 Avatar asked Jul 17 '09 19:07

j82374823749


People also ask

Is using AJAX secure?

Ajax is not inherently secure or insecure. It does however open up 'opportunities' for insecure code. A mistake I commonly see is as follows: The user is authenticated in code-behind when the page is loaded.

Is plain text safe?

A plain text password (or Plaintext, or Plain-text) is a way of writing (and sending) a password in a clear, readable format. Such password is not encrypted and can be easily read by other humans and machines.

Can I send plain text password over https?

Quick Answer:It is a standard practice to send "plain text" passwords over HTTPS via POST method. As we all know the communication between client-server is encrypted as per TLS, so HTTPS secures the password.

Are passwords sent in plaintext?

The passwords are ultimately not plaintext, since the client-server communication is encrypted as per TLS.


3 Answers

No more-or-less safe than a normal HTTP POST request issued by a browser (as in from a <form>)

The "fix" for this is the same "fix" for non-AJAX requests - use SSL.

like image 64
Peter Bailey Avatar answered Sep 29 '22 13:09

Peter Bailey


As others have mentioned, it's no more dangerous than sending an HTTP post from a form. In fact, it's the very same thing.

But if HTTPS isn't an option you can always use a challenge/response scheme over an unencrypted connection. Basically it works like this:

  • Server has a SHA (or whatever hashing algorithm you prefer) hash of the user's password.
  • Client has the password.
  • Client requests (using unencrypted AJAX) that the server send a challenge (a random string of bytes; characters are fine.)
  • Server creates a challenge and a challenge ID, and saves it with an expiration.
  • Client recieves the challenge and challenge ID.
  • Client hashes the password using SHA.
  • Client hashes the resulting hash with the challenge appended in some way.
  • Client sends the challenge ID (not the challenge itself) and the second resulting hash.
  • Server looks up challenge using ID if it exists and hasn't expired.
  • Server appends the challenge to the stored password hash and creates a hash using the same scheme as the client.
  • Server compares its hash with the client. If it's the same, the user is authenticated.

It's actually pretty simple to set up once you get the idea. Wikipedia has some additional information on it.

EDIT: I noticed I forgot to mention, whether or not the authentication is successful you must delete the challenge, regardless. Giving the client multiple attempts on one challenge could lead to security issues.

like image 20
Spencer Ruport Avatar answered Sep 29 '22 11:09

Spencer Ruport


Whether you are sending the password via AJAX or via a normal form, it is still sent via a HTTP POST (hopefully) request. So you are not adding or removing anything security wise.

The only way to prevent someone from intercepting your password is by using SSL (via AJAX or not).

like image 28
Andrew Moore Avatar answered Sep 29 '22 12:09

Andrew Moore