Seguridad en bancos (era Re: HA)

[Marco González Luengo]

El 4 de septiembre de 2009 12:32, Ricardo Munoz<rmunoz en tux.cl> escribió:
> El 4 de septiembre de 2009 11:44, Sebastián Veloso Varas
> <sveloso en sevelv.cl>escribió:
>
>> El 4 de septiembre de 2009 10:56, Ricardo Munoz <rmunoz en tux.cl> escribió:
>>
>> > El 3 de septiembre de 2009 23:58, Marco González Luengo <
>> > noquierouser en gmail.com> escribió:
>>
>
> [...]
>
>> > 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".
>> > >
>> >
>> > estan confundidos. COBOL se sigue usando no porque sea dificil (o caro)
>> de
>> > migrar sino porque cumple con su tarea, ademas de existir mucho codigo y
>> > conocimiento heredado. para que cambiar algo que funciona?
>>
>>
>>
>> Y sumale que Cobol no utiliza un metodo estandar de datos como SQL, usan
>> sus
>> archivos planos de informacion. Migrarlo debe ser complicadisimo, puesto
>> que
>> va amarrado al codigo y al modelamiento propio. Alguien me corrije si
>> existe
>> forma de conectorizar directamente Cobol sobre un DB actual.
>>
>
> existe.
>
> y para Oracle, DB2, etc. aunque eso de "actual" tampoco es tan asi, la
> primera version de Oracle se libero el an~o 1979. tambien puedes ejecutar
> programas en lenguaje C dentro de Mainframe, Java, y hasta codigo PHP.
> Mainframe es como la Matrix... puedes correr de todo y con recursos
> ilimitados (pagas por lo que usas)... "cloud computing" es el mismo concepto
> pero con acceso a traves de Internet.
>
> en todo caso, hay versiones de COBOL para Desktop (con ventanitas y botones)
> y tambien COBOL para Web.
>
>
>>  > respecto a que
>> > COBOL sea seguro o no, simplemente no aplica ya que los programas COBOL
>> > corren en un Mainframe con el cual se puede comunicar una aplicacion en
>> > Linux/Unix que a su vez ofrece las funcionalidades y datos mediante
>> > Webservices (por ejemplo en Java), los cuales a su vez son llamados por
>> la
>> > interfaz de usuario (JSP, ASP, PHP, etc.).
>>
>>
>> Por eso pongo en duda que es mas seguro, si un sistema actual (que es
>> conocido por muchos, accesible y cada dia vulnerable) o
>> un sistema manejado por pocos, que lleva años funcionando.
>>
>
> ningun sistema es seguro por si solo. el tema de la seguridad da para mucho,
> de hecho hay certificaciones [1] donde debes manejar no solo la seguridad de
> las aplicaciones, sino la seguridad fisica, gestion de riesgos, legislacion,
> etc.
>
> en resumen, que usen COBOL para la manipulacion de los datos no tiene
> ninguna relacion con la tecnologia que usen para la interfaz Web que
> finalmente es la que esta mas expuesta desde "afuera". pero se dice que el
> mayor riesgo no viene desde "afuera" sino esta adentro...
>
> [1] http://es.wikipedia.org/wiki/CISSP
>
> --
> Ricardo Mun~oz A.
> http://www.tux.cl
>

Efectivamente. El mantener un sistema viejo y con limitaciones
(arbitrarias o del mismo sistema) hace que con el tiempo estas cosas
se jodan solas ("la vejez mató al hombre y no la pistola que estaba a
su lado").

Ahora, por ejemplo, la limitante de tener claves de 4 dígitos tanto en
ATMs como en Web hace que 1 clave sea débil y la otra no lo sea tanto
(independiente del cartón de bingo o el llaverito numeral), por lo que
basta con apoderarse de la clave "difícil" para tener más del 50% de
posibilidades de acceso. Los 4 dígitos son absorbibles por el cajero
(ya hemos visto cómo se hace eso), por ingeniería social ("dame tu
clave del cajero o el patito muere") o por fuerza bruta ("dame la
clave o te saco la...").

He visto que el campo de contraseña de los ATMs tienen hasta 8 o 10
dígitos para poder insertar. Si tratas de poner una contraseña de,
digamos, 6 dígitos, después no puedes entrar al ATM. ¿Por qué? Porque
su clave *no es* de 4 dígitos.

Podemos reforzar cuanto queramos las transacciones web, pero las
transacciones por ATM (que están ligadas a web, querámoslo o no) son
la pata más coja de la mesa.