none
Proteger cadena de conexion de SQL Server

    Pregunta

  • Utilizo VB 2015 para windows Forms y al utilizar un archivo ".dbml" genera esta codigo:

    <Connection Mode="AppSettings" ConnectionString="Aqui muestra la cadena de conexion" SettingsObjectName="BS_2015.My.MySettings" SettingsPropertyName="eps_bargainConnectionString" Provider="System.Data.SqlClient" />
      <Table Name="dbo.TblUsuComplementos" Member="TblUsuComplementos">

    En las propiedades del mismo archivo, tambien la muestra y en el app.config:

    <connectionStrings>
             <add name="BS_2015.My.MySettings.eps_bargainConnectionString"
                connectionString="Aqui tambien la muestra"
                providerName="System.Data.SqlClient" />
        </connectionStrings>

    Cual de las cadenas seria a proteger y donde podria leer para lograrlo ?

    lunes, 29 de agosto de 2016 21:26

Respuestas

  • La del .dbml solo se usa en tiempo de diseño, esa no se entrega una vez compilado el programa. La que usa en tiempo de ejecución es la que está en el archivo miprograma.exe.config, que se genera automáticamente al compilar copiándolo del app.config. Lo mejor es dejar el app.config "en claro" para que puedas trabajar con él en tiempo de desarrollo, y meter el cifrado sobre el .exe.config que es el que tienes que entregar junto con el .exe para que el programa funcione en la máquina del usuario.

    Puedes leer la cadena (cifrada) con el configurationmanager, luego pasarla por tu rutina de descifrado, y finalmente entregársela al datacontext como parámetro del constructor cuando lo instancies (me imagino que de forma predeterminada estás usando el constructor sin parámetros, en cuyo caso va directamente a leer el .config y no te da oportunidad de descifrarla).

    En cualquier caso, esto no será 100% seguro porque para descifrar la cadena el programa tiene que tener la clave de descifrado, con lo que desensamblándolo se puede sacar esa clave. Lo ideal es eliminar la necesidad de cifrarla; para ello lo mejor es usar autenticación integrada contra la BD, para que se usen internamente las credenciales del usuario que hizo login en Windows. Si no se puede, entonces usar unas credenciales distintas para cada usuario, y que se guarden en el user.config en lugar del app.config, para que el propio Windows las proteja de los demás usuarios.

    • Marcado como respuesta eduepa miércoles, 31 de agosto de 2016 15:50
    miércoles, 31 de agosto de 2016 7:01
  • Gracias Alberto, voy a estudiar la situacion y vere como hacerlo. Gracias
    • Marcado como respuesta eduepa miércoles, 31 de agosto de 2016 15:50
    miércoles, 31 de agosto de 2016 15:50

Todas las respuestas

  • La del .dbml solo se usa en tiempo de diseño, esa no se entrega una vez compilado el programa. La que usa en tiempo de ejecución es la que está en el archivo miprograma.exe.config, que se genera automáticamente al compilar copiándolo del app.config. Lo mejor es dejar el app.config "en claro" para que puedas trabajar con él en tiempo de desarrollo, y meter el cifrado sobre el .exe.config que es el que tienes que entregar junto con el .exe para que el programa funcione en la máquina del usuario.

    Puedes leer la cadena (cifrada) con el configurationmanager, luego pasarla por tu rutina de descifrado, y finalmente entregársela al datacontext como parámetro del constructor cuando lo instancies (me imagino que de forma predeterminada estás usando el constructor sin parámetros, en cuyo caso va directamente a leer el .config y no te da oportunidad de descifrarla).

    En cualquier caso, esto no será 100% seguro porque para descifrar la cadena el programa tiene que tener la clave de descifrado, con lo que desensamblándolo se puede sacar esa clave. Lo ideal es eliminar la necesidad de cifrarla; para ello lo mejor es usar autenticación integrada contra la BD, para que se usen internamente las credenciales del usuario que hizo login en Windows. Si no se puede, entonces usar unas credenciales distintas para cada usuario, y que se guarden en el user.config en lugar del app.config, para que el propio Windows las proteja de los demás usuarios.

    • Marcado como respuesta eduepa miércoles, 31 de agosto de 2016 15:50
    miércoles, 31 de agosto de 2016 7:01
  • Gracias Alberto, voy a estudiar la situacion y vere como hacerlo. Gracias
    • Marcado como respuesta eduepa miércoles, 31 de agosto de 2016 15:50
    miércoles, 31 de agosto de 2016 15:50