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

Question

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?

Thanks

Answer 1

AJAX calls are just plain HTTP request.

It behaves like ordinary HTTP request and also comes with all the advantage and disadvantage of it. It is not any safer.

To make your AJAX calls safe, there are several ways you can try:

1. Use SSL. SSL will encrypt messages between your user and your server. The disadvantage of SSL is that you will have to pay additional fee for valid SSL certificates. Invalid SSL certificates while usable, does not provide the same level of guarantee of security to the users.
2. Encrypt requests before being sent, client-side. E.g.: hash users' password before being sent over the network. Most of the time, you don't need users' plain text password anyway. This is not usable when users don't allow client side scripting to run.
3. And apart from common misleading information where POST is safer than GET, it is not. Both are equally open for attackers to see.

Answer 2

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.

Answer 3

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).

Answer 4

The plain text password transmitted via AJAX will be as secure as the same password transmitted via a normal HTTP post. That is to say AJAX uses HTTP and can therefore be intercepted and sniffed. Your best bet is to use HTTPS (SSL).

For further reading on AJAX and security I'd recommend the following readings

• Top 10 Ajax Security Holes and Driving Factors
• Ajax security holes and how to fill them

Answer 5

This is just as safe as having a login form that is not SSL secured be sent over the wire, like almost all forums out there do!

Answer 6

It isn't safe. Don't send unencrypted passwords. It's very likely that they will be intercepted at some point you will have a major problem.

Here is a video example of capturing a telnet password. Telnet sends in plain text and this nicely illustrates the major problem you have if you even think of doing this. Any two bit script kiddie can snag a plain text password faster than you can so "Oh my God, where did my database go?"

Answer 7

Make sure the target of your AJAX call is a trusted HTTPS:// page and you've made it every bit as secure as any of the other sends of the same information that the rest of your application is doing. Most libraries / frameworks don't limit you to just HTTP:// for your AJAX calls.

Answer 8

You are sending it in the clear, so anyone with sniffing/listening/etc the client's network will be able to easily see the password. The AJAX call is just a plain old HTTP message. If you want to see this in action, fire up a copy of wireshark and make the request your self. You will be able to see the password in the HTTP packet.

Answer 9

Yes it can be read. Just like everything else without some kind of layer of security (See SSL)

To see it yourself run a tool like WireShark as you do your AJAX commands.

How likely? Not very, but the user's password will probably be saved in someone's log files in plain text. If someone eventually found it, then it could be bad news. Back in college, my networking class had access to some (semi) fancy routers. We had assignments where we signed up for accounts on random websites. As we did this, we noticed some very scary things on the log files in the routers. This was an eye opener for me to think about how every communication is tracked and most likely logged somewhere.

Answer 10

As others have mentioned it's no more safe 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) the server send a challenge (Some random string of bytes. Characters are fine.)
Server creates a challenge and a challenge id and saves it with an expiration.
Client recieves a challenge and a 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 it's 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.

Answer 11

As already mentioned, SSL is the best solution here. However, you could hash the password on the client side. If you google for it, you'll find plenty of javascript implementations of md5.

Answer 12

damn you guys worry me. SSL does not protect against the arp poisoning MITM attack. It would be fatal to worship SSL as you guys are. You must have a way to encrypt the password on the client side before it makes even one hop or else even a novice hacker will be able to intercept the password in plaintext