elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Tutorial básico de Quickjs


  Mostrar Mensajes
Páginas: [1] 2 3
1  Seguridad Informática / Seguridad / mitigar ataque Ddos htaccess en: 7 Diciembre 2016, 16:00 pm
Hola,
Se que es un tema muy extenso y no basta con  htaccess para hacer frente a un ataque DDOS pero como dice el titulo intentar mitigar

Mi idea es la siguiente:
Poner una denegación en htaccess si una ip se conecta mas de un numero de veces en un lapso de tiempo.

Código
  1. Order Deny,Allow
  2. Deny from xxx.xxx.xxx.xxx
  3.  


En mi proyecto tengo todo redireccionado a mi index.php a traves de htaccess
Código
  1. RewriteCond %{REQUEST_FILENAME} !-f
  2. RewriteCond %{REQUEST_FILENAME} !-d
  3. RewriteRule ^(.*)$ /index.php?otras_variables=$1 [NC,L,QSA]
  4.  

Para index.php he encontrado una solucion con esta libreria:
https://github.com/damog/planetalinux/blob/master/www/principal/suscripcion/lib/antiflood.hack.php
Que hace exactamente lo que yo quería (si alguien se conecta mas de lo establecido,  le manda un aviso que esta bloqueado y no sigue con la ejecución de los scripts).
Este script ya puedo modificarlo de tal manera que en vez de aviso lo pongo en una lista negra por htacces.

Ahora el problema es con los imagenes porque si alguien pide directamente una imagen
ej: https://mi_sitio.com/carpeta_imagenes/mi_imagen.png
Por un lado es un recurso valido (osea he dado permisos para .png en mi htaccess)
Pero por otro lado, como esto no pasa por index.php, ya no sirve el conteo que tengo en index.php con la librería "antiflood.php" que puse arriba.

Se también que habrán otros recursos .js .css etc ... pero por lo menos si alguien puede darme alguna pista para los imágenes ... el resto supongo que lo podre hacer por analogía.

Saludos y gracias
2  Seguridad Informática / Criptografía / Re: Algoritmo inscripcion autenticacion en: 2 Diciembre 2016, 22:07 pm
Hola kub0x,

"Mas claro que el agua" !!!
Ahora ya he entendido bien todo.

Fue esta frase que me confundió:
Citar
- Genera un par de claves RSA en el lado del servidor. Esto ya contábamos con ello ¿por qué sino como cifra el usuario la simétrica AES sobre el mensaje aleatorio?

Por esto creí que quieres decir, que tengo que generar las claves del usuario en el servidor de donde deduje yo que luego tendría que mandárselo al usuario.
Ahora si me ha quedado claro que no es así.

Estas semanas intentare armarlo todo en local ya te contare que tal me ha ido.

Saludos y gracias por todo.
3  Seguridad Informática / Criptografía / Re: Algoritmo inscripcion autenticacion en: 30 Noviembre 2016, 14:50 pm
Muy buenas ,

Citar
La firma no es otro cifrado con AES, una firma creo que la vés como MAC, pero esto es una firma DIGITAL

Gracias por los detalles que me diste esto me aclaro todo.
Caso cerrado lo de la firma :D




Citar
El usuario hace sign-up por primera vez:

- Genera un par de claves RSA en el lado del servidor. Esto ya contábamos con ello ¿por qué sino como cifra el usuario la simétrica AES sobre el mensaje aleatorio?. La privada RSA es única (un mismo par para todo) y cifrála con el passphrase que desees en AES-256.
- El usuario computa una firma digital sobre su info y cifra dicha info con una clave AES aleatoria. El user cifra la clave aleatoria AES con la pública del server y envía todo lo especificado aquí al server.
- El server descifra la clave AES con su privada (la del server obvio), descifra el mensaje con la clave AES y verifica la firma digital. Si todo va bien, re-cifra la info del usuario, cifra la clave AES con la privada del server y guarda la info cifrada por AES y la clave AES cifrada por la privada RSA.

Ahora si entrán a tu server, verán que la info de todos los usuarios está cifrada, y también verán que hay una clave AES cifrada por la privada de tu server. Entonces pensarán, bueno sólo necesito descifrar la info por la key AES, vale vamos a buscar la private key del server. Digamos que la encuentran, pero no verán más que la privada tuya cifrada por AES.

La autenticación la hacemos como te dije, generas mensaje y clave AES aleatoria. Computas firma digital con la privada del usuario sobre el mensaje aleatorio y cifras el mensaje con AES. Envías la info al server y el server descifra la AES con su privada (la del server), descifra el mensaje con la AES y computa la firma digital con la pública del cliente. Si la firma digital es satisfactoria entonces has autenticado al cliente al 100%.


Segun entiendo , en esta propuesta el usuario ya no genera sus claves RSA (como hemo hablado anteriormente).
Las genera el servidor y se los manda al usuario (¿es esto correcto?)

Aunque creo que he entendido luego el proceso de autenticacion, estoy un poco perdido en esto:

Citar
Ahora si entrán a tu server ... vamos a buscar la private key del server ... Digamos que la encuentran, pero no verán más que la privada tuya cifrada por AES.

Y dicha clave AES (la que utilizo para cifrar la privada mía) tendré que tenerla fuera del servidor ... sino no le veo lógica. ¿Es esto correcto?

Si es así ... entonces entiendo que la publica me basta para autenticación 100%,
pero en este caso (si no me equivoco) aunque este autentificado, el usuario no puede descifrar sus datos.

A no ser que no he entendido  bien el proceso

Tambien estoy un poco confundido cuando me dices de las privadas del servidor
¿Hablamos solo de la privada del user generada por servidor? o de dos privadas una del user y otra mia (ambas presentes en el servidor).

Un saludo
4  Seguridad Informática / Criptografía / Re: Algoritmo inscripcion autenticacion en: 26 Noviembre 2016, 15:48 pm
Citar
Si no entiendes algo, pues aquí estoy para lo que necesites.

No sabes cuanto te lo agradezco kub0x !

Al intentar aprender todo como autodidacta (cosas de la vida + tonterias de la juventud) pues aprendo trocitos de cosas quedándome siempre partes que estoy saltando (por no saber de su existencia)

Ojala el proyecto que tengo en la cabeza ira bien, entonces no voy a olvidar tu ayuda te lo aseguro !


Citar
Citar
Ok creo  lo he averiguado.
para el lado cliente en la misma libreria js pone un ejemplo:

cryptico.encrypt(PlainText, MattsPublicKeyString);

y en el servidor con openssl.

Ahí sólo estás cifrando un mensaje con la pública. No veo que estés generando una clave AES aleatoria, ni un mensaje, ni una firma digital ni nada de lo que dije anteriormente :D


Puse solo como un resumen ... (el proceso en si, lo he entendido ... por esto puse lo de usar lo mejor de las dos librerías ... solo estaba un poco confundido con lo del padding )


Sin embargo en lo de la firma , cuando escribi el mensaje puse una pregunta (no se si lo habrás leído) donde te preguntaba si esto de la firma es otro proceso o bien es simplemente un cifrado con AES ... pero luego ... he deducido (MAL) que si, que solo es otro cifrado AES (al que tu llamaste firma) así que borre dicha pregunta.

Ahora que me pusiste las funciones en js ... me puse a encontrar su equivalente en openssl y creo haber encontrado algo el "dgst" (aunque los ejemplos que encontré eran para firmar-verificar un fichero de texto ) de todos modos me doy cuenta que estoy cerca así que lo averiguare por mi mismo.


Ahora ya que se me ha quedado en la cabeza el proceso entero (al menos este cual tratamos aquí en este hilo),
me falta todavía practicarlo un poco cuando tendré tiempo (lo de AES ya he echo practicas queda RSA + esta firma )


O sea ahora de punto de vista matemático seria digamos aceptable como robustez

Los puntos débiles que le veo por ahora serian: la intrusión en algunos (o ambos) de los lados cliente - servidor y/o el phishing + eventualmente la criptoanalisis

Por otro lado, en mi codigo php tengo ya hecha (trabajando en local) la verificación y saneamiento de todos los datos de entrada + PDO + procedimientos almacenados para la interacción con la base de datos
Para el servidor también: redirecionamiento https + HSTS + Hardening & Security cabeceras (XSS, CSRF, secure httponly cookies etc)

Volviendo al tema:
Ahora ya con lo que se sobre AES si RSA intentare reforzar un poco la lógica del login (ya no empleare métodos de la edad de piedra para que el usuario tenga que contar hieroglifos en una tabla sumeria :D )

A ver que te parece.

Asumiendo que el usuario pilla algun keylogger virus troyano etc, o peor un acceso a su maquina o se le hace un phishing. Entonces esto comprometería todo.

Por esto voy a dividir el acceso a los usuarios en dos partes:
-una para poder trabajar solo con usuario + contraseña, en donde si alguien le roba su contraseña o la sesión que no le afecte
-y otra para los datos sensibles donde tendrá que utilizar su clave privada (como ya hemos hablado)


En el proceso de inscripción (aparte de lo que hemos hablado) voy a añadir también una OTP que lo va a recibir por SMS (de todos modos voy a tener que comprobar su teléfono.
 Lo que no me puedo permitirme al principio, es usar SMS como segundo factor siempre en cada login ... no todos somos ricos :D )

con esta OTP puedo cifrar su publica al enviarla al servidor y luego que me envía los otros datos ya cifrados con su privada + firma etc, como si seria el primer login.

Entonces esto sera un poco mas cómodo para el cliente ya que solo de vez en cuando tendra que emplear su clave privada ademas la esta exponiendo menos.

O sea la privada del cliente solo se empleara como autorización para los datos sensibles o si se logea de otra maquina (o ha borrado la cookie de su maquina)

-Dicha cookie no va a ser para guardar su sesión (siempre voy a pedir user+pass para login aunque tenga cookie)
 pero la empleare como si seria una OTP una vez usado generare otra (cifrada en el servidor + httponly + secure)

Así que si se le roba el pass o esta cookie otra vez SMS + su privada (como hemos hablado) Si alguien abusa de SMS hago que mande el a mi un SMS.

Entonces aunque se le ha robado incluso su privada + su passphrase queda el SMS como OTP.

Ademas al mandarle el SMS, lo voy a emplear también para cifrar la publica del cliente que tengo en el servidor.
Me mando esta clave que he empleado a mi mismo y la destruyo (asi cubro tambien la parte del servidor)

Ahora (desde mi punto de vista quedarían estas debilidades seguro son mas :D pero no me doy cuenta):

-Que el atacante haga todo el proceso ar revés
 
O sea primero hacerse con la publica del cliente que tengo en servidor y luego que robe al menos user+pass+privada+passphrase del usuario y usarlos para descifrar los datos del cliente.

¿Tendrás alguna idea al respecto para evitar esto? (claro que no entre! pero si entra ... creo que ya me dijiste ... si entra .... no sirve de nada el cifrado )

Y la segunda seria criptoanalisis en lo cual soy NULO !

Por esto mi pregunta es:
 ¿ayudaría que los passphrases del cliente para la generación del primer par RSA y la del AES (usada para cifrar su privada) serian algo complicadisimos y largos?

Algo así (mas complejos todavía pero no me deja el foro ponerlos aquí:
Citar
¥ö `ŠúZtq¯>à@I?¥øƒafF ÁƒpÂé‡ 臬qúy_Ðpà„Á?ð8‡7`ÆRÍØU±+XøŒàBb:9^ƒPCmêm“oU›í£è\õ':ë`µNžTêOfEùÁŸ =:/ðf£­e


Ya te preguntaras ¿Y como se supone que va memorar el usuario tal cosa?

He pensado en hacer que el usuario guarde su privada y su passphrase en unas fotos (esto si no juntas)

Por esto quiero usar para que escoja unas fotos que se puede recordar usando

Citar
FileReader(); //para abrir las fotos en el lado cliente
readAsBinaryString(); // para generar la passphrase


y emplear esta librería: https://eligrey.com/demos/FileSaver.js/

para que el cliente guarde de manera mas sencilla su privada y su passphrase (esto si AVISANDOLE QUE NO LAS GUARDE en la maquina por lo menos la foto de passphrase) ... de todos modos podre emplear el SMS que recibe para crear un algoritmo de regenarcion de passphrase en base a dicha foto

Todo esto en el lado cliente sin necesidad del servidor.

Apropósito servirá de algo, que antes de introducir su foto (usada como passphrase) le obligo que se desconecte de internet ?
Puedo chequear si tiene conexión y sugerirle que se desconecte antes de introducir su privada y su passphrase luego quitar la memoria (ssd o usb) y volver a conectarse para continuar el proceso  

Se que es muy paranoia pero de este modo solo seria complicado para mi hacerlo y no para el usuario emplearlo asi que puedo cumplir tambien con lo de Kerckhoff (menos lo de desconectarse de internet).


Bueno ojala funcione bien lo que intento hacer como negocio y si se gana algo emplear personas calificadas para estos propósitos creo que seria lo mejor pero hasta entonces tendré que sobrevivir

Te aseguro que no me olvidare de ti tampoco

Gracias por tu paciencia y tu extensa ayuda  ... me ha servido mucho

Ahora como he dicho practicar (cuando puedo) y te molestare de vez en cuando con alguna duda puntual y no escribirte mas novelas como esta

Un saludo y felicitaciones por lo que haces






5  Seguridad Informática / Criptografía / Re: Algoritmo inscripcion autenticacion en: 24 Noviembre 2016, 14:45 pm
Gracias kubox,

En principio me ha quedado todo claro.


Citar
Haz un PBKDF user+pass+salt+it y pásaselo a generateRsaKey como la passphrase. Si dos passphrase son iguales, también lo serán las private key.

¿Aportaria alguna mejora si hago asi?

Como tengo otra libreria (CryptoJS) para AES (cada una con sus pro y contras ) intentare aprovechar lo mejor de cada una por ejemplo:

CryptoJS tiene SHA3-512 PBDKF2 y Pkcs7 para padding pero no tiene PRNG
En cambio cryptico tiene PRNG pero hashes mas flojos pbdkf1 y padding con ceros

Entonces usare PRNG de la libreria cryptico para generar IV y salt
y generare la key usando la libreria CryptoJS

Código
  1. var key = CryptoJS.PBKDF2(passphrase, salt, { hasher: CryptoJS.algo.SHA3-512, keySize: 4, iterations: it });
  2. //keySize: 4 es para 32bytes
  3.  


hmm el padding se queda con ceros (pero voy a mirar si puedo emplear CryptoJS para AES en vez de AES que tiene "cryptico"

Apropósito: Desde algunos meses que hemos hablado la primera vez me he quedado con una duda:
El numero de iteraciones ... hay que guardarlo en algún lugar ?  no se si te acuerdas que me dijiste que algunos emplea un rango de tiempo 9-10 milisegundos ...

Entonces cuando uno va a descifrar con AES ¿como saber cuantas iteraciones poner?


Citar
la clave privada cifrada con AES (no por RSA  :P)
:D Ha sido solo una confusión de términos (al no ser muy acostumbrado con ellos)  ... en la cabeza la tenia correcto AES y no RSA.


Citar
- Después del login, el usuario genera una clave simétrica AES y un mensaje aleatorio. El usuario computa el SHA-256 sobre el mensaje y lo firma con su privada, esto es una firma digital sobre el mensaje. Ahora el usuario cifra el mensaje aleatorio con la simétrica y cifra la clave simétrica con la pública del servidor y envía al servidor el mensaje aleatorio cifrado, la clave simétrica cifrada por la pública del server y la firma digital.
- El servidor recibe el mensaje aleatorio cifrado por AES, la clave simétrica AES cifrada con la pública del servidor (su pública) y la firma digital. El propio server coge la clave simétrica cifrada y la descifra con su privada, coge la firma digital y la descifra con la pública del usuario (recuerda que fue guardada en el registro), coge el mensaje aleatorio y lo descifra con la simétrica obtenida. Ahora que tiene el mensaje aleatorio en plaintext, computa el SHA-256 y lo compara con el descifrado de la firma digital. Si son iguales, el servidor sabe que el mensaje fue firmado por el usuario y sabe que sólo el propio servidor puede descifrar la clave simétrica. Esto nos da una autenticidad REAL (PGP trabaja así cuando se utiliza RSA+AES).

El proceso en si, después del login lo he entendido, pero como nunca he trabajado con RSA me queda una duda.
 (casi dos con lo de firmar "y lo firma con su privada") ... supongo que "firmar" quiere decir también "cifrar" con su privada (en este caso) ...
entonces si es así me queda solo una duda:

En el proceso de cifrar con las claves publicas (mia y la del usuario) y privada del usuario
¿se utiliza AES para cifrar y se emplean dichas claves como passphrase para crear una clave AES ? Si seria asi , no hace falta que me expliques como se hace porque esto ya lo se hacer. (PBKDF+passphrase+SHA+IV+salt+it)
¿O es un cifrado que se hace de alguna forma (diferente de AES) con el mismo RSA?
(cosa que por ahora desconozco ... intentare ahora averiguarlo )


Ok creo  lo he averiguado.
para el lado cliente en la misma libreria js pone un ejemplo:
Citar
cryptico.encrypt(PlainText, MattsPublicKeyString);
y en el servidor con openssl.

Saludos


P.D ... Perdona si me he puesto pesado con tantas preguntas pero prefiero estar seguro que he entendido todo

 




 





6  Seguridad Informática / Criptografía / Re: Algoritmo inscripcion autenticacion en: 23 Noviembre 2016, 12:45 pm
Citar
Otro esquema más y el que más me gusta desde el punto matemático, el más empleado en el real world:

-El usuario al registrarse en el servicio, genera en su equipo un par de claves RSA 2048-bit, envía su clave pública al server y guarda la privada firmada por AES-256 en su equipo. La clave simétrica para cifrar la privada la elige a gusto, pero HA DE RECORDARLA (si la pierde tendrá que avisarte)


Ok entendido.

Lo que desconozco por ahora sobre este sistema, es como implementarlo en el lado cliente.

Mirando un poco por la web di con esta libreria javascript.

https://github.com/wwwtyro/cryptico

Si tienes un minuto para mirar el Overview de la misma a mi me parece que encajaría con lo que propones tu.

Lo que no se, son los pasos que habría tenido que hacer el cliente para cumplir lo que me dijiste arriba

Te pongo aquí dichos pasos tal como lo pienso yo (para ver si he entendido bien) :

- emplear esta librería, u otra parecida a esta en el lado cliente (vi otras discusiones sobre la fiabilidad de las mismas en http://crypto.stackexchange.com/questions/10200/is-javascript-rsa-signing-safe pero parece que cumple ... tu que opinas ?) y generar el par de claves RSA

- sacarle una casilla en donde tiene que ingresar su passphrase para cifrar su llave privada con AES-256 (ya tengo esta otra librería probada )

Aquí tengo una duda Se necesitan 2 Passphrases una para RSA y otra para AES
¿Se utiliza la misma (la que el usuario tiene que memorizar)?

- y al pulsar enviar que mande al servidor su publica (eventualmente en el mismo tiempo con sus datos de inscripción)

- Luego sacarle en una caja de texto la clave suya privada y cifrada con RSA, codificada en base64 para ser compatible ASCII
- el cliente copia la misma y se la guarde como texto en su maquina  (mejor en una usb o tarjeta ssd etc) (Modo paranoia ON -> Esteganografia para privada cifrada con RSA :D )


- Después del login le pongo una caja de texto en donde tiene que pegar su clave privada (ya que con javascript no se pueden abrir ficheros ... aunque vi algo en el mismo HTML5 que tiene una API creo... lo mirare)

- Otra casilla en donde tiene que ingresar su passphrase  y ... "Lo he dejado a los matemáticos" :D

Si es así el resto lo entendí todo.




Me gustaría, si puedes, confirmarme (o no) si los pasos que hago en el lado cliente son correctos o si tu habría pensado en otra cosa.

Un saludo.
7  Seguridad Informática / Criptografía / Re: Algoritmo inscripcion autenticacion en: 23 Noviembre 2016, 06:10 am
Citar
el server no sabe D4, no podrán establecer la misma passphrase

Tienes razon ... me he olvidado el maldito D4 .... intervalo hacia que hacia yo  ??? ;D

Citar
No la he puesto en mi respuesta anterior ya que pensé: no creo que haga que el cliente mandé la passphrase al server. No lo veo conveniente por un motivo, en estos esquemas, lo suyo es que ambos generen P sin tener que compartirla, al igual que Shamir's secret sharing


Supongo que tu tienes toda la razon ... al saber sobre el tema pero mi logica, no me deja entender por ahora en donde seria esto un problema ya que de este modo la P no existe en ningun lado .... solo cuando el cliente la envia ... en algunos milisegundos (segundos) queda inutilizable ya que una vez utilizada esta P ... en el servidor se genera otra , se cifra otra vez con otra P nueva, y despues se destruye . Por mucho que alguien ha capturado la P que mando el cliente ... ya no sirve ... ya hay otra .. empleada y destruida tambien.

Ya lo he pillado ... como la P son las coordenadas .... en 5 - 10 intentos tendra toda la tarjeta ... Solo le falta el D4 ... a por el servidor !!!    (o con un poco mas de paciencia ) ... lo adivinara pronto   :-(

.... A dormir ... en España son las seis y media de la mañana  ... y a soñar .... D4 y demas  :silbar:  ;D ... Gracias kub0x

¿Cual seria entonces tu consejo?

Lo leere luego ... Un saludo
8  Seguridad Informática / Criptografía / Re: Algoritmo inscripcion autenticacion en: 23 Noviembre 2016, 05:04 am
Citar
La tarjeta sería mejor cifrarla con un user+pass+salt+iteracciones usando PKDF + AES-256 + HMAC

Correcto.(solo que la tarjeta lo guardo junto con los otros datos a cifrar no separado)

Lo que si no creo que has entendido es que al cliente se le manda dicho intervalo -> el cliente regerera la P  y se lo manda asi como esta (por https TLS) al servidor o sea la P del cliente es la passphrase ..  usado para generar el key de  AES  con PKDF  para cifrar los datos en el servidor incluso la tarjeta

Al recibir la P correcta el servidor descifra , tiene la tarjeta , genera otros credenciales (otra P) otro key AES y cifra de nuevo con estas nuevas guardando otro intervalo (el nuevo) y destruye la llave y la P.

Al siguiente login el usuario solo recibe el intervalo nuevo ... regenera la P la manda al servidor y este puede usarla de nuevo como passphrase para regenerar la key ... esto si tiene que guardar tambien las iteraciones ... IV +salt ya los tiene

En el mensaje anterior he añadido algo al final ... justo cuando tu creo que me respondías ... que opinas ?

9  Seguridad Informática / Criptografía / Re: Algoritmo inscripcion autenticacion en: 23 Noviembre 2016, 03:18 am
Muy buenas noches kub0x

Desconocía lo de Kerckhoff pero algunos puntos si que los sabia por otras lecturas ( como que mejor que sea conocido y fuerte por su propia fortaleza que por el ocultismo incluso que no sea muy complicado pero no se me ocurría otra cosa )


Por mi parte me gustaría uno con un simple click ni contraseñas ni nada, estilo captcha este "No soy un robot" pero estoy consciente que no es posible.


Llevo solo unos meses tocando un poquito mas de cerca el tema de la seguridad y al principio creí que con https se resuelve la cosa. Pronto me di cuenta que resuelve solo el transporte entonces he empezado ( cuando me ha quedado tiempo ) en alguna manera en cifrar los datos ... luego surgió la pregunta: ¿Y la clave donde lo guardo? ... y de allí llegue a CryptoJS para hacerlo desde el cliente ... el resto lo conoces.

Citar
imagina que al usuario se le roba su private-key pero esta esta cifrada por AES-256-CBC, no me quedaría otra que ver en que equipos posiblemente esté almacenada, pero quizá no lo esté... Con esto quiero decir que cuanta menos información se guarde mejor.

De acuerdo contigo pero llegamos al kelogger + los demás y estará cifrada por AES-256-CBC con una passphrase que tiene que introducir en la maldita casilla :D

Citar
Lo mejor es usar una tarjeta de coordenadas electrónica

No entiendo que quieres decir con electrónica. ¿Hay alguna con chip o algo así?

He mirado en google y lo que vi es (en la cajarural) "Tarjeta de firma electrónica"  o sea la llaman electrónica pero es la misma de las coordenadas nada de electrónico.  Además no voy a tener los medios al principio para permitirme esto.


Como te dije al principio sabía que no tiene que ser complicado y la manera en que la he pensado yo no solo que no es trivial ... Es un verdadero coñazo !!!... Imagínate medio planeta ( que intento conquistar  :D ) con sus bolígrafos, contando dígitos en sus tarjetitas ... y maldiciéndome a mi :D )))))

Claro que me gustaría algo más sencillo pero por ahora no se qué.

A no ser que no he entendido yo bien: O sea sin el rollo del conteo en el cual he pensado, ¿quieres decirme que es bastante robusto así pedir directamente 3 coordenadas ( y cambiar la tarjeta cada cierto tiempo )?

¿O quedarme  solo con la parte (de la idea que tenia) de la coordenada secreta + un pequeño conteo ( :D sin boligrafo) y escoger la coordenada que coincide con el conteo + dos vecinas?



Muchísimas gracias por tu ayuda kub0x

P.D.

Citar
En tu caso sucedería lo mismo, da igual cuantas veces cambies el sistema que si se le roba la tarjeta adios. Vale, el atacante no sabría el valor privado (a no ser que entre al server), pero teniendo la tarjeta del usuario, no tardaría mucho en adivinar el valor privado antes de que el usuario reporte el robo o se de cuenta de la intrusión

El valor privado no se guardaría en el servidor ... se envía al usuario al inscribirse (para que lo memorice) y no se guarda nada sobre el ni hash ni nada solo se guarda la diferencia entre el valor privado (D4) y el valor usado (A3) en el ejemplo seria la cifra 5 y a los 3 intentos si que el cliente sabrá porque se bloquea.

La tarjeta entera si tiene que guardarse con los otros datos del cliente a cifrar pero cifrados AES-CBC con la passphrase P.

A no ser que quieres decir que al saber esta distancia 5 ... intentara todas las posibilidades. Entonces se podrá mejorar hacer el cliente Que recuerde también esta diferencia (seria como su OTP).
O mejor que se renuncia al lio de guardar una secreta, luego recibir el intervalo y luego el conteo.
Darse cada vez que recuerde una como privada como su OTP


Lo que me gustaba mas con la P de 30 dígitos era que al menos para la fuerza bruta parecía mas fuerte (en teoria)

Pero si lo pienso bien ... con una normal (o sea 3 coordenadas 15 caracteres) pero con mayúsculas + minúsculas + dígitos tampoco no se queda demasiado lejos (en teoría fuerza bruta)

Ademas si le añado esto de que memorice siempre una privada como OTP, ni siquiera le digo que coordenadas tiene que ingresar que ya sabe una, mas dos vecinas

Hmm y aqui entra el keylogger o troyano   >:D  ;D cuando le voy a dar la siguiente OTP
10  Seguridad Informática / Criptografía / Re: Algoritmo inscripcion autenticacion en: 22 Noviembre 2016, 21:11 pm
Primero gracias por tu tiempo kub0x

Citar
Déjaselo a los matemáticos
 :D  Tienes toda la razon.
Citar
y desde ese día me puse la meta de comprender la matemática subyacente
Aquí también lo has clavado ... has conseguido convencerme que por aqui esta el camino para mi también.


Lo que pasa es que hasta alcanzar dicha meta ( o intentar acercarme a ella ) tengo que sobrevivir de alguna manera :D  (ademas tengo medio siglo de vida y sera mas difícil de roer huesos del gigante a esta edad)


He mirado un poco lo de Secure multi-party computation y Secure two-party computation pero no he insistido mucho viendo que se requiere un tercero de confianza (que en caso de la web supongo que seria un servidor ... ¿me equivoco?).

Inspirado en tu firma "No hay amigos, ni enemigos, lucha necia, todos contra todos" ... pues igual con los servidores en que servidor voy a tener yo 100% confianza :D


Volviendo a los matemáticos, (por esto me gustaba lo del Shamir sharing secret) pero no hay matemático que pueda hacer que al querido cliente no se le robe su secreto con un keyloger, troyano etc o en el caso de Secure multi-party computation (y otros por estilo), que no haya listo suelto (como tu decías) que no entre algún día en dicho servidor de confianza.


Así que para luchar con el gigante (como no conozco bien sus armas)... haré otro intento pero jugare sucio :D ... o sea intentare no emplear las armas del gigante (la matemática) ... y empleare las manos, los ojos, y cabeza del querido cliente ... que por cierto no va a ser contento con el trabajo que le voy a dar, pero si clama seguridad ... que venga con su contribución para poder alcanzarla !!! (¿No les parce correcto ?)


Entonces Voy a dividir el acceso de los usuarios en dos secciones:

- Una para poder trabajar, donde se usa el usuario y contraseña de toda la vida + (https TLS ... para toda la web no solo login)

- Y otra sección para datos sensibles + otras cosas que necesitan mas seguridad para la cual el cliente genere manualmente una passphrase (la P de antes) de al menos 30 digitos de longitud (y de un solo uso) pero sin revelar mucha información de su tarjeta.


   - El cliente  memoriza solo una referencia ( que le da el servidor al inscribirse ej D4 de antes )
   (¿Me explico? no memoriza el valor de la coordenada solo su referencia D4)
   
   - El servidor le manda un numero (entre -10 y +10) ej: 5 (que lo sabe desde cuando genero la ultima passphrase)
   Entonces el cliente cuenta 5 coordenadas en su tarjeta empezando desde la que tiene memorada (D4)
   Lo que le dará A3 (porque la D4 es la penúltima de su tarjeta y D5 la ultima)
   
   - Apunta a mano en un papel el valor de A3 mas los valores de sus vecinos A2 y A4 (en una sola linea)
   Ej:
   791624629153825 (15 digitos de tres coordenadas)
   
   - Ahora emplea como algoritmo los mismos dígitos que conforman el numero resultante de arriba
   Tacha el primer dígito (7 en este caso), cuenta siete dígitos adelante llegaría hasta el 6
   y apunta sus vecinos (4 y 2) o sea ahora P = 42
   Tacha el segundo dígito 9 cuenta nueve dígitos adelante, le sale 1 y apunta sus vecinos (9 y 5)
   Ahora P = 4295
   etc ... etc ...

   Si contando, supera al final continua empezando desde el principio
   Ej: para el 8 (el que esta a 3 posiciones antes del final)
   cuenta hasta el 2 (el quinto dígito desde el principio) y sus vecinos son 6 y 4
   Espero que se entiende

   - Al final P = 429596212621582171952785642712 (30 digitos)
   

  Solamente pido tu opinión (o de otros conocedores) y si ésta es también fácil de romper, ya no te molesto mas (tonterías por la cabeza me pasan millones :D )
  
  Como mejora ya me ha pasado una tontería ( en este instante ) :D ... hacer dos tarjetas esta misma numérica para el algoritmo de conteo y otra alfanumérica (mayúsculas + minúsculas + números) de donde escoger para construir la P
  
  Y otra :D ... no paro en soltar tonterías :D Para que la longitud de P no sea fija, escoger el primer dígito
  Ej actual 4 contar cuatro desde el mismo llegamos al 5 y agregamos los 5 dígitos contando desde el 5 (59621) al final de la P

  ahora P = 42959621262158217195278564271259621 (35 dígitos) y nunca no se sabrá cual es la longitud
  
  También quiero subrayar que ésta seria de un único uso (como las OTP) cada vez el servidor genera otra para la siguiente autenticación ( mejor dicho autorización, para cuando hace falta, ya que para autenticación utiliza contraseña normal)
  
  Saludos y gracias por adelantado.
  
  P.D (Perdone también por mi Castellano ... lo aprendí "a la oreja")
Páginas: [1] 2 3
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines