No ha podido matar el Visual Basic, menos a COBOL... Att.
Jaime Chereau Ossa 2009/9/3 Marco González Luengo <[email protected]> > El 3 de septiembre de 2009 08:02, Sebastián Veloso > Varas<[email protected]> escribió: > > El 3 de septiembre de 2009 03:53, Marco González Luengo < > > [email protected]> escribió: > > > >> El 03/09/09, Daniel Serpell <[email protected]> escribió: > >> > Hola! > >> > > >> > El Wed, Sep 02, 2009 at 02:12:25PM -0400, Leonardo San Martin > escribio: > >> >> 2009/9/2 Rodrigo Gutiérrez Torres <[email protected]> > >> >> > >> >> > Acabo de hacer esa prueba con mi "aparatito" del T-Banc: escribí el > >> >> > número y, en cuanto cambió, presioné Enter. No me aceptó la clave y > >> tuve > >> >> > que reingresar por la actual. Al menos en mi caso, los relojes > andan > >> >> > "como reloj" :). > >> >> > > >> >> > >> >> Con la tecnología de hoy día, un "reloj electrónico" no se > >> atrasa/adelanta > >> >> fácilmente. Deben pasar unos cuantos miles de años para obtener > >> milésimas > >> >> de > >> >> segundos de desfase, ergo era de esperar el resultado de tu prueba. > >> > > >> > Mmm..., ¡ojalá fueran tan precisos! :-) > >> > > >> > Un reloj de cuarzo de precisión (calibrado de fábrica) puede llegar a > >> variar > >> > unos 30 segundos al año (aprox. 1ppm). Más precisión que esa requiere > >> > compensar según la temperatura ambiente de manera continua, con lo que > >> > puedes > >> > llegar hasta 3 segundos al año (aprox. 0.1ppm). > >> > > >> > El problema es que al envejecer, la frecuencia varia de maneras que no > >> > son predecibles. > >> > > >> > Lo que hacen los aparatitos de claves es que el servidor "aprende" el > >> > desface > >> > del aparato cada vez que lo utilizas, y predice el estado del reloj > >> interno > >> > al momento de verificar la clave. Y el aparatito se deshabilita luego > de > >> > unos años para que debas cambiarlo por uno nuevo calibrado. > >> > > >> > En el servidor utilizas una fuente de reloj más precisa, por ejemplo > un > >> > receptor > >> > de GPS o un reloj esclavo compensado por NTP. > >> > > >> > Daniel. > >> > > >> > >> Disculpen un poco mi salida de tópico, pero hay algo que me queda > >> dando vueltas de toda esta discusión, y tiene que ver con el dilema de > >> las passwords a veces forzadamente básicas e inseguras se solicitan o > >> asignan para estos sitios web y cajeros automáticos. > >> > >> Para mí es horriblemente injusto, incómodo e inseguro que, en mi caso, > >> sea forzado a usar claves de 4 dígitos para ATM y el sitio web del > >> banco. El "cartón de bingo" es prácticamente subutilizado en algunos > >> bancos. > >> > >> La verdad preguntaría a quién debo matar por tal aberración, pero > >> sería irme del tema. Por eso planteo ¿qué hay del forzar los malditos > >> 4 dígitos? > >> > >> > > Eso responde a que los sistemas bancarios son "arcaicos". Fueron > diseñados > > en Cobol, y actualmente siguen funcionando de la misma manera. En su > tiempo, > > no fue pensada quizas una solución mas avanzada de seguridad. Imaginate > > migrar o modificar un sistema completo bancario (la red bancaria nacional > en > > realidad) a un sistema moderno: hoy en dia especialistas en desarrollo en > > Cobol son los menos. Es por eso, que los cajeros a pesar de estar cada > dia > > mas bonitos, le coloquen animaciones y todo eso, la aplicacion de giro de > > dinero sigue siendo lento y vejete..jejeje.Lo importante es que aun > > funcionan ... (no se por cuanto mas) > > > > Espera... ¿todavía usan COBOL? Y más encima tienen millones... y no > son capaces de pagar lo que sea necesario para migrar los sistemas a > algo "más seguro". > > Con su permiso, pero mi Desert Eagle y yo tenemos una cita. XP > >
