#66 Bueno no sé si alarmista es el post o los lectores (yo me incluyo), el post no aclara como hace todo el proceso y eso nos a confundido un poco, pero el post sigue siendo interesante.

#60 Si lo has probado entonces tendrás razón. O quizá han arreglado la aplicación al ver el post en menéame

#60 y #47 si es como decis, entonces al app no es vulnerable y el post es directamente falso e incorrecto.
En el post no da a entender que hay que cambiarse la CA.
Coincido en que cifrar otra vez es un absurdo con con que este https bien implementado es suficiente.

#62 Claro que sí hombre, implementar más seguridad en una aplicación de PAGOS es tontería

#63 Según entiendo con mis conocimientos básicos del tema, si como dice #60 hace falta tener una CA _{¿o un certificado?} corrupto previamente instalado en el teléfono la aplicación tendría la misma seguridad que cualquier navegador ¿no? pero está claro que la aplicación puede tener más seguridad llevando el certificado embebido o comprobando que la CA es tal y no es otra, una seguridad extra que no les cuesta nada de implementar y que puede evitar muchos problemas.

#64 Como ya dije en #47, "utilizando su propio almacén de CAs de confianza mejoraría bastante la seguridad", ya que el control de las CA pasaría del usuario del dispositivo al desarrollador.

No obstante la situación actual de la aplicación no es ni mucho menos como para dedicarle un post alarmista en el que no se explica claramente los requisitos previos (instalar una CA autofirmada en iOS, lo cual es un acto que pide confirmación y saltan advertencias de seguridad, y si es un móvil de empresa NO deja instalarla) y se tergiversa la realidad (texto plano es cuando NO hay SSL y en las capturas se aprecian siempre URL con https, y en ningún momento se indica que sin el requisito previo la aplicación NO envía ni un sólo dato)

#66 Bueno no sé si alarmista es el post o los lectores (yo me incluyo), el post no aclara como hace todo el proceso y eso nos a confundido un poco, pero el post sigue siendo interesante.

#63 Todo lo que se añada suma, pero si ya estas cifrando con un método, mas vale que cifrar bien con ese método, y no cifrar con dos y los dos mal.

#60 Hola, yo también he probado con varios proxies ssl y nada, sin instalar el certificado fake en el móvil esto no rula... El post da a entender que directamente interceptando el tráfico ssl con un certificado falso se ve todo y no es cierto. Es alarmista y confuso en mi opinión.

#56 Lo dice en #16 #17 y #18 , tienes razón en que en artículo no se entiende muy bien.

#59 He decidido hacer una prueba de concepto para ver si verdaderamente es como dice el autor del artículo.
Con un proxy interceptando SSL y una CA autofirmada, da error al iniciar la conexión SSL y no deja continuar.
Levantando un servidor suplantando el del BVVA y realizando DNS spoofing, el mismo comportamiento.

Conclusión: si no añades CA al móvil, la aplicación no te deja continuar ni envía un sólo dato.

Para mi gusto, igual de segura que cualquier navegador de cualquier dispositivo.

#60 Si lo has probado entonces tendrás razón. O quizá han arreglado la aplicación al ver el post en menéame

#60 y #47 si es como decis, entonces al app no es vulnerable y el post es directamente falso e incorrecto.
En el post no da a entender que hay que cambiarse la CA.
Coincido en que cifrar otra vez es un absurdo con con que este https bien implementado es suficiente.

#62 Claro que sí hombre, implementar más seguridad en una aplicación de PAGOS es tontería

#63 Según entiendo con mis conocimientos básicos del tema, si como dice #60 hace falta tener una CA _{¿o un certificado?} corrupto previamente instalado en el teléfono la aplicación tendría la misma seguridad que cualquier navegador ¿no? pero está claro que la aplicación puede tener más seguridad llevando el certificado embebido o comprobando que la CA es tal y no es otra, una seguridad extra que no les cuesta nada de implementar y que puede evitar muchos problemas.

#64 Como ya dije en #47, "utilizando su propio almacén de CAs de confianza mejoraría bastante la seguridad", ya que el control de las CA pasaría del usuario del dispositivo al desarrollador.

No obstante la situación actual de la aplicación no es ni mucho menos como para dedicarle un post alarmista en el que no se explica claramente los requisitos previos (instalar una CA autofirmada en iOS, lo cual es un acto que pide confirmación y saltan advertencias de seguridad, y si es un móvil de empresa NO deja instalarla) y se tergiversa la realidad (texto plano es cuando NO hay SSL y en las capturas se aprecian siempre URL con https, y en ningún momento se indica que sin el requisito previo la aplicación NO envía ni un sólo dato)

#66 Bueno no sé si alarmista es el post o los lectores (yo me incluyo), el post no aclara como hace todo el proceso y eso nos a confundido un poco, pero el post sigue siendo interesante.

#63 Todo lo que se añada suma, pero si ya estas cifrando con un método, mas vale que cifrar bien con ese método, y no cifrar con dos y los dos mal.

#60 Hola, yo también he probado con varios proxies ssl y nada, sin instalar el certificado fake en el móvil esto no rula... El post da a entender que directamente interceptando el tráfico ssl con un certificado falso se ve todo y no es cierto. Es alarmista y confuso en mi opinión.

#49 #47 #31 Según dice el autor del post ( #21 ) no es necesario añadir ninguna CA ni modificar nada en el teléfono, ya que la aplicación acepta certificados autofirmados sin mostrar siquiera un mensaje de warning.

#50 No, para nada. Los certificados los maneja el sistema operativo y algunas aplicaciones (en escritorio) como Firefox, que tienen su propio contenedor de certificados. Dudo mucho que BBVA haya implementado su propio contenedor en una pequeña aplicación o implementado su propia librería SSL. ¿Alguna prueba que sostenga lo que dice Oscar o tu?

#51 Yo te digo lo que dice la noticia, no lo he probado por que no tengo cuenta en BBVA ni tengo interés. Muchas aplicaciones se pueden configurar para ignorar los errores de certificados, por ejemplo wget si le pasas el parámetro --no-check-certificate se comerá cualquier certificado.

#51 perdón? Cualquier app de Android puede detectar certificados SSL no válidos y por ejemplo no seguir ejecutando nada, mostrar un warning o lo que sea.
De hecho puedes como en la propia web de development de Android hablan de ello: http://developer.android.com/training/articles/security-ssl.html
También puedes no aceptarlos por defecto cambiando parámetros en el manifest, como dicen en esta respuesta de StackOverflow: http://stackoverflow.com/questions/2012497/accepting-a-certificate-for-https-on-android
De hecho como he dicho antes, yo hago una app para un banco grande y es lo primero que se hace en la app, comprobar que el certificado es válido.

Si a ti te la pela la seguridad que te pueda dar una app de un banco, bien. A mi no me gustaría que NADIE pudiera ver mis contraseñas para poder hacer una transferencia o lo que sea por internet.
Creo que toda seguridad es poca en algo tan sensible como datos bancarios. Nosotros ofuscamos el código, encriptamos la base de datos temporal(que guarda mientras la app está activa la lista de movimientos y cuentas, cuando no usas la app durante 5min, te desloga y se borra. También ocurre si cierras la app, obviamente), se verifican los certificados, además nunca se mandan los datos sensibles en texto plano y no recuerdo qué mas cosas se le metieron a la app. Sólo por si acaso pasa algo.

#50 Según el texto del artículo "ya que el usuario ha podido instalar en su teléfono móvil el certificado del atacante así que todas las comunicaciones quedarían expuestas".
Sobre #21, no dice que no haya añadido estos certificados autofirmados manualmente a través de los ajustes de iOS, sólo "que se están fiando de un CA que no es el suyo".

#56 Lo dice en #16 #17 y #18 , tienes razón en que en artículo no se entiende muy bien.

#59 He decidido hacer una prueba de concepto para ver si verdaderamente es como dice el autor del artículo.
Con un proxy interceptando SSL y una CA autofirmada, da error al iniciar la conexión SSL y no deja continuar.
Levantando un servidor suplantando el del BVVA y realizando DNS spoofing, el mismo comportamiento.

Conclusión: si no añades CA al móvil, la aplicación no te deja continuar ni envía un sólo dato.

Para mi gusto, igual de segura que cualquier navegador de cualquier dispositivo.

#60 Si lo has probado entonces tendrás razón. O quizá han arreglado la aplicación al ver el post en menéame

#60 y #47 si es como decis, entonces al app no es vulnerable y el post es directamente falso e incorrecto.
En el post no da a entender que hay que cambiarse la CA.
Coincido en que cifrar otra vez es un absurdo con con que este https bien implementado es suficiente.

#62 Claro que sí hombre, implementar más seguridad en una aplicación de PAGOS es tontería

#63 Según entiendo con mis conocimientos básicos del tema, si como dice #60 hace falta tener una CA _{¿o un certificado?} corrupto previamente instalado en el teléfono la aplicación tendría la misma seguridad que cualquier navegador ¿no? pero está claro que la aplicación puede tener más seguridad llevando el certificado embebido o comprobando que la CA es tal y no es otra, una seguridad extra que no les cuesta nada de implementar y que puede evitar muchos problemas.

#64 Como ya dije en #47, "utilizando su propio almacén de CAs de confianza mejoraría bastante la seguridad", ya que el control de las CA pasaría del usuario del dispositivo al desarrollador.

No obstante la situación actual de la aplicación no es ni mucho menos como para dedicarle un post alarmista en el que no se explica claramente los requisitos previos (instalar una CA autofirmada en iOS, lo cual es un acto que pide confirmación y saltan advertencias de seguridad, y si es un móvil de empresa NO deja instalarla) y se tergiversa la realidad (texto plano es cuando NO hay SSL y en las capturas se aprecian siempre URL con https, y en ningún momento se indica que sin el requisito previo la aplicación NO envía ni un sólo dato)

#66 Bueno no sé si alarmista es el post o los lectores (yo me incluyo), el post no aclara como hace todo el proceso y eso nos a confundido un poco, pero el post sigue siendo interesante.

#63 Todo lo que se añada suma, pero si ya estas cifrando con un método, mas vale que cifrar bien con ese método, y no cifrar con dos y los dos mal.

#60 Hola, yo también he probado con varios proxies ssl y nada, sin instalar el certificado fake en el móvil esto no rula... El post da a entender que directamente interceptando el tráfico ssl con un certificado falso se ve todo y no es cierto. Es alarmista y confuso en mi opinión.

#47 Bravo a tu comentario en lo concerniente a los programadores. Cualquiera que se dedique (o se haya dedicado) al tema de la consultoría informática en España, sabrá que el programador, que con suerte anda cobrando 24K, es el último mono. A veces incluso, le habrán reportado ese problema al Jefe de Proyecto de turno, pero al final, el equipo de trabajo suele ser una barco en la tormenta creada por el comercial de turno.

Es más, me jugaría el cuello a que han echado mas horas que la puerta para poder cumplir con "los compromisos" adquiridos por el comercial/gerente/[inserte aquí al tocapelotas de turno]