Simple secure php / javascript login

Question

I want to create a secure login, so I want to encrypt the password before sending it as a POST parameter. I do this using the SHA1 javascript function.

Then I understand that if someone intercepts an encrypted password, he can use it right away. Sending it as a parameter to the message of the same URL.

How can I be sure that the password comes from the input field? Maybe with a PHP session? I do not want to use secure http yet. Does anyone have a simple alternative?

Answer 1

How can I be sure that the password comes from the input field?

You can not.

Closest to this is the usual CSRF protection ... but it will only stop people who trick users into sending data from their site to your site. It will not protect passwords.

I do not want to use secure http yet. Does anyone have a simple alternative?

HTTPS is a simple option.

Answer 2

Sending the SHA1 password over the network to your server effectively makes the SHA1 hash a real password.

Besides the fact that you have no advantages, you are really impairing your security; If I steal your database using SHA1 hashes, now I can log in using these functions without even having to search the hashes to get a “real” password.

HTTPS is the only real way to protect your password from sending in text form. And while you go to HTTPS, make sure you change these SHA1 hashes to bcrypt.

If you are concerned about the additional costs of SSL certification, you can also create a self-signed certificate if you are not concerned about browser errors or are ready to add the certificate to a trusted list ( http://resources.arcgis.com/en/help/main/10.1/index. html # // 0154000005q6000000 ).

Answer 3

The only thing that can help you is to create a temporary salt for each session, then encrypt the password on the client side, and then decrypting the password using the same salt that was saved on the server side, this approach looks like a unique token that was used to prevent CRSF, because even a man-in-the-middle has captured a password that he cannot decrypt.

Finally, you need to create another (different algorithm) to save the password in the database, the conceptual idea above is to provide a password between the client and server.

explanation:

Client → Request → Server

Server -> Reply (sending a unique salt can be used with JavaScript like session_id ()) -> client

Client -> Executing JavaScript -> Password Encryption Using Unique Salt

Client -> POST -> Server

Server → password decryption with saved salt → password retrieval

I hope someone corrects me if the idea above is wrong!

Note: AES can be used for both JS and PHP

Salt = Key

Available tools:

AES Advanced Encryption Standard

jsaes: AES in JavaScript

PHP AES DEC / ENC

phpAES

Answer 4

Please grant the world and all your customers a favor and CONTINUE encrypting the password before sending it over unencrypted HTTP.

There are two sides to this problem, and in this case, both sides are you and the client you serve. Unfortunately, most users use the same passwords for many sites, since we do not have the memory capacity to process hundreds of sites with which we log in to hundreds of passwords, we, as end users, choose two or three and continue our life . You are certainly mistaken if you send your client passwords via HTTP without encrypting them first, and there is actually something that needs to be received. Trust your customers so that their passwords are probably the same as what they used to enter the bank, not fall into the hands of hacks or, more importantly, the hands of anyone involved in website development, because it’s harmful IT employees really exist and it’s very easy to get these passwords as they are sent to your application for server-side processing ...

I wouldn’t like to think how many web developers have read this article and decided against client-side encryption, this should be one of the first things we do is protect for users, not on our own ... Protecting your database done through a variety of procedures, and each security analyst has an opinion on what to do or not to do, hash-salty-spunked-wangled-whatever. client-side encryption should not be discussed.