Hace unos días compré un billete sencillo de Colonia (Köln) a Aquisgrán a través de la aplicación DB Navigator. El billete era válido durante 6 horas después de la compra, sin embargo, un temporizador comenzó a partir de las 00:00 y se detuvo a las 02:00 como se ve en la imagen de abajo.
¿Para qué sirve este temporizador?
P.D. Volví a Colonia con un billete diferente y volvió a aparecer el mismo temporizador.
Según este enlace (sólo en alemán), es para comprobar si ha comprado el billete justo ahora o con suficiente antelación. Las normas suelen ser que hay que comprar el billete antes de subir al tren. Ahora, con los billetes móviles, algunas personas "inteligentes" pensaron que basta con comprar un billete cuando ven al revisor, y viajar gratis cuando no lo ven. En el transporte de cercanías (especialmente en los tranvías y cada vez más en los trenes regionales) ya no hay un revisor en cada tren, sino equipos de control de billetes que recorren la ciudad. Obviamente, sólo pueden cubrir una pequeña parte de los vehículos de tránsito disponibles.
Esta es probablemente la razón por la que los operadores introdujeron este temporizador, para que sea visible para el conductor si usted ha comprado el billete justo ahora o hace más de 2 minutos.
¿No hay que escanear el código QR como cualquier otro billete de papel? Ese temporizador parece una solución bastante mala contra el fraude... Es lo mismo que comprar el billete y esperar a que el operador lo fiche.
@Alexis_FR_JP una versión hackeada de la aplicación DB forzar el temporizador para mostrar siempre 02:00 es probablemente disponible en algún lugar ya. Es un teatro de seguridad.
@JonathanReez Esto no es en absoluto un teatro de la seguridad; véase mi respuesta más abajo para saber por qué.
La respuesta de @dunni describe el ataque que esta medida de seguridad intenta mitgar. Un comentario en su respuesta afirma que esto es "teatro de seguridad"; yo describo en esta respuesta (porque esta explicación es demasiado larga para caber en un comentario) por qué no lo es.
La mayoría de las medidas de seguridad no pueden evitar completamente los ataques. Una medida de seguridad eficaz es aquella que aumenta el coste para el atacante de forma significativa y no aumenta también los costes para el defensor más allá de un rendimiento económico razonable.
Por este motivo, los controles aleatorios de los billetes funcionan, aunque a veces permiten viajar gratis: aunque un atacante puede simplemente no comprar un billete y tener la posibilidad de viajar gratis, si la sanción cuando se descubre es lo suficientemente alta, la mayoría de los atacantes potenciales optarán por comprar un billete antes que correr el riesgo de pagar la multa o sufrir otro castigo
En este caso, hay dos requisitos para un atacante: 1. Escribir u obtener una versión de la aplicación que parezca ser la oficial y que muestre el mismo resultado que si el usuario hubiera comprado el billete mucho antes de que el revisor llegara a comprobarlo. 2. Cargar lateralmente esta aplicación, ya que la Deutsche Bahn puede asegurarse con bastante facilidad de que una que aparezca en la tienda oficial sea retirada fácilmente.
Escribir una aplicación de este tipo es significativamente difícil; implica no sólo tener la habilidad de duplicar la propia aplicación, sino también superar cualquier medida de seguridad que proteja la aplicación original (como ser capaz de extraer de ella las claves necesarias para instruir a los servidores de la base de datos para comprar un billete).
Por supuesto, una vez que una persona escriba una aplicación de este tipo, podría ser compartida con otras personas incapaces de hacerlo. Pero encontrar una aplicación de este tipo una vez escrita tampoco es del todo trivial; DB también puede tener la capacidad, incluso si no está en la tienda oficial, de hacer que la retiren por medios legales. Si no pueden hacer eso, también pueden cambiar fácilmente el funcionamiento de su aplicación (diferentes claves de seguridad, diferentes protocolos de red, diferente visualización) para exigir al autor de la aplicación que la actualice.
Incluso en el caso de que la aplicación esté disponible fácilmente, el usuario debe ser lo suficientemente sofisticado como para descargar la aplicación (ya que no estará disponible en la tienda oficial de aplicaciones) y también debe estar dispuesto a correr el riesgo de seguridad personal de que el autor de la aplicación es malicioso y realmente escribió la aplicación para atacar a los usuarios que la descargan, en lugar de a DB.
Todo lo anterior se combina para hacer un costo bastante alto para el atacante, mientras que para DB agregar el temporizador a su aplicación existente es muy poco trabajo. Gastar unos pocos días de tiempo de los desarrolladores y probadores para añadir esta característica a la aplicación probablemente se amortiza muy fácilmente, incluso si evita que sólo el 50% de los atacantes potenciales ejecuten el ataque (aunque probablemente evita un porcentaje mucho mayor).
La razón por la que algo como los controles de seguridad de la TSA estadounidense se califican de teatro de seguridad es porque imponen unos costes muy grandes a los defensores a cambio de muy poco beneficio para los atacantes. Estos controles existen porque los costes son soportados principalmente por personas que pueden hacer poco al respecto (las aerolíneas y sus pasajeros), mientras que los beneficios (parecer que se está haciendo algo con respecto a un problema) recaen sólo en algunos funcionarios gubernamentales y elegidos que sufren poco el coste global.
"Escribir una aplicación de este tipo es significativamente difícil" -> sólo tiene que hacerlo una persona, después de lo cual decenas de miles podrían utilizarla. ¿Hay alguna razón por la que no se pueda codificar una marca de tiempo dentro del propio billete? No se podría falsificar la marca de tiempo, suponiendo que todo el billete está firmado.
¿O tal vez ya existe una marca de tiempo y el temporizador es sólo para la comodidad del usuario?
¿No es todo lo que necesitas una captura de pantalla del billete de la aplicación legítima, y dibujar una nueva caja de tiempo sobre ella? No veo por qué la aplicación necesitaría hablar con los servidores de la base de datos en absoluto, por lo que se presenta aquí.
Ya hay una buena respuesta: Proporciona una adicional indicador visual rápido en caso de que el pasajero haya comprado el billete sólo después de entrar en el vehículo y divisar al conductor.
Pero añadamos algo más de contexto.
Los controles de las multas no suelen amortizarse con ellas. Los controles de billetes se pagan consiguiendo que más gente compre billetes. El objetivo de los controles de billetes no es atrapar a los pasajeros que hacen trampas, sino animar a los pasajeros a comprar billetes válidos.
Hay muchas maneras de eludir el temporizador, empezando por "Mi teléfono acaba de fallar, el reinicio se hará en un minuto" y terminando con un software que crea un billete falso. Pero especulo que los creadores de la aplicación especularon que el temporizador recuerda a los posibles tramposos que el tiempo de compra es relevante. Eso animaría a esas personas a comprar billetes válidos.
Para abordar los comentarios a las otras respuestas, que plantearon la legítima preocupación de que los billetes falsos derroten el temporizador: el tiempo de compra sigue siendo relevante incluso si uno de los múltiples mecanismos que muestran que el tiempo de compra está vencido. Y ser atrapado con un billete falso puede ser mucho más incómodo que ser atrapado sin billete.
Esto explica de forma más directa y clara uno de los puntos clave que intentaba exponer en mi respuesta. Excelente respuesta.
"Mantiene honesta a la gente honesta" es probablemente la mejor razón detrás de todas estas características de seguridad. Cualquier seguridad de software desarrollada por humanos puede ser derrotada por otros humanos, si se les da suficiente tiempo e incentivo. Aumentar la dificultad de derrotar al sistema mantiene a más gente honesta.
Como dice el viejo refrán: las cerraduras no detienen a los ladrones, sino a la gente honesta.
Se trata de un sistema de tickets llamado Prueba de pago .
Históricamente, los revisores recorrían cada tren y comprobaban a cada pasajero, vendiéndole un billete si lo necesitaba. Sin embargo, esto resultaba caro para el personal, por lo que se buscó la forma de automatizarlo.
Se les ocurrió un "sistema de honor" modificado en el que la gente compraría billetes y llevaría una prueba de ello. Luego, se harían controles aleatorios, con multas costosas para los infractores.
Así que el temporizador es un intento de resolver ese problema. Muestra al inspector que el comprador compró el billete hace unos segundos pero lo más importante es que muestra al comprador que el el inspector sabe que .
El inspector ya puede obtener esa información del código de barras, por lo que es más bien un elemento disuasorio para el comprador.
ViajeroSabio es una comunidad de viajeros en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros viajeros, hacer tus propias preguntas o resolver las de los demás.
2 votos
Me pregunto si tienes 2 minutos para detener la venta, después de comprometerte.
0 votos
@Willeke Había un botón "Editar pedido", parecía activo tanto antes como después de que expirara el temporizador. No he probado, pero tu suposición podría ser un caso.
0 votos
@Willeke: Por desgracia, AFAIK no.
1 votos
Este temporizador no es específico de la aplicación de Deutsche Bahn, sino que también se puede ver en (casi) todas las aplicaciones de las empresas de transporte local.
0 votos
Solución tonta, insegura y fácilmente hackeable para un mundo con menos humanos manejando máquinas.
3 votos
O solución barata y suficiente cuando se mira cuál es el vector de ataque. Si utilizas el transporte local, y te fijas en la gente que engañaría y no compraría billetes, honestamente la mayoría de ellos lo más probable es que no sepan cómo hackear una aplicación móvil.
1 votos
No se trata de un billete DB, sino de un billete para la tarifa de transporte regional (VRS), que tiene la regla de los 2 minutos. En el caso de los billetes de los DB, no existe dicha regla (ni contador), aunque la app rechazará la venta de billetes para una conexión específica 2 (más o menos) minutos antes de la salida.