[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Clarification]

From: Uwe Brauer
Subject: Re: [Clarification]
Date: Tue, 07 Jun 2022 18:24:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>>> "YK" == Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Tue, 7 Jun 2022 at 14:16, Uwe Brauer <oub@mat.ucm.es> wrote:
>> as Tim and other pointed out, I can use, what google calls a app
>> password that I have to generate. I find this a bizarre
>> design/security decision since this password is considerably
>> shorter than my original imaps/smtps password.

> I can try to explain the idea of app passwords, and then maybe they
> will not seem as bizarre to you.

> What we start with is a single Google account, with a single password,
> and all client applications using this password. Easy to configure,
> bad for security: most users will choose a weak password and store it
> in many configuration points, and if it leaks or is stolen from any of
> those, the whole account is compromised. The attacker can use your
> master password to log in and change your password, and then you are
> locked out.

> On the other hand, with app passwords, each password is constrained to
> a single client application. You generate a password for your email
> client and it can connect with that password. If that password gets
> stolen, the attacker has temporary access to your data. They cannot
> change your password and lock you out. When you find out, you revoke
> the leaked password and generate a new one, and then the attacker is
> locked out and your account is no longer compromised.

I see point taken, thanks.

However for my taste they are too short, I'd prefer them at least to
have 32 chars or better more.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]