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.

Order Deny,Allow
Deny from xxx.xxx.xxx.xxx
 

En mi proyecto tengo todo redireccionado a mi index.php a traves de htaccess

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php?otras_variables=$1 [NC,L,QSA]
 

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

Hola kub0x,

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

Fue esta frase que me confundió:

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.

Muy buenas ,


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






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:


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

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 !




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 )

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 )

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 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í:


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



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

Gracias kubox,

En principio me ha quedado todo claro.



¿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

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

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?


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.



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:
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

 




 

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 )


- 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"

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.

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



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    ... Gracias kub0x

¿Cual seria entonces tu consejo?

Lo leere luego ... Un saludo

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 ?

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.


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


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   ) con sus bolígrafos, contando dígitos en sus tarjetitas ... y maldiciéndome a mi )))))

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 ( sin boligrafo) y escoger la coordenada que coincide con el conteo + dos vecinas?



Muchísimas gracias por tu ayuda kub0x

P.D.


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     cuando le voy a dar la siguiente OTP

Primero gracias por tu tiempo kub0x

   Tienes toda la razon.
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  (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


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 ... 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 )
  
  Como mejora ya me ha pasado una tontería ( en este instante ) ... 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 ... no paro en soltar tonterías 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")