En mi github tengo implementado el Eliza en version hablada.

https://github.com/4nimanegra/TalkToMe

Usa la API de speech de google. Transformo lo que me hablan en texto que lo meto en el eliza que después el texto que saca lo lee. La interaccion es completamente con microfono y altavoz de movil.

No se si te servirá. Usa Cordova y los plugins:
cordova-plugin-tts
cordova-plugin-speechrecognition

Es una prueba de concepto programada en media hora por lo que no esperes ni interfaz, ni gaitas. Era para probar si podía hacer programas rápidos usando voz y altavoz. Es pantalla blanca y el elemento que escucha y habla. Le tendrás que dar los permisos que toque. Tienes el apk y los sources que son javascript.

Hay otro programa que lee lo que sale cuando sacas una foto, ahi se usa el ocr y el text to speech.

https://github.com/4nimanegra/leeme

misma historia, prueba de concepto muy rapida para probar. Pero tienes el código de ejemplo muy simple que funciona.

Saludos.

Se pueden hacer exploits en casi cualquier lenguaje. El requisito probablemente más indispensable es que puedas sacar datos por pantalla y eso lo permiten todos. Por ejemplo, en javascript podrías generar un exploit y ejecutarlo via phantomjs para utilzarlo via terminal como entrada de pantalla para un pograma específico.
O hacer un html estatico y un codigo javascript para automatizar la explotación de un sqlinjection para atacar un sistema (o sistemas) web. Según las paticularidades del lenguaje hay algunos que son más propicios que otros.

Hay un método mas laxo que no requiere hacer un storing de todas sesiones y realizar un destroy de las sesiones. Puedes utilizar un timestamp. En la sesion guardas que hora es cuando hace login y en la base de datos poner en la base de datos almacenas que hora es cuando cambie la password (poniendo solo en los datos de esa sesion el timestamp).
Si alguien entra, existe sesion y es mas vieja que el timestamp pues le quitas la información de la sesion y que tenga que volver a hacer login. No se si se entiende.

En mi caso, cambia cada vez, no devuelve algo consistente. Habría que mirar si en media...
Saludos

Puedes optar como te decía a replicar el cifrado de la contraseña mediante la pass del usuario y tu password. La creación de usuarios pasaría por la aceptación por tu parte de la cuenta de usuario momento en el que generas una pass aleatorioa para el usuario y una simetrica cifrada con la pass aleatorioa y la tuya. Cuando el usuario entra cambia la password y se vuelve a cifrar la simetrica con la nueva pass del usuario. Con lo que cada usuario podría acceder a sus datos y tu a los de todos (como Dios ^^).
Eso tiene el problema de que tienes que hacer tu los usuarios o exigir al usuario a que espere el check tuyo y que si te roban tu pass maestra tienen acceso a todo, como tu. Pero así ninguna password ni dato se almacena físicamente en limpio en el servidor.

Pero el usuario introduce ell pass en limpio que es cuando la necesitas descifrar para acceder a la passphrase de cifrado simétrico que cifra la info del usuario y cuando se almacena en memoria para descifrar. El resto del tiempo esta cifrada con esa contraseña que sólo está en la cabeza del usuario y en forma de hash en tu base de datos.

El atacante que entre no podrá mas que acceder a las contraseñas en uso si hace el volcado de memoria. No al resto que estan cifradas con la password de cada usuario.


+ 10000 puntos de carisma a lo que comenta engel. Tu pasas la información cifrada al cliente y que él la descifre. Si no tienes la información descifrada en el lado del servidor aunque hackeen el servidor no pueden acceder a la información.


En realidad menos. porque si a un cliente le hackean es su culpa no tuya. Y si hackean al cliente, tengas tu la informacion descifrada o sólo la cifrada van a poder acceder a dicha información. Solo que en el caso que describe engel si te hackean sólo a ti no acceden a ninguna información.

Bueno, se podría utilizar un nivel más. Aunque no sirve de demasiado, se podría requerir de que alguien metiese la password cada vez que se reinicia el servidor, de manera que en lugar de almacenarse en fichero la password simétrica se almacene en memoria.
No obstante fijarse que el atacante no tendría más que generar un archivo php que obtuviese la variable en memoria y la mostrase en pantalla.

No obstante, igual lo suyo es almacenar las passwords simétricas de cifrado de cada cliente, cifradas con su password. La password de cifrado esta almacenada de forma cifrada, y solo se descifra con la password en limpio del cliente. Que no se almacena en el servidor porque el cliente te la teclea cada vez que quiere acceder y con eso descifras la clave simétrica que permite descifrar los datos de cada cliente.

Aunque esto tiene sus problemas, si un cliente pierde su password, toda su información se pierde. Igual tendrías que hacer otra copia cifrada con una llave maestra que sea la password del admin. Aunque entonces el admin podría acceder a los datos en limpio del cliente. Todo tiene sus problemas y eso implicaría un único punto de fallo.

Por otro lado, nada impide a un atacante que accede fisicamente con suficientes privilegios acceder a la información de al menos aquellos usuarios que esten utilizando en ese momento el sistema.

una de las primeras cosas que igual debes hacer en un algoritmo de cifrado para evitar esquemas de criptoanálisis es utilizar el efecto avalancha. Introducir una entrada más en cada carácter a cifrar y combinarlo con la salida anterior. El primer carácter cifrado se puede dejar sin tener entrada adicional. de manera que si cifras usando una clave con los mismos caracteres el texto codificado saldrá diferente porque la nueva salida no dependerá sólo del mensaje y la clave, si no del carácter obtenido como texto cifrado del anterior.
No se si se entiende.

Por otro lado, también deberías utilizar bloques mas grandes, que tu algoritmo utilice cosas de las que no se pueda terminar obteniendo un diccionario.
Igual estaría bien leer un poco sobre redes de feistel, muy sencillas y potentes para hacer algoritmos de cifrado simétrico.
Si quieres hacer cosas de criptografía, personalmente te recomiendo el Lucena (http://www.grc.upv.es/biblioteca/cripto.pdf) si no tienes mucha fluidez en inglés, o el schneier (https://www.abebooks.com/servlet/BookDetailsPL?bi=30425390127&searchurl=kn%3Dapplied%2Bcryptography%2Bschneier%26sortby%3D17&cm_sp=snippet-_-srp1-_-title2) si no te importa leer texto en inglés (y comprarlo).

Pero eso es DHCP y está inhabilitado te está diciendo.Si no he entendido mal, está comentando que él/ella ha ingresado en una red WPA pero no tiene ni idea del direccionamiento interno y como el DHCP esta inhabilitado no puede componer un paquete ARP con ceros para que le de puerta de enlace e IP. Y además al ser WPA, no puede esnifar trafico de otros ordenadores para intentar obtener el direccionamiento de forma pasiva.
O a lo mejor no he entendido bien.

Yo creo que el auge de los teclado mecánicos es un poco moda. Uno de membrana con teclas finas requiere de mucha menos presión y probablemente sea más agradable y te canse mucho menos, al final haces menos presión.
Por tema económico, cuando te falla un poco lo tiras y compras otro, por la diferencia de precios parece que podría ser un punto a favor de los membrana.
Por otro lado, los mecánicos probablemente duren más, seguramente sea mucho más ecológico tener un teclado durante mas tiempo que 3 o 4 durante menos.
No obstante, esto es como los zapatos, intenta optar por un teclado que se adapte a ti. A lo mejor eres mas de teclas gruesos o finas o teclados mas anchos o menos anchos.
Por tema de retraso que hablas por piezas que son algo firmes, probablemente lo notes más en teclados mecánicos que en los de membrana.