¿Por qué no se usa php para sitios bancarios o para transacciones bancarias?

Para los sitios bancarios o los sitios transaccionales principales, los costos de administración de riesgos hacen que sea mucho más fácil y económico para una gran empresa sentirse segura con una aplicación desarrollada en .NET y usa el marco de seguridad provisto con .NET que usar PHP. / p>

Al final del día, las organizaciones utilizarán el entorno más barato que creen que puede proporcionar la seguridad que desean en función de su apetito por el riesgo, su perfil de amenazas y el tamaño y tipo de los equipos de desarrollo.

Es probable que el desarrollo de una aplicación PHP segura cueste mucho más que una aplicación .NET a nivel empresarial.

He contratado como consultor de TI en cuatro de los principales bancos del Reino Unido, dos servicios comerciales del Reino Unido y un banco de los EE. UU. y nunca me he encontrado con un sistema web basado en PHP.

En mi experiencia, el 80% ha sido Windows / ASP y el resto de Java. La percepción actual es que Microsoft y Oracle son compañías profesionales y seguras que pueden brindar soporte para sistemas de misión crítica que funcionan 24 * 7, mientras que PHP y código abierto solo son utilizados por estudiantes y hackers. Sé que este no es el caso (también desarrollo con PHP para sitios de comercio electrónico), pero esa es la percepción. Además, los productos de MS y Oracle se integran bien con los mainframes de bancos heredados, mientras que PHP no es tan rico en características en esta área. Finalmente, a todos nos encanta el código abierto debido a su bajo costo, mientras que a los bancos no les preocupa el costo y pagarán una prima para obtener un servicio de soporte garantizado (la disponibilidad es más importante para ellos que el costo, ya que afecta la percepción del cliente de su productos).

Java es anterior a PHP por un margen bastante decente, y los bancos fueron algunas de las primeras instituciones en comenzar a computarizar su infraestructura. Entonces, como regla general, la mayoría de ellos ya tenían muchas cosas en su lugar, a veces en Java, mucho antes de que PHP existiera.

Pero eso no es todo. PHP es generalmente considerado como un lenguaje web solamente. Teóricamente puedes usarlo para otras cosas, pero es un mal ajuste. Los bancos necesitan un lote más código para ejecutar sus sistemas que solo el front-end web. Y como la gran mayoría de su código (y, por lo tanto, sus programadores) no utilizan PHP, no tiene sentido usar PHP solo para el front-end web.

Pero eso no es todo tampoco. Java y .NET no son perfectos y ambos han tenido problemas en el pasado. Pero cuando comparas su reputación con PHP, Java y .NET salen oliendo a rosas. Ahora la reputación de PHP puede no ser merecida; hay muchos muy malos programadores de PHP y muchos muy malos código PHP que no es necesariamente culpa del lenguaje en sí . Sin embargo, es caritativo decir que PHP es un poco "peculiar" . Y si está buscando un diseño seguro y fácil de mantener sólido, hay un argumento sólido que hacer de que PHP no es su mejor opción.

Estoy trabajando en un banco francés, boursorama.com. Tenemos 3 bancos similares en España, Reino Unido y amp; Deustchland. Usamos PHP para todo, excepto para aplicaciones de carga pesada (C & C ++ en su lugar). Tenemos algún proxy Java, proporcionado por socios que no tienen ninguna otra solución.

Creo que PHP no es utilizado por las compañías bancarias principalmente porque su pila de tecnología es más antigua que PHP5. Antes de PHP5, no puedes dejar de lado características serias orientadas a objetos.

Desde mi experiencia, el Banco no tiene una sola pila de tecnología. Trabajan con socios externos a través de servicios que no necesitan ajustarse a sus tecnologías (SOAP, REST, ...). Entonces, en general, sus socios no necesitan participar en sus elecciones tecnológicas.

PHP en el futuro seguramente será un serio competidor para los lenguajes clásicos / profesionales como Java / C / .net. Se han logrado grandes avances en términos de estándares y estabilidad. Y los lenguajes de scripting tienden a ser más rápidos que nunca (mira las presentaciones de javascript v8).

En general, los lenguajes de código abierto como PHP rara vez se usan en entornos corporativos, ya que las personas tienden a asociar el valor con el precio (que las cosas gratuitas también son de baja calidad). Yo diría que esto es lo contrario de la realidad en el mundo de la programación, pero no estoy a cargo de ningún banco.

En cuanto a PHP en particular, es extremadamente difícil escribir una aplicación en PHP sin encontrarse en uno de sus principales defectos . Es improbable que alguien serio con respecto a la seguridad lo utilice (lo que desafortunadamente crea un círculo vicioso, donde ninguno de los principales desarrolladores de PHP sabe nada sobre seguridad). Por ejemplo, hay un gran número de formas erróneas para escapar de un cadena para una base de datos (incluidas las que se ve bien ), y casi nadie usa el < a href="http://php.net/manual/en/pdo.prepare.php"> forma más segura . O cómo la única forma correcta de hash de contraseñas en PHP solo se agregó recientemente y es aún difícil de usar ( y el hecho de que el valor predeterminado es increíblemente inseguro).

Esto no es cierto, PHP se usa ampliamente para transacciones bancarias. Sin embargo, es raro en los sitios de banca, porque los bancos pueden pagar IDE costosos como Visual Studio, por lo que prefieren hacerlo. También servidores dedicados. Puede omitir la seguridad tanto en java como en c # así como en PHP, también puede asegurar ambos al mismo nivel. Tiene que ver también con la base de datos. SQL Server funciona con C #, para Oracle se usa Java. Dicha base de datos se usa también por razones de seguridad, que no está disponible (hasta hace poco) en la pila LAMP.