That is pretty much what I thought, and I agree that this all is good to do.
I accept that in reality professional bad-guys are the biggest risk, but
in my paranoia I am more afraid of what happens if my phone slips out of
my pocket in a public place.
Assuming the person who picks it up can unlock my phone (that may be
unrealistic) if we have eliminated passwords then they have access
to all my data stored anywhere.
On Sun, 26 Jan 2020, Brandon Long wrote:
On Sun, Jan 26, 2020 at 10:35 AM Andrew C Aitchison via mailop <
mailop@mailop.org> wrote:
Hmm.
Proving that you can read a text sent to a number you provide today
does not prove that you are the person who used the ID and password
yesterday.
So they demand you provide a new verification channel so that you can
prove your ID *next* time ?
I find these multi-factor verifications unsettling because it takes
a significant effort to convince myself that the verification does
indeed prove what it is supposed to prove and that it is safe from
man-in-the-middle. I have lost enough physical keys over the years
to worry about what happens if I lose my phone (which does not have
a finger print reader) ...
It's hard to determine what happened based on the descriptions, but
the general answer is pretty simple.
Passwords are terrible and completely broken. They are generally
poorly chosen, weak, and re-used. The result is extreme levels of
hijacking. On top of that, people forget their passwords and this
isn't something like your home electricity bill or even your
bank... how does Google know it's you?
At the one end, that makes account recovery challenging, and it
certainly seems that Google decides that losing your account is
better than giving it to someone else. There's probably extensive
arguments and concerns about how exactly the draw that line, but
that's the tension. Your Google account can contain multitudes of
personal information, granting it to the wrong person can be
crippling to the main owner. Losing access can also be terrible.
The other end of this, what do you do when someone presents the
right password to log in, is it a hijacking or not? What happens is
a risk assessment of the login, is it from the usual location?
Usual country? Usual device type? Is it from somewhere where you
see a lot of unusual logins? Does it look like some automated
software and not a normal browser? How strong is the password? How
common is the password?
The end result of that risk assessment is whether to let the user
in, or to make the login more complicated. That started with
captchas, sometimes requiring up to 5 or more of them in the
riskiest case. The next level is requiring a phone number. Better
if the phone number used was already known to Google, but really any
phone number will do because a phone number costs money to obtain,
so limiting how many accounts can use a number or how frequently,
and you have raised the cost of accessing the account. Of course,
then you need to know what all of the free or almost free phone
number services are, to not allow those to be used, as they don't
cost enough.
Of course, if there's money to be made, there's a way, so you get
people stealing entire boxes of sim cards and creating special
hardware to use them, see the pictures from this article:
https://cyberpolice.gov.ua/news/kiberpolicziya-prypynyla-diyalnist-masshtabnogo-servisu-dlya-reyestracziyi-riznyx-akauntiv-u-mesendzherax-soczmerezhax-ta-poshtovyx-servisax-8596/
This isn't about tracking, this is about keeping your data safe, and
protecting everyone else from what can be done with a hijacked
account, from sending spam to click fraud to YT abuse to bitcoin
mining on GCP.
In many respects, actually setting up 2FA on your account puts you
in a better situation. It means that access to your account is hard
to abuse, and so the risk assessment is completely different. Yes,
it means that you need to keep both the password and 2FA source
secure and available... but that's better than forcing Google to
guess at some secondary thing to verify you and choosing wrong.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
