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.
Reply to: