Password delivery problem

When handling sensible information in the internet it has become common to verify users by a combination of password and username. More often than not the first communication between a web service and a new user is the registration. Therefore this point of exchange is quite vulnerable for many kind of attacks (man-in-the-middle, spoofing, knock-back,..), mostly with the goal to fetch the registration data for a third party. The first step towards countering such methods is to establish a somewhat secure channel before requesting any detailed data from the user, but passwords must be verified and for that they have to be transmitted. Besides https and ssh there are many other protocols that increase the overall security, but still submitting passwords in plain is not an option for various reasons. What is the best way to establish a secure handshake between webservices and users? or how can they both agree on one password without the need to sent it?

Taggings:

Submitted by Michael Havlicek on Tue, 12/13/2011 - 06:01
1 answer

Encoded Password submission

The basic idea in this approach is to encode the password before sending it, no matter in which direction. Therefore we could be sure that the plain password cannot be read without breaking the encoding before. While this approach has some merit, it is only really effective in reality when the encoding is either hard, lossy or both as with an encoding that is neither, a rule may be found to extract the original password again.
On the other hand, sending a password that went through such treatment to the user, it would/should be impossible for the user to find out if this password is really his or not. All web services that provide a reminder function where the stored password is sent to the user, and this password is, above all, in plain text too, may not be considered secure at all.
For this reason such reminder functions can only work with additional information (e.g. “whats the name of your first pet?”) provided by the user that was agreed upon earlier.
So to ensure the privacy of the password through its whole lifecycle is hard and needs some adjustments to otherwise accepted behavior, on the side of the users as well as the system.

The password must be generated by the user, it is then encoded locally with a lossy method and transferred over a secure connection (ssh,…) to the server where the password will be stored in a lossy state. All further compares base on the user sending a lossy encoded password and the server side controlling it.

Submitted by Michael Havlicek on Tue, 12/13/2011 - 07:29