Cifrado de información en los archivos de configuración de ASP.NET

Una pregunta muy típica con la que me suelo encontrar es la de: «¿Cómo puedo hacer para proteger la información de mi cadena de conexión a la base de datos si ésta la pongo en mi web.config?».


Bueno, lo primero que he de decir es que siempre conviene usar mejor la seguridad integrada de Windows (cadena de conexión con «Integrated Security=SSPI;») que las cuentas propias de SQL Sever, por lo que en ese caso no sería necesario encriptar nada. Por otro lado existe un manejador de peticiones de IIS que impide que el contenido de los archivos web.config sea accedido mediante HTTP, por lo que sólo debería preocuparnos que alguien viera nuestra configuración en caso de tener un agujero de seguridad en el servidor o bien en nuestro código (por cierto, aprende a evitarlos), en cuyo caso tendríamos un problema mucho mayor que el hecho de que sepan las credenciales de un usuario de SQL Server, que ya de por si debería estar bastante limitado en cuanto a permisos.


No obstante es interesante saber que en ASP.NET 2.0 o 3.5 podemos encriptar cualquier sección de nuestro web.config de forma sencilla y transparente para nuestro código.


Podemos hacerlo por código, pero lo más sencillo y lo que usaremos casi todas las veces es la herramienta de línea de comandos aspnet_regiis.exe, ubicado en la carpeta «C:WindowsMicrosoft.NETFrameworkv2.0.50727«. Sólo hay que pasarle el tipo de proveedor de cifrado que queremos usar (-prov), el modificador «-pef» para indicar que queremos cifrar una ruta física, la sección a encriptar, y la ruta en el disco duro donde está el web.config a cifrar.


Por ejemplo:



aspnet_regiis.exe -pef «connectionStrings» «C:miRaizIISMisitioWeb» –prov «DataProtectionConfigurationProvider»


Que indica que queremos cifrar la sección «connectionStrings» del web.config ubicado en «C:MiRaizMiStioWeb», usando para ello el proveedor de la DPAPI (más sobre esto ahora).


De este modo obtendremos una cadena del estilo de esta:



 <connectionStrings configProtectionProvider=»DataProtectionConfigurationProvider»>
  <EncryptedData>
   <CipherData>
      <CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAt …… +hXziceYxOxY=</CipherValue>
   </CipherData>
  </EncryptedData>
 </connectionStrings>


(he quitado la mayor parte de la cadena cifrada porque es muy larga).


Lo más estupendo de esto es que no tendremos que tocar ni una sola línea de nuestro código para que funcione, ya que ASP.NET descifra de manera transparente la cadena de conexión al leerla desde la configuración.


Con el parámetro -prov (opcional) podremos especificar el proveedor de cifrado que queremos utilizar. Por defecto se nos proporcionan dos: el mecionado «DataProtectionConfigurationProvider» que cifra usando la DPAPI (Data Protection API de Windows), o bien el «RsaProtectedConfigurationProvider», que usa una pareja de claves pública/privada para cifrar y descifrar, y es el que se usará por defecto si no especificamos ninguno. Si quisiésemos usar un cifrado propio podemos construir una clase proveedora y especificarla con -prov al usar esta herramienta.


Desde mi punto de vista es mejor usar siempre DPAPI, ya que es una criptogra´fia muy segura y está atada por completo al equipo en elq ue se ha realizado el cifrado. De este modo aunque alguien lograse leer el archivo web.config y llevárselo a otro equipo no podría descifrarlo. Por este mismo motivo, una nota de precaución: debes usar esta técnica directamente en el servidor en el que va a estar la aplicación funcionando, puesto que si por ejemplo cifras en tu equipo de desarrollo y luego lo mueves a un servidor de producción, no se podrá descifrar la sección una vez allí. Así que haz el cifrado en el equipo donde va a funcionar la aplicación.


Se puede cifrar cualquier sección del web.config, y no sólo la de las cadenas de conexión. Las únicas que nose pueden cifrar son estas:


    *  <processModel>
    * <runtime>
    * <mscorlib>
    * <startup>
    * <system.runtime.remoting>
    * <configProtectedData>
    * <satelliteassemblies>
    * <cryptographySettings>
    * <cryptoNameMapping>
    * <cryptoClasses>


Las demás no hay problema ninguno si las ciframos, y se usarán del mismo modo, siendo el descifrado transparente para el programador.


¿Y si me olvido de lo que ponía y necesito volver a tenerlas en claro?


No hay problema. Podemos usar el mismo ejecutable con la opción -pdf para descifrar:



aspnet_regiis.exe -pdf «connectionStrings» «D:LogistiaCodigoLogistiaWeb»


Con esto conseguiremos que la sección vuelva a mostrar su contenido en claro.


Espero que te sea útil 🙂

TRUCO: Cómo conservar la distribución de los iconos del escritorio

Si hay una cosa que me revienta es que se me desordenen los accesos directos que tengo colocados en mi escritorio. Como tipo ordenado y rigoroso que soy, mis accesos directos no están colocados de cualquier forma, sino que los tengo agrupados de una manera lógica (para mi, claro), de forma que pueda encontrar rápidamente lo que busco. Lo que más tengo son accesos directos a Internet con direcciones de consulta, cosas de las que me quiero acordar, etc…


Por eso, cuando cambias la resolución, tienes un problema con los drivers de pantalla (como los que asistísteis a mi charla del lanzamiento de VS2008 recordaréis), o cualquier otra circunstancia, me paso media hora ordenandolos de nuevo. Y no estoy para perder el tiempo en chorradas. No sé cómo una cosa tan común como está no la incorpora Windows de serie. Parece mentira.


El caso es que me dió por ver si había forma de conseguirlo. Y efectivamente la hay, como era de esperar. Resulta que, nada más y nada menos que en el kit de recursos de Windows NT (ojo, NT, no ha llovido ni nada), se incluye una DLL llamada layout.dll que sirve precisamente para eso, y que aún hoy en día, tantos años después, sigue funcionando en XP o Vista sin problema. La he metido en un ZIP que puedes descargar aquí: layout.zip (4 kB). Creo que esta DLL se le atribuye al mítico Jeffrey Richter que la escribió como ejemplo de uno de sus libros.


El caso es que te bajas el ZIP, lo sdecomprimes y tienes dentro dos archivos: layout.dll y layout.reg.


Copia la DLL a C:WindowsSystem32 o la carpeta quivalente en tu sistema. Luego haz doble click sobre el archivo de registro y cuando te pregunte acepta que la información se pueda agregar al registro.


A partir de ese momento dispones de dos nuevas opciones en el menú contextual del elemento «Equipo» (o «Computer» en ingles) de tu menú de inicio, y sólo hay. Con ellos podrás guardar y posteriormente restaurar la posición de los elementos que tengas en el escritorio.



Ten la precaución de usar la opción de guardar cada vez que hagas un cambio sustancial en la disposición de elementos del escritorio o cuando añadas nuevos accesos directos.


No funciona en 64 bits


La pega de esta DLL es que sólo funciona en versiones de 32 bits de Windows. Si estás utilizando una versión de 64 bits no te servirá de nada. Por suerte un programador ¿ruso? llamado Serge Baranov, ha desarrollado una versión de esta utilidad que funciona en 64 bits, y que es la alternativa que tienes en este caso. La puedes descargar desde la página de AMIP Tools.


Espero que te resulte de utilidad.


Actualización 23/1/2010 (el original es de Abril de 2008):


He descubierto un programa mejor, con más opciones, y que funciona para todas las versiones de Windows, incluso en 64 bits. Se llama Desktop Restore y lo ha escrito Jamie O’Connel. Descárgalo desde aquí.

Como obtener los roles a los que pertenece un usuario: revisited

Hace ya un montón de tiempo (en septiembre de 2004), escribí un post, creo que interesante, sobre cómo obtener los roles a los que pertenecía un usuario de Windows.


El caso es que entonces la única manera de conseguirlo era mediante reflexión saltarse las normas de acceso a miembros para llamar a un método interno de la clase WindowsIdentity que devolvía esa información. El caso es que desde entonces no lo había vuelto a revisar (ni falta que me hizo), pero hoy uno de los alumnos de nuestro curso 70-536 de fundamentos de desarrollo en .NET para certificación, me ha hecho notar que en -NEt 2.0 y superiores ya no funciona, y además me ha sugerido la forma de hacerlo con las nuevas versiones (muchas gracias Miguel Ángel, vero que el curso te está cundiendo mucho, jeje), que sería así:

        private static string[] ListaDeRolesNET2(WindowsIdentity wId)
        {
        List<string> roles = new List<string>();
        
        foreach (IdentityReference idGrupo in wId.Groups)
        roles.Add(idGrupo.Translate(typeof(NTAccount)).Value);
        
        return roles.ToArray();
        }

Ahora está plenamente soportado por la plataforma, ofreciéndose una colección Groups que permite obtener los roles/grupos a los que pertenece un usuario en el equipo local o en un Directorio Activo.


Muy interesante. Espero que os sirva.

Instalar el sistema de BackUp de XP o Windows 2003 Server en Vista

Sin paños calientes: el sistema de Backup que trae Vista no vale para nada. Bueno, sí, vale para usuarios domésticos que no quieren ni pueden complicarse la vida. Pero en entonos profesionales es otra cosa. Parece mentira que un Vista Enterprise o Ultimate no meta otro sistema diferente.


El caso es que el sistema que trae Vista es muy sencillo d eusar pero no te deja obtener un buen control sobre lo que archivas, excluye ciertos tipos de archivos y, si no tienes instalado el Service Pack 1, no te guarda archivos cifrados con EFS (Sistema de archivos Encriptado), algo que por ejemplo yo uso cantidad, y muchos profesionales que manejan datos confidenciales (abogados, médicos, etc…) también.


La ayuda del sistema dice en concreto lo que pone la imagen del lateral.


Total, que lo que he hecho es instalar en mi Vista una copia del programa de Backup de toda la vida que venía con Windows 2000 y superiores. NtBackup.exe, vamos.


Para conseguirlo debes buscar tres archivos en la carpeta C:WindowsSystem32 oo equivalente en tu XP o Windows Server 2003, en concreto:



Ntbackup.exe
Ntmsapi.dll
Vssapi.dll


Copialos a tu sistema Vista en cualquier carpeta y añade un acceso directo al EXE en tu menú de inicio.


Además hay que asegurarse de que tenemos activado el servicio «Removable Storage Management» (en castellano debe de ser «gestión de almacenamiento extraible», pero no lo tengo en castellano a mano para comprobarlo). Para ello te vas a Panel de Control·Programas·Activar desactivar componentes de Windows, y lo activas en la lista que te aparece. Es necesario hacerlo para usar cintas y otros medios extraibles, y además si no lo activas te dará una advertencia cuando arranques NTBackup.


Con esto estará listo y podrás hacer copias mejores desde Vista.


Otro detalle: Si no instalas el programa en C:WindowsSystem32, cuando programes una tarea de backup periódica te fallará. El motivo es que el programa mete la tarea programada partiendo de la base de que está en la carpeta de sistema, y tendrías que cambiar la ruta a mano. Un fallo tonto de los programadores, que no les costaba nada usar la carpeta en la que se encuentre el ejecutable.

Windows Vista: el único sistema operativo viable para las grandes empresas, según Forrester

Esto va a ser polémico, como no… pero un informe que acaba de sacar (ayer) la prestigiosa empresa de investigación Forrester Research concluye que Vista es el único S.O. viable para implantar en grandes empresas, y que todas deberían ir migrando hacia él pronto, dejando de lado a Mac y a Linux.


El inform se titula «Building The Business Case For Windows Vista, Five Reasons To Start Your Company’s Migration Soon» estudia las formas de implantar los distintos SO en las empresas, sus pros, sus contras, etc.. y lega a la conclusión de que, por muchas razones, las grandes empresas deben migrar hacia Vista cuanto antes. Por ejemplo, dicen cosas ta directas como esta:



«Para grandes emrpesas no hay otra opción viable»


Dicen que con el SP1 de Vista las migraciones están empezando a acelerarse. Con respecto a Mac y Linux dicen:



«Estos SO han encontrado su nicho en ciertas industrias Por ejemplo Apple en marketing e investigación científica así como en el sector sanitario y retail. Novel (Suse), Red Hat y Ubuntu se usan mucho en servicios financieros y agencias gubernamentales. Pero cambiar miles de usuarios de golpe de Windows a uno de estas plataformas es simple y llanamente inviable.»


No se meten en cuestiones de características, si es bonito o menos bonito, etc, sino en cuál es más viable tener instalado y funcionando en entornos grandes, donde una configuración o migración «de uno en uno» no es una opción.


Este siempre ha sido uno de los grandes problemas de Linux y otras aplicaciones Open Source, como Firefox u Open Office: no se trata de que sean mejores o peores (yo soy un enamorado de FireFox, uso algo Ubuntu Linux, y me horroriza Open Office), sino de sí ofrecen el nivel de gestión y operaciones que una empresa mediana/grande necesita.


Desde mi punto de vista eso es en lo que más deben trabajar, antes que en cualquier otra cosa.

El problema de los valores por defecto en listas desplegables de ASP.NET

Se trata este de un truco sencillo, pero aún así interesante ya que mucha gente tarda en darse cuenta de cómo solucionarlo.


El problema surge cuando usas un control DataSource del tipo que sea (ObjectDataSource, SqlDataSource, LinqDataSource, etc…) y lo enlazas con un DropDownList para mostrar una lista de valores para elegir, por ejemplo, la categoría de productos a mostrar en otro control GridView. El origen de datos te devuelve sólo los diferentes valores de categorías disponibles en la base de datos, pero lo habitual es que además de una categoría (o lo que sea) concreta, desees dar una opción o dos por defecto, por ejemplo «Ver todas» y «Ninguna». Pero claro el control de origen de datos no tiene esas categorías inexistentes contempladas, así que ¿cómo haces?


Pues muy fácil, pero hay que saber un truquillo: la propiedad AppendDataBoundItems del control DropDownList.


Si la estableces a True lo que consigues es que cualquier elemento que coloques en lalista en tiempo de diseño se conserve (en los primeros lugares además) aunque le añadas dinámicamente otros en tiempo de ejecución con el control de origen de datos. Así, basta con que añadas un par de elementos como los del ejemplo, según tus necesidades, para tener disponibles más opciones adicionales en la lista desplegable.


Sencillo pero útil 🙂

Bug en el control RangeValidator con los idiomas Búlgaro y Eslovaco

Bueno, esto es de estas cosas que crees que a ti no te van a pasar pero luego resulta que sí, que te pasan 🙂


Y es que un cliente nuestro ha encontrado la aguja en el pajar. Una aplicación que teníamos producía un error inexplicable en un par de clientes de este cliente, y no sabíamos de qué era. Viendo el registro de errores pudimos llegar a dar con el problema.


Resulta que cuando el idioma del navegador del usuario es Búlgaro (bgt-BG) o Eslovaco (sk-SK) y tienes el cambio automático de cultura activado, el control RangeValidator puede romper si estás validando fechas. Sí, es que la aplicación que habíamos hecho está internacionalizada y nuestro cliente tiene clientes en todas partes de europa, así que…


Al producirse el error la página incluso deja de cargar, ya que rompe durante la asignación de los valores máximo y mínimo si éstos se establecen mediante código (como es normal cuando se trata de fechas).


El problema es que en estos países el formato de fechas es raro de narices (algo así, «11. 4. 2008 r.», fíjate enlos espacios tras los puntos) y el validador se vuelve loc y no es capaz de interpretarlas. Sin embargo la clase DateTime con su método Parse sí que es capaz por lo que hace sospechar del modo en el que está implementado el validador 🙁


Lo curioso del tema es que este error estaba ya controlado por Microsoft en ASP.NET 1.1 (http://support.microsoft.com/kb/937096/en-us), pero por lo que se ve no se solucionó del todo en las otras versiones. Ahora funciona con el húngaro pero no con el búlgaro ni el esloveno.


La única forma que he encontrado a bote pronto para solucionarlo es asignar las fechas en la carga a las propiedades de rango usando el formato habitual en castellano (dd/mm/aaaa), que es reconiocido sin problemas aunque el local sea uno de los conflictivos.


Ya he notificado el bug a Microsoft, así que a ver si lo solucionan definitivamente para un próximo Service Pack o para un parche específico.


ACTUALIZACIÓN (7-Mayo-2008):


Hoy me han escrito desde el equipo de desarrollo de ASP.NET para decirme que ya tienen el bug corregido y que será incluido en el Service Pack 1 de .NET Framework 3.5 (que incluye también a .NET 2.0).

Controles GridView que rompen con el nuevo Service Pack 1 para .NET 2.0 y .NET 3.5, y nueva propiedad de campos enlazados

Recientemente instalé el nuevo Service Pack 1 para .NET 2.0 (y .NET 3.5) en un servidor de producción. De repente la aplicación empezó a producir resultados inexplicables en unas rejillas de la aplicación de un cliente. De hecho desaparecían multitud de registros de éstas, aunque las consultas de las que dependían se seguían realizando sin problemas. Era un problema bastante raro y pensamos en un bug del SP1.


El caso es que fué una combinación de un error nuestro y un cambio de comportamiento en el SP1 de .NET 2.0. Lo explico porque puede interesarle a bastante gente.


De hecho este problema tiene mucho que ver con otro que ya ocmenté en este blog hace unos meses sobre el formato de fechas en los campos enlazados de una rejilla. En ese post además mostraba el código fuente de .NET que involucraba a este problema.


En el SP1 han cambiado ligeramente el comportamiento del enlazado a datos de campos DataBound en rejillas.


El caso es que el programador de nuestra aplicaicón había puesto en la rejilla un formato erróneo en dos campos almacenados como cadenas en la BD, colocando esto en la propiedad DataFormatString:



«{0:d}»


Esto es un formato no válido para un dato de tipo String, que es lo que se guarda en la base de datos. El formato “D” usado aquí es sólo aplicable a Enteros (lo pone bien claro la documentación de .NET), y el correcto sería por ejemplo “F”. Por lo tanto el problema se solucionaba cambiando la cadena de formato de la rejilla a, por ejemplo:



«{0:F2}»


De este modo se formatea como un número decimal en coma flotante con dos decimales, que es lo que nos interesaba.


En la versión anterior previa al SP1, de hecho no se estaba aplicando el formato en absoluto y por eso no rompía (consulta el código del post relacionado que menciono arriba) ya que la propiedad HtmlEncode es true por defecto. En el SP1 han cambiado este código y ahora sí que se aplica antes del formato de cadena.


De hecho han introducido una propiedad nueva llamada HtmlEncodeFormatString que por defecto vale true y que nos ayuda a controlar este aspecto.


Espero que esto le pueda ayudar a más gente.


Saludos


JM.

Google App Engine: hosting de alta disponibilidad gratuito

Interesante noticia la aparecida hoy en los medios americanos respecto a este anuncio del gigante de los buscadores. Se trata de App Engine (ver el motor del grafiquito adjunto, se han roto la cabeza con el logo), un nuevo servicio a través del cual Google ofrece a los desarrolladores su infraestructura de red y de servidores para albergar aplicaciones Web. Y lo mejor es que es completamente gratuita.


De momento se lo darán sólo a los 10.000 primeros que lo soliciten. También tendrá algunas limitaciones, pero vamos, que si mi aplicación Web las alcanzara creo que me daría exactamente igual pagarles un pasta por dejarlo ahí: 10 GB de transferencia diaria, y 500 MB de almacenamiento (esto último es quizá un poco escueto si quieres guardar contenidos). Con esa transferencia se estima que podrías servir alrededor de 5 millones de páginas vistas diarias. Ahí es nada. A partir de ese lïmite empezarán a cobrar.


Podrás utilizar BigTable, el sistema de almacenamiento distribuido de Google (usado por ejemplo por Google Maps), y su sistema de archivos propietario GFS. Con ello obtienes también el uso de la infraestructura de red y de servidores redundantes propia de Google (la más grande del mundo).


El único problemilla es que, de momento, sólo se permiten aplicaciones escritas en Phyton. Y desde luego dudo que nunca se vea soporte para .NET, pero cualquiera sabe. 🙁


Microsoft: toma nota y danos algo similar a los desarrolladores Web de .NET 🙂

Creative amenaza a un programador por desarrollar drivers mejores a los de ellos

Esto lo he leído hoy en Engadget y he flipado bastante. Reproduzco:



«Muchos usuarios han tenido problemas usando las tarjetas de sonido de Creative en Vista, y un habilidoso programador, Daniel Kawakami, se las arregló para escribir sus propios drivers. Resulta que el software proporcionado por Daniel es aún mejor que el del fabricante, y por eso sus programas llegaron a hacerse muy populares.


El problema empieza cuando Daniel pide donaciones para poder dedicarle más tiempo a la programación, y Creative no toma las cosas bien, por lo que procede a amenazarlo públicamente en los foros.


La respuesta de Daniel es simple y clara: no producirá más controladores, pero se siente molesto porque dice que Creative simplemente podía haberle enviado un email. A nosotros nos parece que Creative debería invertir más tiempo contratando a Daniel para que haga lo que ellos no pueden, y menos tiempo amenazándolo.»


Yo me pregunto: ¿realmente Creative no es capaz de hacer drivers mejores? ¿No tiene dinero para fichar a Daniel? o, como bien sugiere un lector en el post original, ¿no será que directamente no les interesa crear buenos drivers para sistemas nuevos de modo que tengas que actualizar el hardware y así su negocio vaya mejor, y por eso le dan caña al bueno de Daniel?.


A mi por ejemplo me pasó con una webcam Logitech carísima que me compré. A los pocos meses salió Vista y esta gente no ha sacado drivers. pasaron los meses y siguen sin sacar drivers y por lo visto no tienen intención de hacerlo tampoco. Resultado: me gasté un pastón (era de las cámaras más caras en el momento), la usé tres o cuatro meses y al final para poder tener webcam en Vista tuve que comrparme otra nueva (por supuesto no Logitech, claro).


En fin…