可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I asked here about a protocol that I was asked to implement, and how secure it was. Since it seemed clear from the very beginning that it was shit. Being so I ask:

Can you guys point me to some very simple login protocol (I am null at cryptography systems)?? I am developing both server and client side of the application and I have my own messengering system, so I have enough freedom.

Only 2 special characteristics for your suggestions.

Simple: the network this application is going to run over is not specially insecure and I only want to avoid the sending of the password in plain text
If possible, not a too long interchange of messages. The shorter, the better.

回答1:

Check out Challenge Response Authentication

Server includes a random challenge string in the login form
When you login, javascript hashes the password, and then hashes that with the challenge
Server then performs the same check (your DB should store hashed passwords, but this method prevents you from effectively using a salt for that hash since you'd have to broadcast this)

回答2:

Three pass protocol would be handy. Basically, it boils down to:

Person A encrypts his password, and sends it to Person B.
Person B encrypts the encrypted password, and sends it back to Person A.
Person A decrypts it, and sends it back.
Person B decrypts it, and gets the password in plaintext.

This way, the password is never sent in plaintext, neither are encryption keys. It's a relatively quick protocol too, since it relies (presumably) on symetric encryption, which is very quick.

回答3:

Storing the password hash in the database is not optimal secure in case the database contents get into unauthorized hands. There is no way to reverse the hash directly, but there are online dictinonaries (like here) for reversing hashed (pass)words.

In the DB you should store somethig like:

md5(login_name +  domain_or_appname_salt + password);

The salt in the middle prevents many forms of dictionary attacks.

On the clients side (in the browser) you would have a login form with username and password. A small piece of javascript would hash the userame + app_salt_ and password, so only the login_name and generated hash are sent to the server.

Now, the plaintext password will never be send to the server in plain text. So you should not have to rely on HTTPS here.

The same technique can be used in the password update form. Thus the server never knows the plaintext password.

I hope you got some inspiration from this and the other answers.

Happy Hacking!

Huibert

回答4:

If your protocol runs on TCP you can just write the authentication in clear and then wrap the communication with SSL. For example, if you are using port 1234 for your protocol, you can then close that port on the server and let clients tunnel it with SSH. This can be done programmatically and it is a very very common solution.

If your protocol runs over HTTP, you can do this in a standard way by using HTTPS. For example Basic Authentication over HTTPS is secure enough for the needs you specified.

On the other hand, if you never want to send the password on the wire, you need to do a challenge response authentication.

Server sends random string
Client sends hash of random string + password
Server verifies hash.

This has the downside that the password are going to be available (encrypted on in plain text) on the server though. If you don't want to store passwords on the server then you need to go back to my first example.