php - multiple - tags input js

Mejores prácticas para almacenar información bancaria en una base de datos (9)

1) El sitio web inicialmente estará en un servidor de alojamiento compartido (esta es mi primera preocupación). --MUY MAL. No tener un control administrativo absoluto sobre el servidor y poder mantener alejados a otras personas es un problema realmente grande.

Me preocuparía mucho que esté accediendo directamente a la base de datos desde el servidor web front-end. Eso es un gran no-no con los datos financieros.

Incluso si tiene el algoritmo de cifrado más sólido de todos los tiempos, debe evitar que alguien secuestre su sistema y lo utilice para descifrar los datos para ellos. No necesitarán la llave, solo necesitarán su aplicación para hacer el trabajo por ellos. Esto es asumiendo que está usando una sola clave para cifrar y descifrar los datos o que está recuperando los datos de la base de datos para mostrarlos a los usuarios del sistema.

Ok, aquí está la cosa. Si tiene que hacer estas preguntas, no tiene la experiencia técnica para hacerlo correctamente. No estoy tratando de parecer malo, es solo un hecho. Iría a trabajar con un grupo de personas experimentadas que lo hagan profesionalmente primero. Habrá muchas cosas que no se mencionan aquí que deberán ser tomadas en consideración. hay muchas cosas sobre seguridad que no están escritas por sí mismas. Cosas que no aprenderás leyendo un libro. Esto es algo muy difícil de construir, ya que hay grandes recompensas para las personas que ingresan a los sistemas financieros.

Resumen de respuestas:
No lo hagas Las implicaciones legales y financieras serán desastrosas. Busque soluciones de terceros establecidas o contrate a un experto. Nunca almacene información confidencial en un servidor compartido. Investigación para el mecanismo de encriptación más apropiado.

Estoy creando un sitio web para un cliente que necesita almacenar la información bancaria de sus clientes (enrutamiento + número de cuenta) en la db para depósito directo. Aquí hay algunos detalles:

1) El sitio web inicialmente estará en un servidor de alojamiento compartido (esta es mi primera preocupación).
2) Estoy usando PHP / MySQL.
3) Planeo usar mcrypt.
4) La clave estará ubicada fuera de la raíz web.

Por favor, hágame saber sus pensamientos. Si es posible, proporcione algunos recursos sobre el procesamiento de ACH.

¡Gracias!

EDITAR: Esperaba tal respuesta, ya que también me aterran los problemas de seguridad que existen. He expresado mi preocupación a mi cliente y este será un buen soporte.

EDIT 2: se alejará de esto. No estaba contento con la idea en primer lugar! Investigaré la API de pago masivo de PayPal.

Creo que puede resolver este problema sin almacenar ninguna información bancaria a través del uso de algo como la API de pago en masa de Paypal . De esa manera, su cliente puede pagarle a las personas, y PayPal almacena toda la información para que usted no tenga que hacerlo.

Si desea leer acerca de todos los pasos que debe seguir para tener una posibilidad remota de proteger los datos financieros confidenciales de su cliente, haga clic en '' Cumplimiento con PCI '' de Google.

Si no tienes el miedo mortal de almacenar datos financieros en línea, eres terriblemente ingenuo.

Creo que todo el mundo aquí ha anunciado su disgusto por la situación, así que solo dejaré un indicio sobre otro problema al hacer cualquier tipo de criptografía (lo cual estaremos de acuerdo es necesario):

¡Los datos tienen que estar encriptados en alguna parte!

Si lo hace en el servidor, un servidor comprometido solo hará el cifrado y los pasará sin cifrarlos.

Si lo hace en el cliente, esto es un poco más seguro, pero todavía deja la puerta abierta si alguien tiene acceso a su servidor: en teoría, pueden abrir un agujero XSS (es decir, insertar un script remoto en su página). .) que envía una copia a su caja antes de cifrar ...

Al final: si realmente considera hacer esto en un servidor que podría no ser seguro en un 110%, CAMINAR .

Estoy de acuerdo con los demás, esta es una muy mala idea.

Se pueden obtener servidores dedicados por entre $ 79 y $ 99 al mes; si eso no fuera asequible, realmente me preguntaría por qué están procesando la información bancaria para comenzar. La forma preferida sería tener la base de datos separada de la caja web en este caso también. Preferiblemente con algunos firewalls y otra protección entre ellos (es decir, 2 firewalls, uno frente al servidor web y otro entre el servidor web y la base de datos).

Pero cualquier cosa sería mejor que usar hosting compartido. Quiero decir, puedes conectarte directamente al servidor SQL y ver todas las bases de datos disponibles. ¿Qué tan fácil sería saltar directamente con una piratería mínima?

Además, dígame el nombre del sitio para que nunca me registre y coloque mi información bancaria en él. :)

Además, asegúrese de tener un seguro de errores y de autorización antes de continuar con el alojamiento compartido.

Hable con un abogado acerca de sus posibles responsabilidades antes de continuar. Tener datos bancarios personales almacenados en un servidor de alojamiento compartido tiene el peligro por escrito. No tienes control sobre quién puede finalmente obtener sus manos sobre los datos.

Otra preocupación es que no son los datos de su cliente, ¡son los datos del cliente de su cliente ! Es posible que pueda llegar a un acuerdo con su cliente para indemnizarlo, pero no cuando sus clientes están involucrados. Una vez que los datos se vean comprometidos, ¡volverán a ti y los clientes te llevarán la espalda!

Me enfrentaba a una situación similar a la tuya y la resolví de esta manera.

Como no realizará el procesamiento de ACH, averigüe si la API de procesamiento de ACH tiene la capacidad de crear un cliente.
Si es así, este objeto del cliente normalmente incluirá el número de cuenta, el número de enrutamiento, etc., y almacenará el token en su base de datos. (Entonces, cuando el usuario da su información, la pasa directamente a su procesador ACH a través de HTTPS y guarda el token).
Siempre que tenga que cargar su cuenta, pase este token al procesador, ¡y listo!

De esta manera, no está guardando ningún número de cuenta ni de enrutamiento en su base de datos, e incluso si alguien piratea la base de datos, solo ve el token, que es bastante inútil, no pueden hacer nada con él, ya que es específico del procesador ACH.

He hecho lo mismo con las tarjetas de crédito usando Stripe.

¡Buena suerte!

No lo hagas

Bu, si es necesario, use criptografía de clave pública / privada. Almacene y use solo la clave pública para cifrar los datos que ingresan a la base de datos. Almacene la clave privada en una ubicación segura (es decir, no en el servidor alojado, sino en una máquina local "segura" con los controles de acceso adecuados). Cuando sea necesario, descargue los datos a la máquina local, use la clave privada para descifrarlos y listo.

Pero seriamente, encuentra una manera de evitar hacer esto si es posible.

No tienes experiencia en esta área, y ni siquiera puedes encontrar latas de gusanos tan grandes en un club de almacén. Este es un caso en el que su cliente necesita contratar a un experto en dominios; Si está interesado en hacer este tipo de trabajo en el futuro, intente trabajar muy de cerca con el experto y absorber todo el conocimiento que pueda.

Para información bancaria, su servidor debe estar en su control no compartido.

Además, mcrypt no es muy seguro. Sé que está incorporado, pero sugeriría algo que no sea tan pirateable como RSA. Si alguien obtiene la información, no debería poder hackearla sin una clave privada.