Numero de serie del disco

"HighSoft" wrote in message
news:

Funcionó perfectamente!!!
Te explico un poco que es lo que estoy tratando de hacer, porque me surge
un nuevo problema.
Quiero proteger contra copia un servicio web que intento comercializar.
Debería funcionar así:

Fase de habilitacion
1. El usuario instala el servicio.
2. Usando una aplicación Windows el usuario obtiene y me proporciona el
numero de serie de su disco duro, y me solicita una clave.
3. Yo genero esta clave con este numero de serie del disco y se la dicto
para que la introduzca
4. La clave queda escrita en un archivo del disco duro del usuario

Fase de uso
Cuando el servicio web está en uso hace lo siguiente:
1. Accede al archivo y lee la clave (paso 4 de la fase de habilitación)
2. Obtiene el numero de serie de disco duro
3. Genera la clave con este numero utilizando el mismo algoritmo del paso
3 de la anterior fase
4. Comprueba si ambas claves son iguales
5. Si son iguales el servicio corre normalmente sino no.

Ahora mi problema es:
En que momento se debe introducir el userName y el password? De qué
manera?

Mi opinión es que te sobra la comprobación del numero del disco en la
fase de uso. Me explico: Si en la fase de habilitación, en el paso 4, ya has
dejado escrita una clave en el disco, entonces durante la fase de uso basta
con comprobar si esa clave existe en el disco del usuario. Para que no sea
fácil de copiar, ponla en algún sitio que no sea muy evidente. Cierto que a
pesar de eso, podrían encontrarla y copiarla, pero puestos a copiar datos
que están en algún sitio extraño del disco, también podrían copiar el propio
número de serie del disco, que es bastante sencillo de cambiar.

Si a pesar de eso quieres continuar con el método de proporcionarle al
servicio web un usuario y password con privilegios para acceder al número de
serie del disco, puedes preguntarlo en la fase de habilitación, y que sea el
programa Windows el que los grabe en el sitio adecuado. Pero no te
recomiendo que los metas en el "identity impersonate". Eso solo era para
hacer una prueba rápida, a ver si efectivamente se trataba de un problema de
permisos. Pero, por motivos de seguridad, no es nada recomendable dejar en
producción una aplicación asp.net que se ejecute con la identidad de un
usuario privilegiado.

Tenia entendido que el numero de serie del disco duro no se podia cambiar,
de ahi que pense que era mas seguro hacerlo asi.
De todas maneras si lo hago asi, siguiendo tu propuesta, seria la aplicacion
windows quien guarde el usuario y password (tal vez en el mismo archivo de
la clave)
Cómo hago para que el servicio web tome estos datos y pueda leer el numero
de serie del disco (como dices, evitando ponerlos en el "identity
impersonate").


"Alberto Poblacion"
escribió en el mensaje news:%

"HighSoft" wrote in message
news:

Funcionó perfectamente!!!
Te explico un poco que es lo que estoy tratando de hacer, porque me surge
un nuevo problema.
Quiero proteger contra copia un servicio web que intento comercializar.
Debería funcionar así:

Fase de habilitacion
1. El usuario instala el servicio.
2. Usando una aplicación Windows el usuario obtiene y me proporciona el
numero de serie de su disco duro, y me solicita una clave.
3. Yo genero esta clave con este numero de serie del disco y se la dicto
para que la introduzca
4. La clave queda escrita en un archivo del disco duro del usuario

Fase de uso
Cuando el servicio web está en uso hace lo siguiente:
1. Accede al archivo y lee la clave (paso 4 de la fase de habilitación)
2. Obtiene el numero de serie de disco duro
3. Genera la clave con este numero utilizando el mismo algoritmo del paso
3 de la anterior fase
4. Comprueba si ambas claves son iguales
5. Si son iguales el servicio corre normalmente sino no.

Ahora mi problema es:
En que momento se debe introducir el userName y el password? De qué
manera?

Mi opinión es que te sobra la comprobación del numero del disco en la
fase de uso. Me explico: Si en la fase de habilitación, en el paso 4, ya
has dejado escrita una clave en el disco, entonces durante la fase de uso
basta con comprobar si esa clave existe en el disco del usuario. Para que
no sea fácil de copiar, ponla en algún sitio que no sea muy evidente.
Cierto que a pesar de eso, podrían encontrarla y copiarla, pero puestos a
copiar datos que están en algún sitio extraño del disco, también podrían
copiar el propio número de serie del disco, que es bastante sencillo de
cambiar.

Si a pesar de eso quieres continuar con el método de proporcionarle al
servicio web un usuario y password con privilegios para acceder al número
de serie del disco, puedes preguntarlo en la fase de habilitación, y que
sea el programa Windows el que los grabe en el sitio adecuado. Pero no te
recomiendo que los metas en el "identity impersonate". Eso solo era para
hacer una prueba rápida, a ver si efectivamente se trataba de un problema
de permisos. Pero, por motivos de seguridad, no es nada recomendable dejar
en producción una aplicación asp.net que se ejecute con la identidad de un
usuario privilegiado.

Tenia entendido que el numero de serie del disco duro no se podia
cambiar, de ahi que pense que era mas seguro hacerlo asi.

El numero de serie del disco no puede cambiarse. Alberto se confundio con el
numero de serie de volumen que si se puede cambiar.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> wrote in message
news:

Tenia entendido que el numero de serie del disco duro no se podia
cambiar, de ahi que pense que era mas seguro hacerlo asi.

El numero de serie del disco no puede cambiarse. Alberto se confundio con
el numero de serie de volumen que si se puede cambiar.

Efectivamente, tienes toda la razón, estaba pensando en el
Volume_Serial_number.

En cuanto a la pregunta de HighSoft:

Cómo hago para que el servicio web tome estos datos y pueda leer el
numero de serie del disco (como dices, evitando ponerlos en el "identity
impersonate").

Al principio estaba pensando en que podrías pasar las credenciales del
usuario directamente al WMI, pero he estado mirando la documentación y dice
que esto solo funciona contra una máquina remota, pero que si lo intentas
hacer sobre la máquina local da un error:
http://msdn.microsoft.com/library/d...server.asp
Asi que este método no va a valer.

Es posible impersonar a un usuario por código:
http://msdn.microsoft.com/library/d...erting.asp
http://msdn.microsoft.com/library/d...etopic.asp

Pero como verás en los artículos anteriores, tiene una cierta
complejidad, y si no quieres meterte en esos lios, igual al final prefieres
dejar las credenciales de usuario metidas en el identity impersonate del
web.config, aunque sea a costa de perder algo de seguridad.

Tienes razon es bastante complejo. Lo que voy a hacer es utilizar el
impersonate en el web.config.
Ya que este archivo es texto puedo modificarlo con la aplicacion windows e
introducirle el usaurio y el password.

Muchas gracias por tu atención

"Alberto Poblacion"
escribió en el mensaje news:%

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> wrote in
message news:

Tenia entendido que el numero de serie del disco duro no se podia
cambiar, de ahi que pense que era mas seguro hacerlo asi.

El numero de serie del disco no puede cambiarse. Alberto se confundio con
el numero de serie de volumen que si se puede cambiar.

Efectivamente, tienes toda la razón, estaba pensando en el
Volume_Serial_number.

En cuanto a la pregunta de HighSoft:

Cómo hago para que el servicio web tome estos datos y pueda leer el
numero de serie del disco (como dices, evitando ponerlos en el "identity
impersonate").

Al principio estaba pensando en que podrías pasar las credenciales del
usuario directamente al WMI, pero he estado mirando la documentación y
dice que esto solo funciona contra una máquina remota, pero que si lo
intentas hacer sobre la máquina local da un error:
http://msdn.microsoft.com/library/d...server.asp
Asi que este método no va a valer.

Es posible impersonar a un usuario por código:

http://msdn.microsoft.com/library/d...erting.asp

http://msdn.microsoft.com/library/d...etopic.asp

Pero como verás en los artículos anteriores, tiene una cierta
complejidad, y si no quieres meterte en esos lios, igual al final
prefieres dejar las credenciales de usuario metidas en el identity
impersonate del web.config, aunque sea a costa de perder algo de
seguridad.