AppleScript - eco en el cifrado AES de openssl - ¿hay alguna manera de descifrar/fisgonear a través de los registros?

No sé si esta pregunta es mejor aquí o en el mundo de Linux... pero necesito una respuesta decente... :)

Estoy usando Applescript para extraer datos de los campos en una hoja de cálculo o base de datos, los inserto directamente en la terminal para el cifrado.

Mi Applescript incluye una línea como:

echo "thisismydatastring and my saltbits"  | openssl aes-256-cbc -k thisismypassword -base64

Mi pregunta: ¿hay alguna manera de filtrar a través de los archivos de registro para capturar esta instancia de texto sin formato de la contraseña?

¿Hay una mejor manera de prevenir la piratería?

Si se puede rastrear el envío de un "eco" a la terminal, ¿hay otra forma de enviar algo a la Terminal donde no llegue a ningún registro (y donde AppleScript pueda obtener los resultados)?

Los registros son un problema, la protección contra cualquiera que se ejecute ps auxpara ver la línea de comandos es otro...
¿Posible problema XY?http://xyproblem.info/
sí, ps aux es exactamente una de mis preocupaciones. Sin embargo, he ejecutado esto tanto como usuario como root, y no he podido ver nada que realmente pasara a la terminal durante este proceso. ¿Cómo propondrías detectarlo con ps?
¿Cómo se podría probar o refutar si Applescript está ocultando acciones de los registros de bash? ¿Hay alguna manera de que Applescript pueda pasar un comando (digamos hash MD5 o comando openssl AES-265-cbc) sin que llegue al historial de bash?
ps lfelizmente mostrará cualquier línea de comando de los comandos que se están ejecutando actualmente, por lo que si un atacante lo ejecuta en un bucle o en el momento adecuado, puede leer su contraseña fácilmente. Y la línea de comando es parte de la tabla de procesos de acceso abierto, por lo que algunas líneas de código C también extraerán los datos.
Usted dijo: "Mi Applescript incluye una línea como:" y afirmo que necesita aclarar cómo está implementando echo "thisismydatastring and my salt bits" | openssl aes-256-cbc -k thisismypassword -base64porque si se hace en un tell application "Terminal" bloque usando el do script comando , se está escribiendo en .bash_history. do shell script Sin embargo, si se hace en el comando integrado de AppleScript , no se registra en ninguna parte porque el do shell script comando usa un no interactivo shell y HISTORYestá deshabilitado en un no interactivo shell . Continuado...
Puede usar, por ejemplo, set theResult to (do shell script "...")y la variable theResult contendrá la información para el procesamiento posterior que desee y lo hará sin ningún registro por el motivo indicado en mi primer comentario.
user3439894 - gracias... sí, ya usamos un comando "Establecer el resultado en (hacer script de shell...)", por lo que parecería (junto con el hecho de que las variables mueren al final del shell) que esto pasaría hasta sin historia. Parecería que la única preocupación adicional que tendría es si "ps l" podría husmear o no en el script a medida que avanza (incluso si es un shell no interactivo) ... Cualquier método para mostrar o espiar esto desde un nivel raíz? ¿Cómo puedo realmente replicar esto?

Respuestas (1)

Superé el problema de la contraseña en mis scripts de bash al obtener (incluido) otro archivo con una variable predeterminada ya configurada.

Por ejemplo. Digamos que tiene un archivo de "configuración" ~/config.confy en él asigna algunas variables:

# Config file for MyScript.sh

$user = Me
$pass = S3cr3t5!

En su secuencia de comandos, obtiene el archivo para que pueda usar las variables que definió:

#!/bin/bash

source /Path/to/config.conf

stuff= "thisismydatastring and my saltbits"

echo  $stuff | openssl aes-256-cbc -k $pass -base64

Personalmente, me gusta mantener la línea que ejecuta el comando lo más limpia posible usando variables (como stuffen el ejemplo anterior) para que sea más fácil ver lo que está haciendo el comando y, en consecuencia, más fácil de depurar.

¿Está a salvo de miradas indiscretas? Sí, en su mayor parte. Puede configurar los permisos para que solo el usuario pueda leer y escribir el archivo y negarlo a todos los demás:

chmod 600 config.conf

Cualquiera que husmee en los registros (que es su pregunta) no podrá ver las contraseñas de texto sin formato.

me parecería que una falla separada con el nombre y la contraseña en realidad sería un modelo menos seguro, ya que sería bastante trivial 'deshacer el borrado' de dicho archivo en un momento posterior, abrirlo y encontrar los datos... y la raíz generalmente puede eludir cualquier configuración de permisos....
No veo cómo sería menos seguro. Si su temor es que root pueda ver sus contraseñas, las verán independientemente de dónde intente almacenarlas (en el mismo archivo o en uno diferente) a menos que, por supuesto, pueda (si tiene los derechos para hacerlo) hacer que el archivo sea inmutable (tal como está). el caso en FreeBSD). Si su almacenamiento es un SSD, ya no es trivial inquietarse. Lo borras y desaparece.
Esta también es una práctica muy común en el desarrollo web donde las contraseñas para cosas como las bases de datos MySQL se almacenan en directorios fuera del sitio que no están disponibles para el demonio web pero obviamente están disponibles para cualquier persona con derechos (obviamente root)
Allan, las variables WRT en el entorno Mac *nix, ¿muere la variable en sí misma al final del comando, o es posible que alguien la llame nuevamente en un momento posterior?
Acabo de probarlo... muere. Según tengo entendido, para que sea "persistente" después de que se ejecute el script es para exportla variable.
AppleScript - eco en el cifrado AES de openssl - ¿hay alguna manera de descifrar/fisgonear a través de los registros?
RespuestasAquíPolítica de privacidad1y, 0v