Re: [OT] OAuth y 2FA (Era: Servidor imap.gmail.com y mutt falla.)
On Thu, 19 May 2022 20:38:26 +0200
Camaleón <noelamac@gmail.com> 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 <hubble@telefonica.net>
Reply to: