2010-03-23 20 views
5

El escenario es que quiero cifrar números de finanzas en una columna con un tipo de datos de int en una tabla de servidor sql. Es una gran aplicación, por lo que es difícil cambiar el tipo de datos de la columna de tabla de int a cualquier otro tipo de datos.¿Hay un método de encriptación para una columna con un tipo de datos de int?

Estoy usando sql server 2005 y asp.net C#.

¿Hay un método de cifrado bidireccional para una columna con un tipo de datos de int?

¿Podría utilizar una función definida por el usuario en SQL Server 2005 o posiblemente un método C#?

+0

¿Qué desea hacer exactamente aquí? Parece no sensato y realmente no sé cómo responder más que "no" o "sí" aquí. – TomTom

+0

Estoy preocupado por ti, ya que es posible que tengas serias fallas en el diseño de seguridad en la aplicación. Quizás si proporciona el contexto de por qué desea implementar la seguridad de esta manera, podemos proporcionar una solución al problema de la causa raíz. –

+0

@John Sansom: El escenario es simple. Queremos que nuestros datos financieros se cifren en la base de datos por razones de seguridad. – Mike108

Respuesta

1

XOR?

:)

Hmm, necesita más texto ...

+0

XOR no es tan bueno porque el mismo valor dará como resultado el mismo valor encriptado. Y los enteros "cercanos" también darán como resultado valores cercanos. (A menos que use un XOR diferente para cada fila). – Thilo

+0

De ahí el :) después de la respuesta. – leppie

0

Hay algunos esquemas de cifrado de dos vías que está disponible en .Net.

Simple insecure two-way "obfuscation" for C#

Usted puede convertir el número entero a ella de matriz de bytes equivalente o convertirla en una cadena de base 64 y cifrar eso.

+0

Ninguno de ellos son FROM int TO int, sin embargo. Ese es el problema principal. En cualquier esquema sensible, el resultado es tan largo como la clave. Para una encriptación de Int a Int, una tabla de reemplazo es la única solución que se me ocurre, y eso tendría 4 mil millones de entradas;) O algo de cambio de bits (como XOR), pero eso apenas cuenta como encriptación. – TomTom

+0

Sí. El problema principal es "FROM int TO int". – Mike108

+0

Mike ¿por qué harías eso? Se supone que los datos encriptados son inútiles de mirar. A la luz de eso, ¿por qué le importaría qué tipo es el resultado cifrado? –

4

Lo siento pero simplemente no puedo ver la razón para encriptar números en una base de datos. Si desea proteger los datos de las miradas indiscretas, seguramente SQL Server tiene seguridad incorporada, ¿sí?

En ese caso, proteja la base de datos con su seguridad estándar. Si no, obtenga un mejor DBMS (aunque me sorprendería si fuera necesario).

Si tiene bits de la información de la tabla que desea poner a disposición (como algunas columnas pero no otras), use una vista o un activador para actualizar otra tabla (menos segura), o una transferencia periódica a esa mesa.

+0

Puede tomar los archivos de la base de datos y examinar el binario sin procesar para obtener información valiosa. Eso pasaría por alto la seguridad estándar a menos que toda la base de datos esté encriptada, lo cual creo que requiere la edición Enterprise. Puede encriptar columnas individuales con SQL Server pero luego es difícil usarlas con Entity Framework. –

+0

@Ian, creo que es un hecho que sus servidores importantes deben ser físicamente seguros. De lo contrario, puede DOS una corporación simplemente saliendo con ellos. Del mismo modo, las rutas de red a un servidor también deben estar protegidas de modo que no pueda, por ejemplo, telnet a ellas de cualquier manera. – paxdiablo

+0

Aparentemente, Sony perdió 12.700 números de tarjetas bancarias que no estaban encriptados. –

0

Bueno, cada injective, surjective función de int a int se puede utilizar como una forma de "codificar" un número entero.

Puede crear dicha función creando una matriz aleatoria con 65536 elementos sin entradas duplicadas y usando f(i) = a[i]. Para "decodificar" tu int, simplemente crea otra matriz con b[i] = x | a[x] = i.

Como han mencionado los otros, esto puede no ser lo que REALMENTE desea hacer. =)

Editar: ¡Mira el comentario de Jim Dennis!

+0

El problema con esto es que el mismo valor dará como resultado el mismo valor encriptado. Entonces todavía puedes encontrar parejas de personas con el mismo salario. – Thilo

+1

Es posible que pueda hacerlo con una columna adicional que contenga sal. Si los valores de sal son lo suficientemente grandes (32 valores aleatorios, por ejemplo), entonces elimina casi todas las colisiones. (Incluso podría tener una restricción ÚNICA en la columna de sal, impuesta por el motor RDBMS). En general, la idea aquí sigue siendo absurda ... pero teóricamente ... –

Cuestiones relacionadas