How to secure the password while it being sent usi

问题:

I'm trying to keep user's password secured, but I noticed that the header information send while submitting the form is visible to everyone. Is it secure or is there a way to keep it secure? I know how to add md5 to the password in JS, but MD5 isn't secure anymore and I can't add a salt with JS because everyone can find out what the salt is. So what are you suggesting to do? I think that soon I'll have a SSL to my website (https://), but I not sure, so I need another way to keep the communication safe. And even if I'll have an a SSL, so it is from the business plan of HostGator, and if I'm not mistaken, the SSL doesn't work on mobile. (The form sent via post using AJAX).

回答1:

AJAX is irrelevant.

The only way to secure your login page is to use SSL or TLS, which work fine on modern mobile browsers.

回答2:

I also think HTTPS is already available in most mobile browsers. But if you're sure it isn't in your situation, you could consider a public key cryptography js library. pidCrypt springs to mind. But only if it's really necessary, it's rather overkill in most cases I think.

回答3:

You can download from here http://pajhome.org.uk/crypt/md5/sha512.html the sha512.js and then declare a function like this:

function formhash(form, password)
{
    $(form).append('<input name="p" type="hidden" >');
    var p = $('input[name="p"]');
    p.val(hex_sha512(password.val()));
    password.val('');

    return p.val();
}

so afterwards you can send data to your server with ajax like:

var dataObj = {
    'username': $('input[name="username"]').val(),
    'password': formhash($('.form-signin'), $('input[name="password"]'))
}; 

and your password will be sent already encrypted. Of course you should use https to your login form page too.

回答4:

Mobile applications, and browsers, support SSL - that is not your issue here. If your host does not support SSL, then you need to switch off of it.

Client side crypto will provide you with no additional security. It might provide you user with additional security.

All of the attacks that could be used to get the password from the client could also be used to get the hashed or encrypted password from the client - your system would except that value, not knowing that it was not the user's browser that generated it. So client side crypto is not going to provide your site with any additional security.

The perspective is different if you are trying to protect your user. By using client-side crypto, you could make the argument that you never know the user's password, protecting the user in the event of a breach of your systems. Your system would still be compromised, but all of the other systems that use that password would not be.

For an authentication mechanism, you need Transport Layer Security, there is pretty much no way around it.