Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #248090 > unrolled thread

google account say it will no longer deliver email

Started byFero Dali <ferodali@gmail.com>
First post2022-05-11 15:30 +0200
Last post2022-06-04 23:10 +0200
Articles 20 on this page of 105 — 30 participants

Back to article view | Back to linux.debian.user


Contents

  google account say it will no longer deliver email Fero Dali <ferodali@gmail.com> - 2022-05-11 15:30 +0200
    Re: google account say it will no longer deliver email Eike Lantzsch ZP6CGE <zp6cge@gmx.net> - 2022-05-11 15:40 +0200
    Re: google account say it will no longer deliver email mick crane <mick.crane@gmail.com> - 2022-05-11 16:40 +0200
    Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-11 20:00 +0200
      Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-11 20:10 +0200
      Re: google account say it will no longer deliver email Fero Dali <ferodali@gmail.com> - 2022-05-11 20:10 +0200
        Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-11 20:20 +0200
          Re: google account say it will no longer deliver email Fero Dali <ferodali@gmail.com> - 2022-05-11 20:50 +0200
        Re: google account say it will no longer deliver email Virgo Pärna <virgo.parna@mail.ee> - 2022-05-12 12:10 +0200
          Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-05-12 15:30 +0200
          Re: google account say it will no longer deliver email Fero Dali <ferodali@gmail.com> - 2022-05-12 15:30 +0200
            Re: google account say it will no longer deliver email Greg Wooledge <greg@wooledge.org> - 2022-05-12 15:40 +0200
            Re: google account say it will no longer deliver email Virgo Pärna <virgo.parna@mail.ee> - 2022-05-12 20:10 +0200
              Re: google account say it will no longer deliver email Fero Dali <ferodali@gmail.com> - 2022-05-12 21:00 +0200
                Re: google account say it will no longer deliver email Virgo Pärna <virgo.parna@mail.ee> - 2022-05-13 08:00 +0200
            Re: google account say it will no longer deliver email Ash Joubert <ash@transient.nz> - 2022-05-13 01:10 +0200
              Re: google account say it will no longer deliver email "tv.debian" <tv.debian@googlemail.com> - 2022-05-13 01:40 +0200
              Re: google account say it will no longer deliver email Nicholas Geovanis <nickgeovanis@gmail.com> - 2022-05-13 02:30 +0200
                Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-13 07:20 +0200
                  Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-05-13 11:40 +0200
                    Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-13 13:40 +0200
                      Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-05-13 13:50 +0200
                        Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-13 14:10 +0200
                          Re: google account say it will no longer deliver email David Wright <deblis@lionunicorn.co.uk> - 2022-05-13 17:20 +0200
                  Re: google account say it will no longer deliver email Michael Stone <mstone@debian.org> - 2022-05-13 14:50 +0200
                    Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-13 19:30 +0200
                    Re: google account say it will no longer deliver email Ash Joubert <ash@transient.nz> - 2022-05-14 05:10 +0200
                      Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-14 07:30 +0200
                        Re: google account say it will no longer deliver email Celejar <celejar@gmail.com> - 2022-05-16 15:20 +0200
                      Re: google account say it will no longer deliver email Celejar <celejar@gmail.com> - 2022-05-16 15:20 +0200
                Re: google account say it will no longer deliver email Ash Joubert <ash@transient.nz> - 2022-05-14 04:50 +0200
                  Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-14 07:30 +0200
                    Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-14 13:50 +0200
                      Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-14 15:30 +0200
                        Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-14 18:40 +0200
                        Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-14 20:50 +0200
                          Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-14 21:00 +0200
                            Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-14 21:30 +0200
                              Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-15 06:40 +0200
                                Re: google account say it will no longer deliver email gene heskett <gheskett@shentel.net> - 2022-05-15 14:00 +0200
                                  Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-15 15:50 +0200
                          Re: google account say it will no longer deliver email gene heskett <gheskett@shentel.net> - 2022-05-14 22:20 +0200
                  Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-05-14 11:00 +0200
                    Re: google account say it will no longer deliver email tomas@tuxteam.de - 2022-05-14 11:30 +0200
                    Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-14 11:30 +0200
                      Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-05-14 14:10 +0200
                        Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-14 15:10 +0200
                          Re: google account say it will no longer deliver email David Wright <deblis@lionunicorn.co.uk> - 2022-05-16 05:40 +0200
                            Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-05-16 10:10 +0200
                              Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-05-16 12:00 +0200
                                Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-05-16 14:40 +0200
                            Re: google account say it will no longer deliver email Stella Ashburne <rewefie@gmx.com> - 2022-05-16 13:10 +0200
                            Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-16 15:40 +0200
                              Re: google account say it will no longer deliver email David Wright <deblis@lionunicorn.co.uk> - 2022-05-16 18:00 +0200
                    Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-14 14:10 +0200
          Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-06-01 19:10 +0200
            Re: google account say it will no longer deliver email Patrick Bartek <nemommxiv@gmail.com> - 2022-06-01 19:50 +0200
              Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-06-01 20:40 +0200
            Re: google account say it will no longer deliver email nemo <moelmoel2714@gmail.com> - 2022-06-02 17:20 +0200
              Re: google account say it will no longer deliver email rhkramer@gmail.com - 2022-06-02 20:10 +0200
                Re: google account say it will no longer deliver email <paulf@quillandmouse.com> - 2022-06-02 20:30 +0200
                  Re: google account say it will no longer deliver email Felmon Davis <moelmoel2714@gmail.com> - 2022-06-02 20:40 +0200
                    Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-06-04 14:00 +0200
                      Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-06-04 14:20 +0200
                        Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-06-04 16:30 +0200
                          Re: google account say it will no longer deliver email Felmon Davis <moelmoel2714@gmail.com> - 2022-06-04 16:50 +0200
                            Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-06-04 19:50 +0200
                        Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-06-04 16:30 +0200
                      Re: google account say it will no longer deliver email Felmon Davis <moelmoel2714@gmail.com> - 2022-06-04 15:50 +0200
                        Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-06-04 16:00 +0200
                          Re: google account say it will no longer deliver email Felmon Davis <moelmoel2714@gmail.com> - 2022-06-04 19:30 +0200
                            Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-06-04 19:50 +0200
                              Re: google account say it will no longer deliver email Felmon Davis <moelmoel2714@gmail.com> - 2022-06-08 03:40 +0200
                                Re: google account say it will no longer deliver email <tomas@tuxteam.de> - 2022-06-08 06:50 +0200
                                Re: google account say it will no longer deliver email rhkramer@gmail.com - 2022-06-08 14:50 +0200
                                  Re: google account say it will no longer deliver email Felmon Davis <moelmoel2714@gmail.com> - 2022-06-08 18:00 +0200
                                    Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-06-08 18:20 +0200
                                      Re: google account say it will no longer deliver email rhkramer@gmail.com - 2022-06-08 18:30 +0200
                                        Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-06-08 19:20 +0200
                      Re: google account say it will no longer deliver email Curt <curty@free.fr> - 2022-06-04 16:30 +0200
                Re: google account say it will no longer deliver email rhkramer@gmail.com - 2022-06-03 21:00 +0200
    Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-11 20:30 +0200
      Re: google account say it will no longer deliver email Fero Dali <ferodali@gmail.com> - 2022-05-11 21:00 +0200
        Re: google account say it will no longer deliver email Siard <shiems@mailbox.org> - 2022-05-11 22:00 +0200
          Re: google account say it will no longer deliver email John Hasler <john@sugarbit.com> - 2022-05-12 04:00 +0200
        Re: google account say it will no longer deliver email Brian <ad44@cityscape.co.uk> - 2022-05-11 22:20 +0200
          Re: google account say it will no longer deliver email Fero Dali <ferodali@gmail.com> - 2022-05-11 22:30 +0200
    Re: google account say it will no longer deliver email "sp007@caiway.net" <sp007@caiway.net> - 2022-06-04 21:00 +0200
      Re: google account say it will no longer deliver email Richard Owlett <rowlett@cloud85.net> - 2022-06-04 21:10 +0200
      Re: google account say it will no longer deliver email John Hasler <john@sugarbit.com> - 2022-06-04 21:10 +0200
        Re: google account say it will no longer deliver email "sp007@caiway.net" <sp007@caiway.net> - 2022-06-04 22:10 +0200
          Re: google account say it will no longer deliver email John Hasler <john@sugarbit.com> - 2022-06-04 22:40 +0200
            Re: google account say it will no longer deliver email "sp007@caiway.net" <sp007@caiway.net> - 2022-06-04 22:50 +0200
              Re: google account say it will no longer deliver email Edwin Zimmerman <edwin@plainemail.net> - 2022-06-04 23:10 +0200
                Re: google account say it will no longer deliver email "sp007@caiway.net" <sp007@caiway.net> - 2022-06-04 23:40 +0200
          Re: google account say it will no longer deliver email wec <wec@upwardmail.net> - 2022-06-04 23:10 +0200
            Re: google account say it will no longer deliver email "sp007@caiway.net" <sp007@caiway.net> - 2022-06-04 23:20 +0200
              Re: google account say it will no longer deliver email Larry Martell <larry.martell@gmail.com> - 2022-06-05 02:50 +0200
                Re: google account say it will no longer deliver email "sp007@caiway.net" <sp007@caiway.net> - 2022-06-05 02:50 +0200
                  Re: google account say it will no longer deliver email Larry Martell <larry.martell@gmail.com> - 2022-06-05 03:00 +0200
                    Re: google account say it will no longer deliver email John Hasler <john@sugarbit.com> - 2022-06-05 03:10 +0200
                      Re: google account say it will no longer deliver email "sp007@caiway.net" <sp007@caiway.net> - 2022-06-05 06:10 +0200
                    Re: google account say it will no longer deliver email "sp007@caiway.net" <sp007@caiway.net> - 2022-06-05 03:20 +0200
                Re: google account say it will no longer deliver email gene heskett <gheskett@shentel.net> - 2022-06-05 03:50 +0200
          Re: google account say it will no longer deliver email Alain D D Williams <addw@phcomp.co.uk> - 2022-06-04 23:10 +0200

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →


#248153

From<tomas@tuxteam.de>
Date2022-05-13 13:40 +0200
Message-ID<EmBOh-fcmQ-21@gated-at.bofh.it>
In reply to#248148

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 13, 2022 at 09:36:13AM -0000, Curt wrote:
> On 2022-05-13, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
> >
> > It's just the basic antipattern you can see everywhere in surveillance
> 
> You seem to be seeing these antipatterns at the drop of any hat.

Uh -- whatever you mean to say with that.

[...]

> I guess the devil, as always, will be hiding somewhere in the details.

It always does, indeed.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#248154

FromCurt <curty@free.fr>
Date2022-05-13 13:50 +0200
Message-ID<EmBXX-fcq5-3@gated-at.bofh.it>
In reply to#248153
On 2022-05-13, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
>> > It's just the basic antipattern you can see everywhere in surveillance

>> You seem to be seeing these antipatterns at the drop of any hat.
>
> Uh -- whatever you mean to say with that.

I meant that you applied (or employed) the term quite recently in a
completely unrelated thread about openssh, and David Wright's
observation that logging in remotely as root can be problematic.


> [...]
>
>> I guess the devil, as always, will be hiding somewhere in the details.
>
> It always does, indeed.
>
> Cheers
> --=20
> t
>
> --Dpz3S9OQGoUbsVHa
> Content-Type: application/pgp-signature; name="signature.asc"
>
>
> --Dpz3S9OQGoUbsVHa--
>
>


-- 

[toc] | [prev] | [next] | [standalone]


#248155

From<tomas@tuxteam.de>
Date2022-05-13 14:10 +0200
Message-ID<EmChk-fcLP-7@gated-at.bofh.it>
In reply to#248154

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 13, 2022 at 11:44:52AM -0000, Curt wrote:
> On 2022-05-13, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
> >
> >> > It's just the basic antipattern you can see everywhere in surveillance
> 
> >> You seem to be seeing these antipatterns at the drop of any hat.
> >
> > Uh -- whatever you mean to say with that.
> 
> I meant that you applied (or employed) the term quite recently in a
> completely unrelated thread about openssh, and David Wright's
> observation that logging in remotely as root can be problematic.

Hm. It seems I was unclear. Trying to fix it (hopefully *not* making
it worse):

 - I do agree that logging in as root remotely can be problematic
   (especially when root has a weak password). So I think it is
   a good thing for the admin to be able to disable that.
 - I think the software forcing the admin to do that would be an
   antipattern. OpenSSH *doesn't* force the admin to do that,
   so it *doesn't* follow that antipattern.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#248159

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2022-05-13 17:20 +0200
Message-ID<EmFfb-ferl-7@gated-at.bofh.it>
In reply to#248155
On Fri 13 May 2022 at 14:02:40 (+0200), tomas@tuxteam.de wrote:
> On Fri, May 13, 2022 at 11:44:52AM -0000, Curt wrote:
> > On 2022-05-13, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
> > >
> > >> > It's just the basic antipattern you can see everywhere in surveillance
> > 
> > >> You seem to be seeing these antipatterns at the drop of any hat.
> > >
> > > Uh -- whatever you mean to say with that.
> > 
> > I meant that you applied (or employed) the term quite recently in a
> > completely unrelated thread about openssh, and David Wright's
> > observation that logging in remotely as root can be problematic.
> 
> Hm. It seems I was unclear. Trying to fix it (hopefully *not* making
> it worse):
> 
>  - I do agree that logging in as root remotely can be problematic
>    (especially when root has a weak password). So I think it is
>    a good thing for the admin to be able to disable that.
>  - I think the software forcing the admin to do that would be an
>    antipattern. OpenSSH *doesn't* force the admin to do that,
>    so it *doesn't* follow that antipattern.

What I don't understand about that thread is why the shift in
focus to ssh, openssh, and logging in (or otherwise) as root.
I don't see any antipatterns there (they certainly haven't been
spelled out), but just choices made by the sysadmin, between
no root password, having a password but not usable for remote
logins, and so on. Choices helped along by our Debian developers.

Surely the serious antipatterns mentioned in that thread are:
. running setuid scripts, as the OP claimed was possible in the past,
. suggestion to run said scripts as root, without having seen them.

(One of the benefits of posting scripts here is that they get
criticised, usually constructively, and hence improved.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]


#248156

FromMichael Stone <mstone@debian.org>
Date2022-05-13 14:50 +0200
Message-ID<EmCU2-fcXE-1@gated-at.bofh.it>
In reply to#248145
On Fri, May 13, 2022 at 07:16:11AM +0200, tomas@tuxteam.de wrote:
>A loong password is not "equivalent" to 2FA, that's right. Good
>password management (of which length is but a part) is as secure
>as 2FA.

No, it really isn't.

[toc] | [prev] | [next] | [standalone]


#248164

FromBrian <ad44@cityscape.co.uk>
Date2022-05-13 19:30 +0200
Message-ID<EmHgZ-ffzB-3@gated-at.bofh.it>
In reply to#248156
On Fri 13 May 2022 at 08:42:21 -0400, Michael Stone wrote:

> On Fri, May 13, 2022 at 07:16:11AM +0200, tomas@tuxteam.de wrote:
> > A loong password is not "equivalent" to 2FA, that's right. Good
> > password management (of which length is but a part) is as secure
> > as 2FA.
> 
> No, it really isn't.

How does a 40 random character, high entropy sound for Google? Good
enough to go up against 2FA? Avoiding the tedium and inconveniece,
of course.

[toc] | [prev] | [next] | [standalone]


#248185

FromAsh Joubert <ash@transient.nz>
Date2022-05-14 05:10 +0200
Message-ID<EmQkh-fkZu-3@gated-at.bofh.it>
In reply to#248156
On 14/05/2022 00:42, Michael Stone wrote:
> On Fri, May 13, 2022 at 07:16:11AM +0200, tomas@tuxteam.de wrote:
>> A loong password is not "equivalent" to 2FA, that's right. Good
>> password management (of which length is but a part) is as secure
>> as 2FA.
> 
> No, it really isn't.

A good password will not protect you from password reset via a weak 
channel such as email on an insecure server.

2FA will not protect you if the second factor is weak or resolves to the 
same device. Hint: if you store your password and TOTP key in the same 
manager then you have only one factor.

2FA often smells to me like security theatre, a band-aid over a sucking 
chest wound of weak security practices, much like forced password 
expiry. Done well, in addition to good security practices, including 
strong unique random passwords, 2FA enhances security, but the cost is 
high. Note however that the cost of a compromise can be devastating.

If you use 2FA, you must include it in your disaster recovery plans. 
Imagine all your on-site devices including your phone are destroyed. Now 
recover.

Kind regards,

-- 
Ash Joubert <ash@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [next] | [standalone]


#248192

From<tomas@tuxteam.de>
Date2022-05-14 07:30 +0200
Message-ID<EmSvL-fmfs-1@gated-at.bofh.it>
In reply to#248185

[Multipart message — attachments visible in raw view] — view raw

On Sat, May 14, 2022 at 03:05:11PM +1200, Ash Joubert wrote:
> On 14/05/2022 00:42, Michael Stone wrote:
> > On Fri, May 13, 2022 at 07:16:11AM +0200, tomas@tuxteam.de wrote:
> > > A loong password is not "equivalent" to 2FA, that's right. Good
> > > password management (of which length is but a part) is as secure
> > > as 2FA.
> > 
> > No, it really isn't.
> 
> A good password will not protect you from password reset via a weak channel
> such as email on an insecure server.
> 
> 2FA will not protect you if the second factor is weak or resolves to the
> same device. Hint: if you store your password and TOTP key in the same
> manager then you have only one factor.

Not to speak of SIM spoofing or social engineering of your mobile phone
provider (yes, it has been observed in the wild). There goes your SMS
second factor.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#248277

FromCelejar <celejar@gmail.com>
Date2022-05-16 15:20 +0200
Message-ID<EnINH-fR36-1@gated-at.bofh.it>
In reply to#248192
On Sat, 14 May 2022 07:25:36 +0200
<tomas@tuxteam.de> wrote:

> On Sat, May 14, 2022 at 03:05:11PM +1200, Ash Joubert wrote:
> > On 14/05/2022 00:42, Michael Stone wrote:
> > > On Fri, May 13, 2022 at 07:16:11AM +0200, tomas@tuxteam.de wrote:
> > > > A loong password is not "equivalent" to 2FA, that's right. Good
> > > > password management (of which length is but a part) is as secure
> > > > as 2FA.
> > > 
> > > No, it really isn't.
> > 
> > A good password will not protect you from password reset via a weak channel
> > such as email on an insecure server.
> > 
> > 2FA will not protect you if the second factor is weak or resolves to the
> > same device. Hint: if you store your password and TOTP key in the same
> > manager then you have only one factor.
> 
> Not to speak of SIM spoofing or social engineering of your mobile phone
> provider (yes, it has been observed in the wild). There goes your SMS
> second factor.

Once again, it is well understood (although, bafflingly, often not by
those who should care, such as financial institutions) that SMS is a
terrible choice for 2FA. Hardware tokens, or at least authenticator
apps, are far better. (Although as others have pointed out in this
thread, if your auth app is stored together with your password, that
can eliminate some (but not all) of the benefits of 2FA.)

-- 
Celejar

[toc] | [prev] | [next] | [standalone]


#248276

FromCelejar <celejar@gmail.com>
Date2022-05-16 15:20 +0200
Message-ID<EnINH-fR36-3@gated-at.bofh.it>
In reply to#248185
On Sat, 14 May 2022 15:05:11 +1200
Ash Joubert <ash@transient.nz> wrote:

> On 14/05/2022 00:42, Michael Stone wrote:
> > On Fri, May 13, 2022 at 07:16:11AM +0200, tomas@tuxteam.de wrote:
> >> A loong password is not "equivalent" to 2FA, that's right. Good
> >> password management (of which length is but a part) is as secure
> >> as 2FA.
> > 
> > No, it really isn't.
> 
> A good password will not protect you from password reset via a weak 
> channel such as email on an insecure server.
> 
> 2FA will not protect you if the second factor is weak or resolves to the 
> same device. Hint: if you store your password and TOTP key in the same 
> manager then you have only one factor.

But as you concede below, this is an argument against poorly
implemented 2FA, not against well-implemented 2FA.

> 2FA often smells to me like security theatre, a band-aid over a sucking 
> chest wound of weak security practices, much like forced password 
> expiry. Done well, in addition to good security practices, including 
> strong unique random passwords, 2FA enhances security, but the cost is 
> high. Note however that the cost of a compromise can be devastating.

Is the cost really that high? U2F hardware keys are readily available
for as little as $15 USD (perhaps less - I just took a very quick look
on Amazon), and they can secure all your accounts (that support U2F
2FA).

> If you use 2FA, you must include it in your disaster recovery plans. 
> Imagine all your on-site devices including your phone are destroyed. Now 
> recover.

A very good point. For that, well-implemented 2FA systems typically
encourage the printing out / saving of a handful of OTP passcodes
(which you should backup / print out and save offsite). But of course,
the same is true for passwords as well (assuming you're using (as you
should) long, random ones that are difficult or impossible to remember).

But I agree that it's complicated:

https://dmitryfrank.com/articles/backup_u2f_token

-- 
Celejar

[toc] | [prev] | [next] | [standalone]


#248184

FromAsh Joubert <ash@transient.nz>
Date2022-05-14 04:50 +0200
Message-ID<EmQ0V-fkE6-3@gated-at.bofh.it>
In reply to#248143
On 13/05/2022 12:23, Nicholas Geovanis wrote:
> That's the value added in exchange for Ash's "massive pain in the arse".
> Just making the 1st factor be
> a loong password is not equivalent to 2FA in any way. Machine reaching back
> to you is the difference.

There are attacks that 2FA can defeat, especially things like password 
reset via compromised email server, but in general, two weak factors are 
not a match for a strong unique random password. In particular, it is 
not uncommon for sms/email/totp second factor to resolve to exactly the 
same device as the first factor, reducing 2FA to a single factor. 
Compromise such a user's phone and it is all over.

If Bob username "bob" chooses password "bob123" (real example, name 
changed to protect the guilty) for both his email and website login, 2FA 
via email is easily circumvented by intercepting the email. If both 
email and website had strong unique random passwords, many attacks are 
prevented. Password reset attacks via intercepted emails on the email 
server remain a threat.

It is not enough for a password to be looong. It must be strong AND 
unique AND random. Even a strong password is exploitable if one 
compromised site can be used to obtain it and access many other sites. 
It has to be random because someone else may have used the first 100 
decimal digits or pi or e or the first paragraph of your favourite book. 
Strong goes without saying.

Kind regards,

-- 
Ash Joubert <ash@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [next] | [standalone]


#248193

From<tomas@tuxteam.de>
Date2022-05-14 07:30 +0200
Message-ID<EmSvL-fmfs-3@gated-at.bofh.it>
In reply to#248184

[Multipart message — attachments visible in raw view] — view raw

On Sat, May 14, 2022 at 02:40:53PM +1200, Ash Joubert wrote:
> On 13/05/2022 12:23, Nicholas Geovanis wrote:
> > That's the value added in exchange for Ash's "massive pain in the arse".
> > Just making the 1st factor be
> > a loong password is not equivalent to 2FA in any way. Machine reaching back
> > to you is the difference.
> 
> There are attacks that 2FA can defeat, especially things like password reset
> via compromised email server, but in general, two weak factors are not a
> match for a strong unique random password [...]

[strong, unique, random]

That's it. The unique part can't be stressed enough: if your have
umpteen services out there, it's a matter of time until one of
those passwords leak (incompetent service provider, phishing,
etc.). It better be different from your other passwords.

To minimise stress, I let a tool generate my passwords (pwgen).
Important ones are 16 char (disk & backup encryption, bank account
key armor, etc.), less important ones (e.g. local login) just 8.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#248200

FromBrian <ad44@cityscape.co.uk>
Date2022-05-14 13:50 +0200
Message-ID<EmYrv-fpDB-9@gated-at.bofh.it>
In reply to#248193
On Sat 14 May 2022 at 07:23:47 +0200, tomas@tuxteam.de wrote:

> On Sat, May 14, 2022 at 02:40:53PM +1200, Ash Joubert wrote:
> > On 13/05/2022 12:23, Nicholas Geovanis wrote:
> > > That's the value added in exchange for Ash's "massive pain in the arse".
> > > Just making the 1st factor be
> > > a loong password is not equivalent to 2FA in any way. Machine reaching back
> > > to you is the difference.
> > 
> > There are attacks that 2FA can defeat, especially things like password reset
> > via compromised email server, but in general, two weak factors are not a
> > match for a strong unique random password [...]
> 
> [strong, unique, random]
> 
> That's it. The unique part can't be stressed enough: if your have
> umpteen services out there, it's a matter of time until one of
> those passwords leak (incompetent service provider, phishing,
> etc.). It better be different from your other passwords.
> 
> To minimise stress, I let a tool generate my passwords (pwgen).
> Important ones are 16 char (disk & backup encryption, bank account
> key armor, etc.), less important ones (e.g. local login) just 8.

Let me introduce you to my bank: they reduced the maximum 20 chars
to 16 and did not allow some special chars such as "!" and ".".
Mind you, I feel much more secure - 3FA is used :).

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#248206

From<tomas@tuxteam.de>
Date2022-05-14 15:30 +0200
Message-ID<En00h-fqDq-1@gated-at.bofh.it>
In reply to#248200

[Multipart message — attachments visible in raw view] — view raw

On Sat, May 14, 2022 at 12:42:28PM +0100, Brian wrote:
> On Sat 14 May 2022 at 07:23:47 +0200, tomas@tuxteam.de wrote:
> 
> > On Sat, May 14, 2022 at 02:40:53PM +1200, Ash Joubert wrote:
> > > On 13/05/2022 12:23, Nicholas Geovanis wrote:
> > > > That's the value added in exchange for Ash's "massive pain in the arse".
> > > > Just making the 1st factor be
> > > > a loong password is not equivalent to 2FA in any way. Machine reaching back
> > > > to you is the difference.
> > > 
> > > There are attacks that 2FA can defeat, especially things like password reset
> > > via compromised email server, but in general, two weak factors are not a
> > > match for a strong unique random password [...]
> > 
> > [strong, unique, random]
> > 
> > That's it. The unique part can't be stressed enough: if your have
> > umpteen services out there, it's a matter of time until one of
> > those passwords leak (incompetent service provider, phishing,
> > etc.). It better be different from your other passwords.
> > 
> > To minimise stress, I let a tool generate my passwords (pwgen).
> > Important ones are 16 char (disk & backup encryption, bank account
> > key armor, etc.), less important ones (e.g. local login) just 8.
> 
> Let me introduce you to my bank: they reduced the maximum 20 chars
> to 16 and did not allow some special chars such as "!" and ".".
> Mind you, I feel much more secure - 3FA is used :).

Three? Why not go all the way to 5FA [1]?

Cheers

[1] https://boingboing.net/2005/09/14/gillettes-5blade-raz.html
    (not linking to the original Onion because their Javascript
    doesn't want to play with me)

-- 
tomás

[toc] | [prev] | [next] | [standalone]


#248210

FromBrian <ad44@cityscape.co.uk>
Date2022-05-14 18:40 +0200
Message-ID<En2Y9-fsj3-3@gated-at.bofh.it>
In reply to#248206
On Sat 14 May 2022 at 15:21:06 +0200, tomas@tuxteam.de wrote:

> On Sat, May 14, 2022 at 12:42:28PM +0100, Brian wrote:
> > On Sat 14 May 2022 at 07:23:47 +0200, tomas@tuxteam.de wrote:

[...]
 
> > > [strong, unique, random]
> > > 
> > > That's it. The unique part can't be stressed enough: if your have
> > > umpteen services out there, it's a matter of time until one of
> > > those passwords leak (incompetent service provider, phishing,
> > > etc.). It better be different from your other passwords.
> > > 
> > > To minimise stress, I let a tool generate my passwords (pwgen).
> > > Important ones are 16 char (disk & backup encryption, bank account
> > > key armor, etc.), less important ones (e.g. local login) just 8.
> > 
> > Let me introduce you to my bank: they reduced the maximum 20 chars
> > to 16 and did not allow some special chars such as "!" and ".".
> > Mind you, I feel much more secure - 3FA is used :).
> 
> Three? Why not go all the way to 5FA [1]?
> 
> Cheers
> 
> [1] https://boingboing.net/2005/09/14/gillettes-5blade-raz.html
>     (not linking to the original Onion because their Javascript
>     doesn't want to play with me)

With MFA in play, does it really matter whether a password is strong
and unique? The only thing in this situation it now appears to do is
authorise a phone call or email.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#248214

FromBrian <ad44@cityscape.co.uk>
Date2022-05-14 20:50 +0200
Message-ID<En4ZX-ftqQ-1@gated-at.bofh.it>
In reply to#248206
On Sat 14 May 2022 at 15:21:06 +0200, tomas@tuxteam.de wrote:

> On Sat, May 14, 2022 at 12:42:28PM +0100, Brian wrote:

[...]

> > Let me introduce you to my bank: they reduced the maximum 20 chars
> > to 16 and did not allow some special chars such as "!" and ".".
> > Mind you, I feel much more secure - 3FA is used :).
> 
> Three? Why not go all the way to 5FA [1]?
> 
> Cheers
> 
> [1] https://boingboing.net/2005/09/14/gillettes-5blade-raz.html
>     (not linking to the original Onion because their Javascript
>     doesn't want to play with me)

I have just realised that PayPal does 5FA. It meets the Gillete
standard. Or should that be the MAD standard? Our capacity to
put up with sysadmin (management?) nonsense is unlimited.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#248215

From<tomas@tuxteam.de>
Date2022-05-14 21:00 +0200
Message-ID<En59E-fttZ-7@gated-at.bofh.it>
In reply to#248214

[Multipart message — attachments visible in raw view] — view raw

On Sat, May 14, 2022 at 07:43:08PM +0100, Brian wrote:
> On Sat 14 May 2022 at 15:21:06 +0200, tomas@tuxteam.de wrote:

[FIVE blades!1!!]

> I have just realised that PayPal does 5FA. It meets the Gillete
> standard. Or should that be the MAD standard? Our capacity to
> put up with sysadmin (management?) nonsense is unlimited.

:-o

Now I thought I had good satire. They do spoil everything, don't they?

Thanks for that data point.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#248217

FromBrian <ad44@cityscape.co.uk>
Date2022-05-14 21:30 +0200
Message-ID<En5CF-ftS3-1@gated-at.bofh.it>
In reply to#248215
On Sat 14 May 2022 at 20:51:14 +0200, tomas@tuxteam.de wrote:

> On Sat, May 14, 2022 at 07:43:08PM +0100, Brian wrote:
> > On Sat 14 May 2022 at 15:21:06 +0200, tomas@tuxteam.de wrote:
> 
> [FIVE blades!1!!]
> 
> > I have just realised that PayPal does 5FA. It meets the Gillete
> > standard. Or should that be the MAD standard? Our capacity to
> > put up with sysadmin (management?) nonsense is unlimited.
> 
> :-o
> 
> Now I thought I had good satire. They do spoil everything, don't they?
> 
> Thanks for that data point.

The scene is Margaret Thatcher in a restaurant with her Cabinet.

  Waitor: What do you want, madam?
  Margaret: Lamb staeks.
  Waitor: What about the vegetables?
  Margaret: They will have the same as me.

Satire is probably dead in today's Europe.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#248222

From<tomas@tuxteam.de>
Date2022-05-15 06:40 +0200
Message-ID<EnecV-fyZ4-1@gated-at.bofh.it>
In reply to#248217

[Multipart message — attachments visible in raw view] — view raw

On Sat, May 14, 2022 at 08:27:46PM +0100, Brian wrote:

[...]

> The scene is Margaret Thatcher in a restaurant with her Cabinet.
> 
>   Waitor: What do you want, madam?
>   Margaret: Lamb staeks.
>   Waitor: What about the vegetables?
>   Margaret: They will have the same as me.

:-)

> Satire is probably dead in today's Europe.

Satire's doing fine around here, thank you. As for the vegetables...
we're coping too, as well as we can :)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]


#248226

Fromgene heskett <gheskett@shentel.net>
Date2022-05-15 14:00 +0200
Message-ID<Enl4K-fCTM-7@gated-at.bofh.it>
In reply to#248222
On Sunday, 15 May 2022 00:36:41 EDT tomas@tuxteam.de wrote:
> On Sat, May 14, 2022 at 08:27:46PM +0100, Brian wrote:
> 
> [...]
> 
> > The scene is Margaret Thatcher in a restaurant with her Cabinet.
> > 
> >   Waitor: What do you want, madam?
> >   Margaret: Lamb staeks.
> >   Waitor: What about the vegetables?
> >   Margaret: They will have the same as me.
> :
> :-)
> :
> > Satire is probably dead in today's Europe.
> 
> Satire's doing fine around here, thank you. As for the vegetables...
> we're coping too, as well as we can :)
> 
> Cheers
> --
> t

So are we tolerating the vegetables, Tomas, but not too well.
Politicians and diapers need frequent changing, usually for the same 
reason.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]


Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | linux.debian.user


csiph-web