¿Como resolvéis la autenticación y autorización?

[Pedro Narciso García Revington]

Hola,

En asp.net no tenía que darle muchas vueltas a este tema ya que ya venía "de serie".

En nodejs no encuentro ningún módulo parecido. A saber:

* Que me almacene la contraseña "salada". Preferiblemente por bcrypt.

* Que a partir de X intentos de autenticación fallidos bloquee al usuario.

* Que permita bloquear/desbloquear usuarios.

* Que me permita establecer roles para los usuarios y proteger el acceso a ciertos recursos en base a estos.

* Que incluya un proceso de creación de cuenta: formulario -> envío email -> verifico -> ok

* Que incluya procesos para reestablecer la contraseña

Probé everyauth pero no me terminaba. Al final me he hecho un middleware que me permite parcialmente estas cosas.

¿Que usáis vosotros?

[David Roncancio]

Hola pedro 

yo he usado passportjs, connect-auth y tambien como dices un middleware a mano, pero muchas de las cosas que dices son mas de autorizacion y gestion de usuarios que autenticacion como tal, uno de esos no conozco seria interesante tenerlo, a ver si alguien se le mide a hacerlo XD, 

Cordialmente,

David Roncancio
(+57) 3014311354

2012/8/3 Pedro Narciso García Revington <p.rev...@gmail.com>

--
 
 

[David Roncancio]

Sepodria armar uno con cosas como

-locomotive

-locomotive-mongoose

-passportjs

-mongoose-admin

no se si ya exista algo armado

David Roncancio
(+57) 3014311354

2012/8/3 David Roncancio <david.r...@gmail.com>

[Pedro Narciso García Revington]

Pues igual me animo y creo un módulo para esto.

[Carlos Villuendas Zambrana]

Hola,

Pues yo sería el primero en usar. Realmente sería bastante útil. Ya nos iras diciendo si al final te animas :)

 

--
 
 

[Pedro Narciso García Revington]

Te comento,

Ahora mismo estoy llevando un proyecto personal para dominar el mundo y tal y cual.

Este módulo (autenticación + autorización) me hace falta pero me lo puedo dejar para casi el final. 

Pero, si hay más interesados, me encantaría intercambiar ideas y así adelantar trabajo.

Había pensado que los procesos como crear una cuenta, cerrarla, resetar password, etc fueran reentrantes p.e https://github.com/iriscouch/txn#example-account-signup

Además de disponer de un middleware para restringir rutas, datos, etc por roles. Poder extenderlo con facilidad para, por ejemplo, restringir recursos según el tipo de cuenta (pago, gratis, premium…)

La flexibilidad es importante y dar la libertad "de serie" en opciones como tipo de cifrado, función hash, función para crear identificadores, etc. Es un fallo garrafal que me he encontrado en algunas librerías (que no tienen nada que ver con node).

¿Que os parece?

--
 
 

[Carlos Villuendas Zambrana]

Hola,

A mi me parece super interesante pero desde luego es un curro enorme. Eso no se hace ni en una ni en dos tardes. Pero desde luego sería guay tener algo con cancan en Node. Lo que me extraña es que no haya ya algo así. Estas seguro que no lo hay. De todos modos yo ahora mismo también esto con una page que va a necesitar autenticación pero desde luego nada tan bestia. Quiero hacerla rápido y sacarlo algo a la luz pronto. Pero para entonces podríamos ver si un estas interesado en ponerte a hacerlo y podríamos mirarlo.

--
 
 

[David Roncancio]

Hola Pedro si le arrancas seguro te colaboro con algo, 

aquí hay algo para manejar la autorización(https://github.com/chlu/node-authorization), pero creo que lo que tienes en mente es algo mucho mas grande, eche una segunda mirada rápida y no he encontrado nada

David Roncancio
(+57) 3014311354

2012/8/4 Carlos Villuendas Zambrana <carlo...@gmail.com>

--
 
 

[Pedro Narciso García Revington]

He estado dándole vueltas y creo que no lleva tanto curro. 

Explotando la modularidad de nodejs mucho menos. 

Desde luego mucho menos que en otras plataformas.

Os tomo la palabra y voy a darle un tiento esta misma semana.

[Pedro Narciso García Revington]

Hola,

Hoy he colgado un módulo, que trata de prevenir los intentos de conseguir acceso por la fuerza bruta.

Su uso nos permite aumentar los requisitos de autenticación —captcha, pregunta secreta— a medida que el usuario falla en su intento de acceder.

Además entre intento he intento dilata el tiempo de respuesta de forma exponencial hasta un tope.

A ver si mañana puedo darle un tiento y creo el package.json y algunos test.

[Pedro Narciso García Revington]

Se me olvidaba lo más importante… https://github.com/revington/benji

[Ignacio Tolstoy]

No se el resto pero yo hace unos días que estoy probando

http://passportjs.org/ 

Y va bastante bien.

Para conexión con user&pass

https://github.com/jaredhanson/passport-local 

[Pedro Narciso García Revington]

Hola Ignacio, 

Lo que echaba de menos era tener precocinado el proceso de recuperación de contraseñas, 

aumentar el desafío para el login en caso de intentos fallidos y demás.

Para lo segundo voy a combinar el módulo que he hecho https://github.com/revington/connect-bruteforce con https://github.com/aldipower/nodejs-recaptcha.

Para la recuperación/reseteo de contraseña voy a usar este https://github.com/substack/node-password-reset 

En mi primer email dije 

* Que a partir de X intentos de autenticación fallidos bloquee al usuario.

Esto es un error de bulto, sólo quiero que ralentice la respuesta hasta un tope.

Para la protección de recursos por roles hay varios módulos ya creados pero aún no los he estudiado.

Para el proceso de creación de cuentas es posible que cree un módulo si es que no existe ya alguno.

Un saludo

[Gustavo Machado]

Pedro,

Estuve viendo connect-bruteforce y tiene muy buena pinta, sin embargo,
vi esto en el codigo:

self.clientID = function (req) {
return req.connection.remoteAddress;
};

Me pregunto si en el caso de dos personas en la misma red privada no
tendrian la misma remoteAddress y si no es mas comun y conveniente
manejar esto con una cookie.

Saludos,
Gustavo


2012/8/15 Pedro Narciso García Revington <p.rev...@gmail.com>:

> --
>
>

[Pedro Narciso García Revington]

Hola Gustavo,

Me alegro de que te guste y espero que te sea útil.

En el caso que planteas, los otros clientes simplemente verán que su inicio de sesión tarda un poco más de lo habitual.

El problema con la cookie viene con la sistematización de un ataque por la fuerza bruta;

El atacante no la va a respetar (la cookie) y no vamos a ser capaces de prevenir el ataque.

Dicho esto, acabo de caer en que clientID debe ser reescrito para el caso en el que estemos detrás de un proxy. Más o menos así:

self.clientID = function (req) {
        return req.header('x-forwarded-for') || req.connection.remoteAddress;

};

Esta tarde lo miraré.

Un saludo,

Pedro

--

[Gustavo Machado]

Pedro, perdón por la tardanza, pero quizás mi respuesta no fue de lo
mas completa.

El hecho de no tener en cuenta la sesion, podria evitarte un brute
force attack, pero podria facilitar un DoS, ya que cualquiera enviando
muchos requests desde una red, podria ocasionar largas esperas a todos
los usuarios (imaginate una conferencia, un cyber, una oficina, etc).

Lo que quise decir es, que quizás si no tienen una session valida se
pueda retardar el primer intento. De esta forma los requests sin
session o con sessions no "inicializadas" puedan ser retardadas desde
el intento 1 (ni mucho ni poco, unos 5 segundos quizás).

Quizás no tenga mucho sentido esto (no soy experto en seguridad ni mucho menos).

Saludos,
Gustavo


2012/8/16 Pedro Narciso García Revington <p.rev...@gmail.com>:

> --
>
>

[Pedro Narciso García Revington]

Hola Gustavo,

Puedes y debes establecer un tope. 

La penalización que para un ataque por la fuerza bruta es una gran barrera

para un usuario será aceptable.

Además —y tal y como comento en el ejemplo que hay en el proyecto, puedes requerir una prueba de que no se 

trata de un robot a partir del x intento mediante captcha, pregunta o similar.

Al igual que tú yo no soy ningún experto. Estas técnicas son las que he encontrado en textos sobre el tema.

Hay un hilo interesante en stackoverflow http://stackoverflow.com/questions/424210/preventing-brute-force-logins-on-websites

Esto es un requisito de la agpd (protección datos, España) para los sistemas de nivel medio para arriba.

En otros países desconozco como está el tema.

Saludos, 

Pedro

[Gustavo Machado]

Pedro, en el link que nos enviaste dice esto:

"There is at least one whole country is NAT'ed in asia, so IP's cannot
be used for anything."

Y sugieren usar una key que creo que tiene mucho mas sentido que es el
Username :)

Saludos,
Gustavo

2012/8/28 Pedro Narciso García Revington <p.rev...@gmail.com>:

> --
>
>

[Pedro Narciso García Revington]

El problema que tienes con eso es que un atacante con un password y una lista de usuarios puede penalizarte un montón de usuarios. Y si no penalizas la ip, a la velocidad que quiera.

Solución salomónica: por defecto por ip tal y como está. Y si no te convence, la posibilidad de alterar el comportamiento mediante opciones. ¿Que te parece?

Saludos, 

Pedro

[Gustavo Machado]

Si, me parece bien, quizas podrias exponer la funcion clientID en las
opciones, y dejar por defecto que busque por IP.

Gus

> --
>
>

[Pedro Narciso García Revington]

En efecto. Sobreescribiendo clientID lo tendrías:

var bruteForce = new (require('connect-bruteforce'))();

bruteForce.clientID = function(req){

    return req.body.username;

};