Re: [OT] OAuth y 2FA (Era: Servidor imap.gmail.com y mutt falla.)
On 2022-05-19 at 20:38 +0200, Camaleón wrote: > Entiendo las ventajas que supone para la parte servidora usar ese > sistema, pero no para el cliente, y menos aún cuando se trata de correo > electrónico. El correo convencional (no el webmail) no es una API, no > es un servicio, y hacia eso lo quieren arrastrar (desnaturalizar la > esencia del coreo electrónico) pero preferiría que el servidor de correo > me pidiera en certificado digital para autentificarme que usar ese > sistema farragoso de OAuth; auguro problemas de todo tipo y máxima > incomodidad para los clientes. No es una ventaja para los clientes de correo ni está diseñado como tal. Ellos funcionarían mejor simplemente con una contraseña. Para los usuarios, es una cuestión de que el cliente de correo de su elección soporte este sistema. > Ahora bien, lo que ya me pierde es la mezcla de OAuth con la > doble, triple o multi autentificación (2FA). Estos sistemas de doble > seguridad los entendería razonables para validar ciertas operaciones > críticas o autentificaciones ante servicios delicados, pero no para > iniciar sesión en un buzón de correo convencional (POP/IMAP, no > webmail), espero que no sean tan vacaburros de forzar también su uso > o derivarnos al webmail :-/ El problema de fondo es que la gente utiliza contraseñas inseguras. Si tu contraseña es «Camaleon1» el servidor de Gmail no podrá hacer demasiado para proteger tu cuenta (y seguro que tienen clientes con contraseña aún más ridículas y que se negarán a cambiarlas, pero que les cuplarían si les entran en la cuenta). Lo que consiguen con OAuth es dirigir al usuario al navegador, donde tienen mucha más libertad: le pueden pedir un segundo factor (si lo tiene configurado), reenviarlo a un servidor SSO, pedirle una pregunta de seguridad, hacerle resolver un captcha, etc. Una vez dado de alta (a través de ese acceso por la web) el cliente de correo, este se conectará haciendo uso del token que le ha devuelto para cuando necesite acceder. Un saludo
Re: [OT] OAuth y 2FA (Era: Servidor imap.gmail.com y mutt falla.)
El día 19/05/2022, a las 20:38, Camaleón escribió: > El 2022-05-18 a las 09:20 +0200, alfon escribió: > > > > 2. Configurar OAuth2 en Mutt y Fetchmail, si lo permiten, o buscar > > > alguna aplicación alternativa que sí tenga soporte. > > > > > > Seguramente, y para curarme en salud, haga las dos cosas (1 y 2) :-) > > > > > > > Las opciones son usar OAuth (no tengo claro que mutt lo soporte) o una > > > > contraseña de aplicación (pero Google no te las ofrece a menos que > > > > tengas activado el 2FA) > > > > > > Para Mutt he visto esto (no lo he probado): > > > > > > mutt integration with Gmail using OAuth > > > https://luxing.im/mutt-integration-with-gmail-using-oauth/ > > > > Yo tengo configurado mutt con Oauth2 y funciona perfectamente. Existe > > un script proporcionado por Google que automatiza en parte el proceso. > > > > Si tenéis problemas concretos configurándolo lo podemos resolver en > > este u otro hilo de la lista. > > Me parece especialmente interesante este tema, y creo que nos puede ser > de utilidad a todos, por un motivo u otro. > > He estado leyendo sobre OAuth en la página de la Wikipedia para empezar > a entender de qué va :-) > > Si no lo he entendido mal, se trata de un sistema/mecanismo/protocolo > por el que un servicio/servidor permite a un cliente generar un token > para permitir el acceso de terceros (o a él mismo) a sus datos/ > servicidos/credenciales. Por lo que yo he entendido es parecido a Kerberos: Es decir, hay un sistema mediador entre el cliente y el servidor, que proporciona el acceso a este último mediante tokens (vamos... códigos) Sería como si compro un abono transportes que me permite acceder al metro hasta que caduque. > Entiendo las ventajas que supone para la parte servidora usar ese > sistema, pero no para el cliente, y menos aún cuando se trata de correo > electrónico. El correo convencional (no el webmail) no es una API, no > es un servicio, y hacia eso lo quieren arrastrar (desnaturalizar la Yo creo que el correo electrónico es un servicio, ¿no? > esencia del coreo electrónico) pero preferiría que el servidor de correo > me pidiera en certificado digital para autentificarme que usar ese > sistema farragoso de OAuth; auguro problemas de todo tipo y máxima > incomodidad para los clientes. Un poco incómodo sí que es, pero también es más seguro que la contraseña tradicional. Mi problema es que tengo que actualizar el código de refresco cada x días. Se supone que este no caduca, pero en mi caso sí que lo hace. Esto es incómodo, porque tienes que obtenerlo ejecutando el script que proporciona gúgol (oauth2.py) y obtener un código de autorización mediante el navegador web. Para los terminalitas como yo esto es un atraso. Seguro que se puede automatizar usando curl o algo por el estilo, pero esto complica más la cosa. > > Ahora bien, lo que ya me pierde es la mezcla de OAuth con la > doble, triple o multi autentificación (2FA). Estos sistemas de doble > seguridad los entendería razonables para validar ciertas operaciones > críticas o autentificaciones ante servicios delicados, pero no para > iniciar sesión en un buzón de correo convencional (POP/IMAP, no > webmail), espero que no sean tan vacaburros de forzar también su uso o > derivarnos al webmail :-/ Si eso sucede nos hacemos un servidor de correo para nosotros, que no?!!! jeje... Yo estoy deseando hacerlo y dejar de usar gúgol.
Re: [OT] OAuth y 2FA (Era: Servidor imap.gmail.com y mutt falla.)
El 19 de mayo de 2022 20:38:26 CEST, "Camaleón" escribió: >El 2022-05-18 a las 09:20 +0200, alfon escribió: > >> > 2. Configurar OAuth2 en Mutt y Fetchmail, si lo permiten, o buscar >> > alguna aplicación alternativa que sí tenga soporte. >> > >> > Seguramente, y para curarme en salud, haga las dos cosas (1 y 2) :-) >> > >> > > Las opciones son usar OAuth (no tengo claro que mutt lo soporte) o una >> > > contraseña de aplicación (pero Google no te las ofrece a menos que >> > > tengas activado el 2FA) >> > >> > Para Mutt he visto esto (no lo he probado): >> > >> > mutt integration with Gmail using OAuth >> > https://luxing.im/mutt-integration-with-gmail-using-oauth/ >> >> Yo tengo configurado mutt con Oauth2 y funciona perfectamente. Existe >> un script proporcionado por Google que automatiza en parte el proceso. >> >> Si tenéis problemas concretos configurándolo lo podemos resolver en >> este u otro hilo de la lista. > >Me parece especialmente interesante este tema, y creo que nos puede ser >de utilidad a todos, por un motivo u otro. > >He estado leyendo sobre OAuth en la página de la Wikipedia para empezar >a entender de qué va :-) > >Si no lo he entendido mal, se trata de un sistema/mecanismo/protocolo >por el que un servicio/servidor permite a un cliente generar un token >para permitir el acceso de terceros (o a él mismo) a sus datos/ >servicidos/credenciales. > >Es decir, en lugar de decirle a Gmail, «soy fulanito y este es mi >usuario y contraseña», habría que primero generar un token para >permitir el acceso a fulanito, y dado que ese token no contiene los >datos en sí de las credenciales, resulta más seguro contra ataques. > >Hum... sería algo así como decirle al cortafuegos que en vez de >permitir todo y después ir cerrando puertos, que primero cierre todo y >después ir permitiendo cosas concretas. > >Entiendo las ventajas que supone para la parte servidora usar ese >sistema, pero no para el cliente, y menos aún cuando se trata de correo >electrónico. El correo convencional (no el webmail) no es una API, no >es un servicio, y hacia eso lo quieren arrastrar (desnaturalizar la >esencia del coreo electrónico) pero preferiría que el servidor de correo >me pidiera en certificado digital para autentificarme que usar ese >sistema farragoso de OAuth; auguro problemas de todo tipo y máxima >incomodidad para los clientes. > >Ahora bien, lo que ya me pierde es la mezcla de OAuth con la >doble, triple o multi autentificación (2FA). Estos sistemas de doble >seguridad los entendería razonables para validar ciertas operaciones >críticas o autentificaciones ante servicios delicados, pero no para >iniciar sesión en un buzón de correo convencional (POP/IMAP, no >webmail), espero que no sean tan vacaburros de forzar también su uso o >derivarnos al webmail :-/ > >Saludos, > Pues imagina la que se va a montar con los sistemas de los vehículos que usan, por ejemplo, Android Auto, para conectar el teléfono con el coche y poder usar el navegador, las llamadas,... Miedo me está dando... Sistemas inservibles por los que se paga una pasta cuando compras el coche... Saludos
Re: [OT] OAuth y 2FA (Era: Servidor imap.gmail.com y mutt falla.)
On Thu, 19 May 2022 20:38:26 +0200 Camaleón wrote: > El 2022-05-18 a las 09:20 +0200, alfon escribió: > > > > 2. Configurar OAuth2 en Mutt y Fetchmail, si lo permiten, o buscar > > > alguna aplicación alternativa que sí tenga soporte. > > > > > > Seguramente, y para curarme en salud, haga las dos cosas (1 y 2) :-) > > > > > > > Las opciones son usar OAuth (no tengo claro que mutt lo soporte) o una > > > > contraseña de aplicación (pero Google no te las ofrece a menos que > > > > tengas activado el 2FA) > > > > > > Para Mutt he visto esto (no lo he probado): > > > > > > mutt integration with Gmail using OAuth > > > https://luxing.im/mutt-integration-with-gmail-using-oauth/ > > > > Yo tengo configurado mutt con Oauth2 y funciona perfectamente. Existe > > un script proporcionado por Google que automatiza en parte el proceso. > > > > Si tenéis problemas concretos configurándolo lo podemos resolver en > > este u otro hilo de la lista. > > Me parece especialmente interesante este tema, y creo que nos puede ser > de utilidad a todos, por un motivo u otro. > > He estado leyendo sobre OAuth en la página de la Wikipedia para empezar > a entender de qué va :-) > > Si no lo he entendido mal, se trata de un sistema/mecanismo/protocolo > por el que un servicio/servidor permite a un cliente generar un token > para permitir el acceso de terceros (o a él mismo) a sus datos/ > servicidos/credenciales. > > Es decir, en lugar de decirle a Gmail, «soy fulanito y este es mi > usuario y contraseña», habría que primero generar un token para > permitir el acceso a fulanito, y dado que ese token no contiene los > datos en sí de las credenciales, resulta más seguro contra ataques. > > Hum... sería algo así como decirle al cortafuegos que en vez de > permitir todo y después ir cerrando puertos, que primero cierre todo y > después ir permitiendo cosas concretas. > > Entiendo las ventajas que supone para la parte servidora usar ese > sistema, pero no para el cliente, y menos aún cuando se trata de correo > electrónico. El correo convencional (no el webmail) no es una API, no > es un servicio, y hacia eso lo quieren arrastrar (desnaturalizar la > esencia del coreo electrónico) pero preferiría que el servidor de correo > me pidiera en certificado digital para autentificarme que usar ese > sistema farragoso de OAuth; auguro problemas de todo tipo y máxima > incomodidad para los clientes. > > Ahora bien, lo que ya me pierde es la mezcla de OAuth con la > doble, triple o multi autentificación (2FA). Estos sistemas de doble > seguridad los entendería razonables para validar ciertas operaciones > críticas o autentificaciones ante servicios delicados, pero no para > iniciar sesión en un buzón de correo convencional (POP/IMAP, no > webmail), espero que no sean tan vacaburros de forzar también su uso o > derivarnos al webmail :-/ > > Saludos, > > -- > Camaleón > Pero seguro que tod@s intuimos qué es y hacia dónde vamos ;-) gracias. -- hubble
