views:

340

answers:

5

Hello there!!!

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.

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

2.- If possible, not a too long interchange of messages. The shorter, the better.

Thanks in advance, as always

A: 

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.

  1. Server sends random string
  2. Client sends hash of random string + password
  3. 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.

Sklivvz
+3  A: 

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)
Paul Dixon
+2  A: 

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.

Matthew Scharley
A: 

SASL is a secure authentication mechanism. Support for SASL is supplied in the Java standard libraries for releases 1.5+.

Michael Barker
+1  A: 

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

HuibertGill