haciendo una aplicación de iPhone / Android que envíe una contraseña de usuario a mi servidor, ¿cómo puedo protegerla?

Question

haciendo una aplicación de iPhone / Android que envíe una contraseña de usuario a mi servidor, ¿cómo puedo protegerla?

#1 de dr jimbob (4 votos)
#2 de D.W. (4 votos)
#3 de GdD (1 votos)
#4 de Thomas Pornin (1 votos)
#5 de Bryan Agee (0 votos)

1

Estoy creando una aplicación para iPhone / Android para mi sitio web, los usuarios ya tienen una cuenta en el sitio web y la aplicación les permitirá iniciar sesión.

No tengo SSL en mi sitio web, pero es solo un sitio web de reseñas y no se transmiten datos privados. Sin embargo, en un teléfono móvil me parece más peligroso, ya que los teléfonos móviles siempre usan una red inalámbrica. y la gente a veces usa las mismas contraseñas para varios sitios web.

Lo que quiero hacer es: La aplicación hash de la contraseña dos veces, con dos algos de hash que se consideran seguros, y luego la transmite, por lo que al menos si alguien encuentra los datos, solo puede usarla para mi sitio web, o quizás otros sitios web que usen la misma técnica de hashing. tal vez incluso más de dos veces, según lo que sea apropiado.

¿Es esta una buena idea?

y también, ¿son las redes móviles vulnerables a este tipo de ataques de rastreo? ¿Existe comúnmente algún tipo de protección, como una relación de tipo SSL con el proveedor de la red cuando alguien simplemente se sienta en un restaurante y se le proporciona una conexión?

hash encryption mobile

pregunta fiftyeight 28.08.2012 - 18:11

fuente

5 respuestas

0

Personalmente, me gustaría morder los $ 100 / año para comprar un certificado SSL. No es mucho, y si le preocupa la seguridad, vale la pena. Si alguien encuentra una contraseña y obtiene acceso a su sitio, puede usarla para encontrar otras vulnerabilidades, lo que conlleva mayores compromisos: cosas como la posible inyección de SQL para obtener contraseñas / hashes, cuentas de correo electrónico, etc. de otros usuarios.

Si no va a hacer esto, entonces use un valor predecible para saltear, como una marca de tiempo. De esta manera, el hash solo es válido por un breve período de tiempo, y al olfatearlo no daría acceso permanente.

<script type="text/javascript"> var timestamp = new Date().valueOf(); var hash = sha256(sha256(userpass)+salt+timestamp);

Envía tanto el hash como la marca de tiempo al servidor para su comparación (ejemplo de php):

<?php if ($_POST['timestamp'] / 1000 - ts() > 60) { //throw error or exit, password was hashed more than a minute ago if (sha256($userHashFromDatabase.$salt.$_POST['timestamp'] == $_POST['hash']) { // Login successful -- do stuff } else { // login failed }

respondido por el Bryan Agee 28.08.2012 - 18:47
fuente

Lea otras preguntas en las etiquetas hash encryption mobile

Direcciones IP extrañas que aparecen en mi servidor Cómo prepararse para competiciones de hacking [cerrado]

score 4 · Answer 1

¿Puede la gente escuchar a escondidas en las redes móviles? Definitivamente. También es probable que su servidor esté conectado a la red móvil a través de Internet, donde las personas pueden escuchar a escondidas. Además, las personas utilizan con frecuencia la conexión wifi desde sus teléfonos (en lugar de la conexión de datos 3g / 4g), que de nuevo pasará por Internet y está sujeta a muchos potenciales detractores.

¿Por qué no SSL? Si tiene su propio dominio, puede obtener un certificado SSL de una CA (entidad de certificación) firmada y confiable de forma gratuita (https://startssl.com), lo que evita ataques de escuchas ilegales / MitM, etc.

Hay problemas con tu esquema. Por ejemplo, ataques de repetición (el espionaje reproduce el hash), MitM altera los mensajes después de la autenticación (por ejemplo, reemplaza la revisión legítima con spam o una vulnerabilidad XSS), cortafuego, etc. Puede mejorarlo marginalmente con marcas de fecha y hora, pero de nuevo es mucho más sencillo Solo para usar SSL que para intentar reinventar la rueda.

Puedes pensar, no estoy tratando con tarjetas de crédito, ¿por qué me importa si soy inseguro? Tal vez usted tenga revisiones y algún spammer decida robar las credenciales de muchas cuentas para revisar positivamente sus productos. O algún script kiddie se enoja con una revisión y borra todas las revisiones que puedan de su sitio. O su idea de un hash fuerte es sha-1 sin sal (p. Ej., Trabajó para linkedin) y alguien captura los hashes enviados a través de la red y pronto captura un millón de hashes y brutos sha-1 los obliga en paralelo en un incidente embarazoso.

score 4 · Answer 2

Hay una frase que quiero enseñarte: "¿Cuál es tu modelo de amenaza?" Si interactúas con gente de seguridad, te garantizo que uno de ellos te lo preguntará en algún momento. Esta pregunta es una sugerencia para usted de que no ha pensado cuidadosamente qué problema está tratando de resolver.

Cuando leí su declaración "No tengo SSL en mi sitio web, pero es solo un sitio web de reseñas y no se transmiten datos privados, sin embargo, en un teléfono móvil me parece más peligroso", lo que percibo es Que no estás pensando cuidadosamente en la seguridad. Pareces estar reaccionando sobre la base de sentimientos e impresiones superficiales y asociaciones emocionales. Ese no es el derecho de hacer seguridad. En su lugar, debe analizar el riesgo real, pensar en las posibles mitigaciones para defenderse de esos riesgos y luego averiguar si valen la pena.

En tu pregunta, no, no te recomiendo que hagas el negocio de doble hashing de contraseña funky. No intente ser demasiado inteligente, y no intente reinventar la rueda; muchos otros lo han intentado antes, y es probable que repita un error que ya han cometido.

Básicamente, hay dos opciones que pueden tener sentido para usted:

Use SSL. Si le preocupa el riesgo de escuchas ilegales y ataques de intermediarios, la solución correcta es obtener un certificado SSL y habilitar SSL. No se recomienda hacer doble hash con una contraseña personalizada.
No haga nada. Personalmente, creo que una respuesta más razonable es: no se moleste con SSL. No te preocupes por eso. No hagas nada especial. Usted dijo que no hay datos privados y que el sitio web no es importante. Si es así, entonces usar HTTP ordinario está bien. (Sospecho que esta respuesta podría no ser tan popular en este sitio: para la gente de seguridad, a veces hay una tendencia a intentar que todo sea lo más seguro posible. Sin embargo, esa no es siempre la respuesta correcta en la práctica).

Elige uno u otro. Pero no trates de hacer alguna cosa rara y personalizada. Hay una razón por la que las soluciones estándar son, bueno, estándar.

score 1 · Answer 3

Depende de cuáles sean tus metas. Si desea asegurar la transferencia de contraseñas como desarrollador de Android, puedo decir fácilmente que es mucho más eficiente habilitar los https en su sitio web y en la aplicación en lugar de diseñar e implementar un método de hashing. Sin embargo, implementaría un método de hashing de algún tipo, al menos para almacenar la contraseña en el servidor, de modo que, si se hackea, no se pierdan datos de la contraseña.

score 1 · Answer 4

Si su modelo de seguridad está efectivamente evitando que se revele la contraseña a los espías, entonces algún tipo de hash podría hacer el truco. Sin embargo, querrás hacerlo bien.

Si el usuario inicia sesión en el sitio web (a través de la aplicación) simplemente mostrando un hash de la contraseña, este hash es suficiente para la autenticación. Alguien que espíe en la línea aprenderá el hash y, por lo tanto, también podrá iniciar sesión en el sitio. El valor de hash es contraseña equivalente . Si el mismo usuario tiene la misma contraseña en otro sitio (que no conoce), entonces su hash tendrá algunos beneficios solo en la medida en que el otro sitio (que no conoce) no tuvo la misma idea y usó la La misma función hash que la que te propones utilizar. Si su sitio requiere SHA-1 (contraseña) para iniciar sesión, y el otro sitio también requiere SHA-1 (contraseña) para iniciar sesión, entonces el atacante que esté aprendiendo SHA-1 (contraseña) a través de espionaje acceda a ambos sitios, precisamente lo que quería evitar.

La solución es asegurarse de que su función hash sea distinta de la de cualquier otro sitio. Para hacerlo, incluya el nombre del sitio en la entrada de hash. Por ejemplo, si el nombre del sitio es www.example.com y la contraseña es sdfl478gb9 , entonces haga que la aplicación calcule SHA-1 ("www.example.com:sdf1478gb9"). Otros sitios pueden usar diferentes estrategias, pero es muy improbable que usen el nombre de su sitio (y, si lo hicieron, es probable que buscaran problemas activamente).

Por supuesto, el uso de SSL podría ser más sencillo. Sobre todo porque controla tanto la aplicación como el servidor: puede crear un certificado autofirmado para su servidor e incrustar una copia de ese certificado en la aplicación, evitando todos los problemas con la "CA establecida".

score 0 · Answer 5

Personalmente, me gustaría morder los $ 100 / año para comprar un certificado SSL. No es mucho, y si le preocupa la seguridad, vale la pena. Si alguien encuentra una contraseña y obtiene acceso a su sitio, puede usarla para encontrar otras vulnerabilidades, lo que conlleva mayores compromisos: cosas como la posible inyección de SQL para obtener contraseñas / hashes, cuentas de correo electrónico, etc. de otros usuarios.

Si no va a hacer esto, entonces use un valor predecible para saltear, como una marca de tiempo. De esta manera, el hash solo es válido por un breve período de tiempo, y al olfatearlo no daría acceso permanente.

<script type="text/javascript">
var timestamp = new Date().valueOf();
var hash = sha256(sha256(userpass)+salt+timestamp);

Envía tanto el hash como la marca de tiempo al servidor para su comparación (ejemplo de php):

<?php
if ($_POST['timestamp'] / 1000 - ts() > 60) {
    //throw error or exit, password was hashed more than a minute ago
if (sha256($userHashFromDatabase.$salt.$_POST['timestamp'] ==
    $_POST['hash']) {
    // Login successful -- do stuff
} else { 
    // login failed
}