Transmisión de contraseña segura a través de tcp/ip no encriptado

Question

Estoy en las etapas de diseño de un protocolo tcp/ip personalizado para la comunicación móvil cliente-servidor. Cuando no se requiere (los datos no son sensibles), me gustaría evitar el uso de SSL por razones generales (tanto en latencia de handshake como en ciclos de conservación).

Mi pregunta es, ¿cuál es la mejor manera de prácticas de transmisión de información de autenticación a través de una conexión no encriptada?

Actualmente, me gusta SRP o J-PAKE (generan tokens de sesión seguros, son compatibles con hash/salt, y permiten patear en TLS cuando sea necesario), que creo que ambos están implementados en OpenSSL. Sin embargo, soy un poco cauteloso ya que no veo mucha gente que use estos algoritmos para este propósito. También agradecería sugerencias sobre cualquier material que discuta este tema en general, ya que tuve problemas para encontrarlo.

Editar

Quizás la pregunta debería haber sido: ¿hay mejores métodos de enseñanza para las contraseñas sin cifrar seguras a través de TCP/IP? Si no, ¿cuáles son las razones para seleccionar un método en particular sobre otros? (La respuesta de Rooks está más cerca del espíritu de esta pregunta hasta ahora, incluso si viola la carta).

Edición, parte deux

estoy interesado principalmente en el caso de la autenticación de cliente-servidor, donde existe la expectativa de que ambas partes tienen un secreto compartido (contraseña) a priori.

Answer 1

Usted debe echar un vistazo a "Diffie-Hellman key exchange":

Diffie-Hellman de intercambio de claves (D-H) es un protocolo criptográfico que permite que dos partes que no tienen ningún conocimiento previo de la otra para establecer conjuntamente un secreto compartido clave sobre un canal de comunicaciones inseguro. Esta clave se puede usar para encriptar comunicaciones subsiguientes utilizando un cifrado de clave simétrico.

Una vez que haya intercambiado una clave, puede cifrar su contraseña con esta clave y transmitirla a través del protocolo inseguro.

Answer 2

Podría usar un algoritmo de desafío-respuesta. El algoritmo es el siguiente:

• El servidor envía una cadena aleatoria al cliente.
• El cliente combina esta cadena con la contraseña (combinando, puede xor ellos o simplemente anexarlos).
• El cliente calcula un hash (por ejemplo, SHA1) del resultado y lo envía al servidor.
• El servidor calcula el mismo hash utilizando este número aleatorio y la contraseña real.
• El servidor compara los dos valores hash.

Dado que no debe almacenar una contraseña en texto plano, sino como un hash en su lugar, el cliente debe calcular este hash desde el principio.

Es posible que haya varias bibliotecas implementando esto, por lo que probablemente no necesite codificarlo usted mismo.

Answer 3

Todavía creo que SSL es su mejor opción, después de todo ¿por qué reinventar la roncha cuando tanto puede salir mal? No tiene que comprar un certificado caro si tiene una lista de certificados "buenos" y "malos" (comprometidos). openSSL es completamente gratuito, y no veo una buena razón para no usarlo.

Algunas cosas que quizás no sepa: ssl handshakes can be resumed.

También puede usar SSL/TLS sobre UDP para reducir su llamada DTLS.