Teorizando sobre las contraseñas de protección

hola, Javi !

1. Si el metodo para echar abajo una contrase#a de libro es estrablecerla a ""
usease: ActiveWorkbook.Protect "" con sus respectivas combinaciones de true y false
no bastaria con reestablecer la contrase#a al iniciar el workbook_open?.

(Por cierto, para establecer la contrase#a al libro mediante codigo, le he puesto
ActiveWorkbook.Protect "Contrase#a", True, True ; pero me da error 91
Variable de objeto o bloque With no establecido).

2. Como se puede anular el acceso, no al proyecto, sino en la propia barra de herramientas, al Editor de Visual Basic?
y tambien inhabilitar el acceso mediante teclado con Alt+F11. es Application.Onkey... ?

3. ... no llego a entender como se puede abrir desde el "exterior" el codigo de un excel.
En html, por ej., hay un codigo para que la gente no pueda por medio de frames, encajar tu pagina dentro de su pagina web.
Y entiendo que deberia haber alguna forma para bloquear ese acceso no autorizado, aparte de la contrase#a.

los siguientes comentarios son [solo] hasta donde se... :D

1) establecer la clave de un libro y hoja en una cadena vacia -> "" NO 'funciona' si el libro es abierto en la version 2002 en adelante :-(
[aunque] si lo creaste con la version 2002/2003... SI 'funconara' si se abre con la version 2000 o '97 ;)

2) NO 'basta' con 'reponer' la clave en el '_open' del libro [ademas de que es lo mismo a que YA la tiene establecida al abrirlo]...
la 'desproteccion' [por lo general] la hacen DESPUES de abierto :-((
o sea, tendrias que estarla 'monitoreando' con algun evento 'OnTime' [con sus consabidas contra-indicaciones] ;)

3) el 'problema' con el error 91, es probable que no lo este provocando la linea que expones -?-
[generalmente] tiene que ver con variables de objeto NO establecidas o instrucciones With...End With 'mezcladas' con GoTo -?-
o... librerias 'perdidas' o corruptas en [menu] herramientas / referencias... -> en el editor de vba -?-

4) para 'anular' el acceso al proyecto de macros por menus y/o botones de comandos [en alguna barra de menus y herramientas]...
[menus y herramientas] -> haz un bucle que 'busque' e inhabilite un control de boton con la ID 1695
[por atajos de teclado] -> efectivamente, puedes inhabilitar la combinacion de teclado {Alt}+{F11} con un Application.OnKey ;)
SOLO... no pierdas de vista que se puede lograr el acceso al editor de vba [p.e.]...
-> click-secundario sobre la etiqueta de una hoja y seleccionando la opcion de: -> ver codigo [aparte de 'algunas' mas opciones] :D

5) considerando que los lenguajes para HTML y VBA NO son 'lo mismo'... y en tanto NO sea excel una aplicacion 'activa'...
-> no veo forma de que se pueda 'abrir desde el exterior' un codigo de su proyecto de macros :-(

si cualquier duda [o informacion adicional]... comentas ?
saludos,
hector.

Conozco de una herramienta llamada "offkey", que revienta el password y
accedes con la nueva contraseña que él te da. Por ello, decía lo del _open,
para que al acceder al excel, se reestableciese la original. Lo que no sabía
es que ese proceso de "crackeo" se pudiese hacer también con el excel ya
abierto, con lo cual mi idea del _open se va al traste, como bien dices.

Tengo un evento on-time para monitorizar eventos cada 10 segundos (cómo
venía en la web que me recomendasteis), pero supongo que es un intervalo
suficientemente amplio para que puedan acceder. Cuales son esas sabidas
contraindicaciones?

Respecto a lo de abrir desde el "exterior" un código excel, me referia a
los comentarios leidos al respecto de que desde un módulo ajeno al proyecto,
se podia echar abajo la contraseña, asi como los eventos.

Como sería exactamente la línea de código para anular lo del Alt + F11?
Application.OnKey "???", ""

Y por último, aparte de la combinación de teclas Alt + F11, por medio
del menu, y el click-secundario sobre la etiqueta de hoja que mencionas; qué
métodos hay para acceder al editor?, o para ser más concreto, se pueden
bloquear/eludir todos esos tipos de accesos?


Muchas gracias por todas las molestias que te estás tomando.
Javi

hola, Javi !

-> te aseguro que NO es mi intencion parecer un 'aguafiestas' :))
[sin embargo]... considerando otros comentarios ya expuestos en consultar anteriores similares a este hilo...

1) partiendo de que [en excel] la seguridad 'parece' NO ser [hasta ahora] una prioridad ->que limite<-... solo 'nos queda'...
seguir buscando formas 'alternas' o desarrollar nuestras 'propias aplicaciones'
-> en lenguajes 'primarios' de programacion [como 'C', VB-Stand-alone, Delphi, etc.] :))
-> 'reza' un dicho: 'para uno que madruga... otro que no duerme' <= es decir, que siempre habra 'alguien' ...
[para mal]... tratando de 'tomar prestada' la tecnologia de los demas :((
[para bien]... 'tratando' de 'hacerles la labor' -cada vez mas- 'dificil' :))

2) [yo creo que] cuando hablamos de algun 'sistema de proteccion' [y MAS si 'pretendes' que sea... 'infalible' ?]...
[ya iras 'viendo' que...] se encuentran mas 'imponderables' que los intentos de 'prevenirlos' :(

3) [como esta comentado en el articulo]...

Toma en consideracion que una de las tareas más "quema-neuronas" en cuestiones de programacion es:
"Anticipar" (en la medida de lo posible) las acciones del usuario para poder...
"Evaluar" las consecuencias de ejecutar un codigo y finalmente...
"Dise#ar" prevenciones o correcciones de errores "involuntarios" (o premeditados?).

4) algunos 'ejemplos' de -posibles- 'imponderables' que pudieras encontrar en el camino [solo 'enunciativamente']...
[p.e.] puedes inhabilitar el atajo {Alt}+{F11} si pones en el evento '_open' de tu libro la siguiente instruccion...
-> Application.OnKey "%{F11}", ""
PERO... piensa que tendrias que hacer para evitar/prevenir/corregir/... [p.e.] las siguientes eventualidades...
- que el editor de vba YA se encuentre 'visible' [ANTES Y] al momento de abrirse 'tu' libro :-((
- que el 'usuario' tenga habilitados 'ciertos' procedimientos [p.e.] asignados a teclado y/o botones/objetos/... :-(
- tengo en mente varias eventualidades mas :D PERO... considera las que NO se me han ocurrido [a mi] :))

5) [definitivamente]... es 'imperante' que estes en condiciones de ANTICIPAR lo que se le pueda 'ocurrir' al usuario :))
debes considerar el nivel de conocimientos [y la disponibilidad de recursos] de a quienes esta dirigida tu aplicacion ;)
[ademas] siendo excel/vba una herramienta sumamente [en ocasiones, demasiado ?]... 'amigable'
-> 'tendrias que'... considerar mas 'seriamente' las alternativas del punto 1 [lenguaje 'C', VisualBasic -stand-alone-, Delphi, etc.]

comentas [si hubiera] algun detalle 'en el tintero' ? [p.e. 'que es' lo que realmente necesitas lograr] ;)
saludos,
hector.
=> ... "offkey"... revienta el password y accedes con la nueva contrase#a

... no sabia... que ese... "crackeo" se pudiese hacer tambien con el excel ya abierto
... mi idea del _open se va al traste, como bien dices.
... evento on-time para monitorizar eventos cada 10 segundos (como venía en la web que me recomendasteis)
... supongo que es un intervalo suficientemente amplio para que puedan acceder.
Cuales son esas sabidas contraindicaciones?
... lo de abrir desde el "exterior" un codigo excel, me referia a los comentarios leidos al respecto
... que desde un modulo ajeno al proyecto, se podia echar abajo la contrase#a, asi como los eventos.
Como sería exactamente la línea de código para anular lo del Alt + F11?
Application.OnKey "???", ""
... aparte de la combinación de teclas Alt + F11, por medio del menu, y el click-secundario sobre la etiqueta de hoja
... que metodos hay para acceder al editor?, o para ser mas concreto, se pueden bloquear/eludir todos esos tipos de accesos?