Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mark Tinka]

On 4/20/21 01:46, b...@theworld.com wrote:


If they want to protect trillions of dollars in assets maybe they need
to toss in a few billion to help, and stop hoping some bad press for
the technical community will shame some geniuses into dreaming up
better security for them mostly for free in terms of research and
specs and acceptance but that's the hard part.

You know what the net did successfully produce, over and over? Some of
the wealthiest individuals and corporations etc in the history of
civilization. Maybe the profit margins were a little too high and now
we're paying the price, or someone is.



For the most part, services that (want to) rely on security are 
providing their own security solutions. But they are bespoke, and each 
one is designing and pushing out their own solution in their own silo. 
So users have to contend with a multitude of security ideas that each of 
the services they consume come up with. Standardization, here, would go 
a long way in fixing much of this, but what's the incentive for them to 
all work together, when "better security" is one of their selling points?


If, "magically", the Internet community came up with a solution that one 
felt is fairly standard, we've seen how well that would be adopted, a la 
DNSSEC, DANE and RPKI.


At the very least, the discussions need to be had; but not as separate 
streams. Internet folk. Mobile folk. Telco folk. Service folk.


Mark.

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mark Tinka]

On 4/19/21 16:10, Mel Beckman wrote:


Can you cite data? Or provide a rational argument other than “they are”?


https://www.businessinsider.co.za/whatsapp-scam-asking-for-money-after-number-port-2020-1
https://www.sowetanlive.co.za/news/south-africa/2020-01-06-beware-south-africans-are-falling-victim-to-cellphone-porting-scam/
https://www.news24.com/fin24/companies/financial-services/just-hang-up-consumer-group-warns-of-phone-scams-20190620

This is a country full of low-income (or blatantly unemployed) citizens.

Mark.

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mark Tinka]

On 4/19/21 15:33, Mel Beckman wrote:


Tom,

Well, yes, not everyone can afford all technology options. That’s 
life. One has to wonder how someone who needs to protect online 
accounts cannot afford a $30 hardware token (which can be shared 
across several accounts). These low-income people are not the targets 
of identity thieves, spear fishers, or data ransomers. Unlike you, I 
AM arguing against something: SMS as a 2FA token. In this case I don’t 
think we have ignored low-income users, for the same reason that home 
alarm security aren't ignoring low-income users who can’t afford their 
products. It’s certainly no reason to hobble security for the rest of us.


Hmmh, I'm not quite sure that is accurate. Low-income folk will 
certainly have a mobile service, even though they might not have enough 
to buy a security alarm once the rent is paid.


Take finance, for example, in places like East Africa, they folk are 
lucky that they don't need a bank account to either put money away or 
transact for everyday needs. In other countries that don't have this 
(mobile money), low-income folk who earn a living will have a bank 
account, and even that one will come with some kind of online access.


The issue isn't so much the product. The issue is that mobile services 
are so basic and fundamental, everybody, regardless of their financial 
position, will have one. The stats say that as of 2020, of the number of 
users around the world using mobile phones, only 46% of them are "smart".


Mark.

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[bzs]

Can I make an old f*** comment on all this?

We didn't design this network to be highly secure.

It's general enough that security can be layered on at various places.

But when you get down to it it was mostly designed to get information
flowing easy, fast, and freely. Not to lock it down or provide strong
accountability, authorization, and authentication.

Look at RFCs prior to about 1990, security's hardly considered beyond
an occasional login/password scheme or MITM packet injection.

It was designed to be very cheap to implement and deploy at least in
part because it was designed and implemented on frugal academic
budgets.

And to share those implementations or roll your own because the specs
(RFCs etc) were published free.

Then people, corporations by and large, came along and realized they
could use the net to make many zillions of dollars if only it were
secure.

IF...ONLY!

Did anyone promise them that?

And no one ever really figured out how to make it secure beyond some
superficial attempts like adopting login/passwords, wire encryption
(SSL etc.), 2FA, MITM avoidance, etc. none of which were really part
of some well thought out, engineered scheme. Just some new doo-dad to
toss on hoping that maybe this will be good enough. It wasn't.

Now, when their sites are compromised, when they lose gazillions of
dollars to ransomware, when 100M records walk out the door, whatever,
they put on the big sad face and imply they were let down and *they*,
someone else, some gearheads, need to try harder. They're terribly,
terribly disappointed.

What a great con job, try to shame someone else into solving your
problems for you basically for free.

If they want to protect trillions of dollars in assets maybe they need
to toss in a few billion to help, and stop hoping some bad press for
the technical community will shame some geniuses into dreaming up
better security for them mostly for free in terms of research and
specs and acceptance but that's the hard part.

You know what the net did successfully produce, over and over? Some of
the wealthiest individuals and corporations etc in the history of
civilization. Maybe the profit margins were a little too high and now
we're paying the price, or someone is.

It's like my aged, now gone, adviser who'd worked in software going
back to the 50s said about the Y2K problem at that time: It's not that
we couldn't anticipate Y2K problems. It's that we never dreamed the
cheap bastards would still be running the same exact software without
any updates or review for forty years!

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: Carriers need to independently verify LOAs

[Matt Erculiani]

Nothing is stopping the perpetrator of a BGP hijack as a result of a forged
or otherwise illegitimate LOA from facing civil litigation as a result of
revenue loss or other harm done.

This thread and others like it highlight that there is absolutely some
negligence here and could very well find itself in an evidence pile at some
point in the future.

So there IS liability, but the lack of solid precedent means that the bean
counters can't assign a dollar amount to the risk associated with blindly
accepting LOAs, and therefore it might as well not exist.

Someday, somebody will have the pants sued off them because they let their
new customer hijack the hell out of a government entity, bank, oil company,
etc. and we'll start to see better processes.

-Matt

On Mon, Apr 19, 2021 at 11:59 AM Sean Donelan  wrote:

>
> On Mon, 19 Apr 2021, Peter Beckman wrote:
> > And while it would be nice if everyone "independently verified every LOA"
> > the cost of doing so in the far-too-many edge cases is business-endingly
> > high.
>
> If carriers faced legal liability, with appropriate incentatives, I'd bet
> they would solve the verification problem -- quickly, cheaply.
>
> No liability -- no reason to solve the problem.
>
>

-- 
Matt Erculiani
ERCUL-ARIN

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mark Tinka]

On 4/19/21 17:48, William Herrin wrote:


Convenience is the most important factor in any security scheme.


But often not at the top of the implementation priority list.



Hint: carrying around a separate hardware fob for each important
Internet-based service is a non-starter. Users might do it for their
one or two most important services but yours isn't one of them.


You make my point for me.

Mark.

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[John Levine]

It appears that William Herrin  said:
>> If a key fob can be sent to them - preferably for free - that would help.
>
>Hint: carrying around a separate hardware fob for each important
>Internet-based service is a non-starter. Users might do it for their
>one or two most important services but yours isn't one of them.

You think?

https://obvious.services.net/2013/07/better-have-big-pockets-if-you-want.html

R's,
John

Re: Carriers need to independently verify LOAs

[Sean Donelan]

On Mon, 19 Apr 2021, Peter Beckman wrote:

And while it would be nice if everyone "independently verified every LOA"
the cost of doing so in the far-too-many edge cases is business-endingly
high.


If carriers faced legal liability, with appropriate incentatives, I'd bet 
they would solve the verification problem -- quickly, cheaply.


No liability -- no reason to solve the problem.

Re: Carriers need to independently verify LOAs

[Peter Beckman]

US/Canada (ideally all of NANPA) Carriers need to standardize the porting
process.

Right now, I have an anecdotal database for each carrier which requires a
slightly different process. For Verizon Wireless, you have to generate a
Port Out PIN for each number, which expire after 7 days. Excellent! But
only if there isn't a Freeze on the number.

For another, you have to call to get your account number and PIN, as you
cannot get it without calling the carrier, and it is different.

For some carriers, the address on file isn't the End-user's address, which
causes regular and constant rejections. Must request a CSR.

For Google Voice, pay $3 first, then unlock.

For $random_carrier, provide anything and they release the number, without
notice to anyone.

Many carriers do not require an LOA to Port, usually where porting is
automated, and the automated carriers require a PIN and Account Number and
service/billing address to ensure numbers don't get "accidentally" ported,
either due to fraud or a typo.

And while it would be nice if everyone "independently verified every LOA"
the cost of doing so in the far-too-many edge cases is business-endingly
high.

It is the lack of a standard that all carriers share that cause these
problems.

In Europe, you generate a UUID, give the UUID and number to Port to the new
carrier, and it's done. If every NANPA carrier allowed the End-User to
generate a UUID for Porting Out that expired after 7 days, all of this
inconsistency would go away. Mostly. Probably.

Beckman

On Mon, 19 Apr 2021, Joe Greco wrote:


On Mon, Apr 19, 2021 at 01:20:22PM -0400, Sean Donelan wrote:

On Sat, 17 Apr 2021, Eric Kuhnke wrote:

Anecdotal: With the prior consent of the DID holders, I have successfully
ported peoples' numbers using nothing more than a JPG scan of a signature
that looks like an illegible 150 dpi black and white blob, pasted in an
image editor on top of a generic looking 'phone bill'.


All carriers should independently verify any LOAs received for account
changes.

Documents received from third-parties, without independently verifying
with the customer of record, using the carriers own records, are just junk
papers.

Almost no carriers verify LOAs by contacting the customer of record.
Worse, they call the phone number on the letterhead provide by the scammer
for "verification."


Presumably we're kinda talking about a problem parallel to the
Internet ASN/IP space LOA problem here.

It would be awesome if there were a nice easy way to identify the
responsible parties, so you could figure out WHOIS the appropriate
party to contact.  If you've ever tried Googling a company with a
hundred thousand employees, calling their contact number on the Web,
and getting through to anybody who knows anything at all about IT,
well, you can spend a day at it and still have gotten nowhere.

It's too bad that this information is so frequently redacted for
privacy.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov



---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: Carriers need to independently verify LOAs

[Joe Greco]

On Mon, Apr 19, 2021 at 01:20:22PM -0400, Sean Donelan wrote:
> On Sat, 17 Apr 2021, Eric Kuhnke wrote:
> >Anecdotal: With the prior consent of the DID holders, I have successfully
> >ported peoples' numbers using nothing more than a JPG scan of a signature
> >that looks like an illegible 150 dpi black and white blob, pasted in an
> >image editor on top of a generic looking 'phone bill'.
> 
> All carriers should independently verify any LOAs received for account 
> changes.
> 
> Documents received from third-parties, without independently verifying 
> with the customer of record, using the carriers own records, are just junk 
> papers.
> 
> Almost no carriers verify LOAs by contacting the customer of record. 
> Worse, they call the phone number on the letterhead provide by the scammer 
> for "verification."

Presumably we're kinda talking about a problem parallel to the
Internet ASN/IP space LOA problem here.

It would be awesome if there were a nice easy way to identify the
responsible parties, so you could figure out WHOIS the appropriate
party to contact.  If you've ever tried Googling a company with a
hundred thousand employees, calling their contact number on the Web,
and getting through to anybody who knows anything at all about IT,
well, you can spend a day at it and still have gotten nowhere.

It's too bad that this information is so frequently redacted for
privacy.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Carriers need to independently verify LOAs

[Sean Donelan]

On Sat, 17 Apr 2021, Eric Kuhnke wrote:

Anecdotal: With the prior consent of the DID holders, I have successfully
ported peoples' numbers using nothing more than a JPG scan of a signature
that looks like an illegible 150 dpi black and white blob, pasted in an
image editor on top of a generic looking 'phone bill'.


All carriers should independently verify any LOAs received for account 
changes.


Documents received from third-parties, without independently verifying 
with the customer of record, using the carriers own records, are just junk 
papers.


Almost no carriers verify LOAs by contacting the customer of record. 
Worse, they call the phone number on the letterhead provide by the scammer 
for "verification."


The U.S. Postal Service used to let random people change mail forwarding 
orders, without verifying with the original and new addresses. As you can 
guess, there were lots of fake forwarding orders and criminal activity. 
After USPS begin verifying mail forwarding orders by sending a letter to 
the ORIGINAL address and NEW address, mail forwarding fraud declined.  Not 
zero, but declined.

Re: Anyone from Proof Point or Comcast on this list?

[Suresh Ramasubramanian]

comcast.com is their corporate mail domain

comcast.net is their customer domain

Both have entirely different mx hosts and won’t relay mail for each other.

--srs

From: NANOG  on behalf of Matt 
Hoppes 
Sent: Monday, April 19, 2021 10:06:00 PM
To: North American Network Operators' Group 
Subject: Anyone from Proof Point or Comcast on this list?

It seems we are having trouble sending e-mail to some Comcast customers
and getting a relaying denied message, even though the mail should be
being accepted, not relayed.

Below is a copy of a transcript.  Could someone from Proof Point or
Comcast e-mail please contact me to resolve this?


[root@account ~]# dig mx comcast.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> mx comcast.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32690
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;comcast.com.   IN  MX

;; ANSWER SECTION:
comcast.com.9   IN  MX  5 
mxb-00143702.gslb.pphosted.com.
comcast.com.9   IN  MX  5 
mxa-00143702.gslb.pphosted.com.

;; Query time: 0 msec
;; SERVER: 172.16.0.21#53(172.16.0.21)
;; WHEN: Mon Apr 19 12:33:57 EDT 2021
;; MSG SIZE  rcvd: 112

[root@account ~]# telnet mxb-00143702.gslb.pphosted.com 25
Trying 148.163.141.77...
Connected to mxb-00143702.gslb.pphosted.com.
Escape character is '^]'.
220 mx0b-00143702.pphosted.com ESMTP mfa-m0184889
helo rivervalleyinternet.net
250 mx0b-00143702.pphosted.com Hello [192.81.87.236], pleased to meet you
mail from:i...@rivervalleyinternet.net
250 2.1.0 Sender ok
rcpt to:dr[redacted]@comcast.net
550 5.7.1 Relaying denied

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[John Adams]

The goal of U2F is one key fob that works on many services. Implementation is 
pretty simple and the hardware is inexpensive.


Sent from my iPhone

> On Apr 19, 2021, at 08:51, William Herrin  wrote:
> 
> On Mon, Apr 19, 2021 at 5:54 AM Mark Tinka  wrote:
>> It's all about convenience, and how much they can get
>> done without speaking to human.
> 
> Hi Mark,
> 
> Convenience is the most important factor in any security scheme. The
> user nearly always has a choice, even if the choice is as
> rough-grained as "switch to a different company." If your process is
> too onerous (the user's notion of onerous) then it simply won't be
> used. An effective security scheme is the strongest which can be built
> within that boundary.
> 
>> If a key fob can be sent to them - preferably for free - that would help.
> 
> Hint: carrying around a separate hardware fob for each important
> Internet-based service is a non-starter. Users might do it for their
> one or two most important services but yours isn't one of them.
> 
> Regards,
> Bill Herrin
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: Anyone from Proof Point or Comcast on this list?

[Matthew V]

On 2021-04-19 12:36 p.m., Matt Hoppes wrote:
It seems we are having trouble sending e-mail to some Comcast 
customers and getting a relaying denied message, even though the mail 
should be being accepted, not relayed.


Below is a copy of a transcript.  Could someone from Proof Point or 
Comcast e-mail please contact me to resolve this?



Have you tried the Proofpoint reputation and remediation portal?

https://ipcheck.proofpoint.com/

~

Matt

Re: Anyone from Proof Point or Comcast on this list?

[Mike Hammett]

https://list.mailop.org/listinfo/mailop 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Matt Hoppes"  
To: "North American Network Operators' Group"  
Sent: Monday, April 19, 2021 11:36:00 AM 
Subject: Anyone from Proof Point or Comcast on this list? 

It seems we are having trouble sending e-mail to some Comcast customers 
and getting a relaying denied message, even though the mail should be 
being accepted, not relayed. 

Below is a copy of a transcript. Could someone from Proof Point or 
Comcast e-mail please contact me to resolve this? 


[root@account ~]# dig mx comcast.com 

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> mx comcast.com 
;; global options: +cmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32690 
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 

;; OPT PSEUDOSECTION: 
; EDNS: version: 0, flags:; udp: 4096 
;; QUESTION SECTION: 
;comcast.com. IN MX 

;; ANSWER SECTION: 
comcast.com. 9 IN MX 5 mxb-00143702.gslb.pphosted.com. 
comcast.com. 9 IN MX 5 mxa-00143702.gslb.pphosted.com. 

;; Query time: 0 msec 
;; SERVER: 172.16.0.21#53(172.16.0.21) 
;; WHEN: Mon Apr 19 12:33:57 EDT 2021 
;; MSG SIZE rcvd: 112 

[root@account ~]# telnet mxb-00143702.gslb.pphosted.com 25 
Trying 148.163.141.77... 
Connected to mxb-00143702.gslb.pphosted.com. 
Escape character is '^]'. 
220 mx0b-00143702.pphosted.com ESMTP mfa-m0184889 
helo rivervalleyinternet.net 
250 mx0b-00143702.pphosted.com Hello [192.81.87.236], pleased to meet you 
mail from:i...@rivervalleyinternet.net 
250 2.1.0 Sender ok 
rcpt to:dr[redacted]@comcast.net 
550 5.7.1 Relaying denied 

Anyone from Proof Point or Comcast on this list?

[Matt Hoppes]

It seems we are having trouble sending e-mail to some Comcast customers 
and getting a relaying denied message, even though the mail should be 
being accepted, not relayed.


Below is a copy of a transcript.  Could someone from Proof Point or 
Comcast e-mail please contact me to resolve this?



[root@account ~]# dig mx comcast.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> mx comcast.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32690
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;comcast.com.   IN  MX

;; ANSWER SECTION:
comcast.com.9   IN  MX  5 
mxb-00143702.gslb.pphosted.com.
comcast.com.9   IN  MX  5 
mxa-00143702.gslb.pphosted.com.

;; Query time: 0 msec
;; SERVER: 172.16.0.21#53(172.16.0.21)
;; WHEN: Mon Apr 19 12:33:57 EDT 2021
;; MSG SIZE  rcvd: 112

[root@account ~]# telnet mxb-00143702.gslb.pphosted.com 25
Trying 148.163.141.77...
Connected to mxb-00143702.gslb.pphosted.com.
Escape character is '^]'.
220 mx0b-00143702.pphosted.com ESMTP mfa-m0184889
helo rivervalleyinternet.net
250 mx0b-00143702.pphosted.com Hello [192.81.87.236], pleased to meet you
mail from:i...@rivervalleyinternet.net
250 2.1.0 Sender ok
rcpt to:dr[redacted]@comcast.net
550 5.7.1 Relaying denied

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[William Herrin]

On Mon, Apr 19, 2021 at 5:54 AM Mark Tinka  wrote:
> It's all about convenience, and how much they can get
> done without speaking to human.

Hi Mark,

Convenience is the most important factor in any security scheme. The
user nearly always has a choice, even if the choice is as
rough-grained as "switch to a different company." If your process is
too onerous (the user's notion of onerous) then it simply won't be
used. An effective security scheme is the strongest which can be built
within that boundary.

> If a key fob can be sent to them - preferably for free - that would help.

Hint: carrying around a separate hardware fob for each important
Internet-based service is a non-starter. Users might do it for their
one or two most important services but yours isn't one of them.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Tom Beecher]

>
> Can you point out the specific data you think supports your claim?
>

I can, but I'm not going to, because that's not what this side discussion
has been based on.

You said :

These low-income people are not the targets of identity thieves, spear
> fishers, or data ransomers.


I just showed you data that shows they are, but now are trying to move the
goalposts with new quantifiers. I think this discussion has run its course
for me. Take care.

On Mon, Apr 19, 2021 at 10:45 AM Mel Beckman  wrote:

> I don’t see any data showing that poor people are *targets* of Account
> access attacks. Can you point out the specific data you think supports your
> claim?
>
> -mel via cell
>
> On Apr 19, 2021, at 7:33 AM, Tom Beecher  wrote:
>
> 
>
> https://www.ftc.gov/system/files/documents/reports/consumer-sentinel-network-data-book-2020/csn_annual_data_book_2020.pdf
>
> https://www.bjs.gov/content/pub/pdf/vit18.pdf
>
>
>
>
> On Mon, Apr 19, 2021 at 10:10 AM Mel Beckman  wrote:
>
>> Can you cite data? Or provide a rational argument other than “they are”?
>>
>> -mel via cell
>>
>> On Apr 19, 2021, at 7:01 AM, Tom Beecher  wrote:
>>
>> 
>>
>>> These low-income people are not the targets of identity thieves, spear
>>> fishers, or data ransomers.
>>>
>>
>> This is patently false. Low-income / disabled / minority / non-english
>> speakers are absolutely targets of scams like those, and in
>> significant numbers.
>>
>>
>>
>> On Mon, Apr 19, 2021 at 9:33 AM Mel Beckman  wrote:
>>
>>> Tom,
>>>
>>> Well, yes, not everyone can afford all technology options. That’s life.
>>> One has to wonder how someone who needs to protect online accounts cannot
>>> afford a $30 hardware token (which can be shared across several accounts).
>>> These low-income people are not the targets of identity thieves, spear
>>> fishers, or data ransomers. Unlike you, I AM arguing against something: SMS
>>> as a 2FA token. In this case I don’t think we have ignored low-income
>>> users, for the same reason that home alarm security aren't ignoring
>>> low-income users who can’t afford their products. It’s certainly no reason
>>> to hobble security for the rest of us.
>>>
>>>  -mel
>>>
>>>
>>> On Apr 19, 2021, at 6:07 AM, Tom Beecher  wrote:
>>>
>>> HW tokens are great, sure.
>>>
>>> Except there is a lot of overlap in the Venn diagram between those who
>>> still use feature phones and those that spending $30 on said hardware token
>>> is financially obtrusive. ( Not to mention that every hardware token I can
>>> remember looking at requires an app to set themselves up in the first
>>> place, and if this is for the people who can't install apps, that's an
>>> interesting circular dependency. )
>>>
>>> I'm not arguing for or against anything here honestly. I'm just pointing
>>> out that we ( as in the technical community we ) have a tendency to put
>>> forward solutions that completely ignore what might be reasonably feasible
>>> for those of lower income , or parts of the world not as technologically
>>> developed as we might be in ourselves, and we should try to shrink that gap
>>> whenever possible, not make it worse.
>>>
>>> On Mon, Apr 19, 2021 at 8:47 AM Mel Beckman  wrote:
>>>
 Then they can buy a hardware token. Using SMS is provably insecure, and
 for people being spear-phished (a much more common occurrence now that so
 much net worth data has been breached), a huge risk

  -mel

 On Apr 19, 2021, at 5:44 AM, Tom Beecher  wrote:

 

> As far as I know, authenticators on cell phone apps don’t require the
> Internet. For example, the Google Authenticator mobile app doesn't require
> any Internet or cellular connection
>

 Lots of people still use feature phones that are not capable of running
 applications such as this.

 On Sun, Apr 18, 2021 at 9:05 AM Mel Beckman  wrote:

> As far as I know, authenticators on cell phone apps don’t require the
> Internet. For example, the Google Authenticator mobile app doesn't require
> any Internet or cellular connection. The authenticated system generates a
> secret key - a unique 16 or 32 character alphanumeric code. This key is
> scanned by GA or can be entered manually and as a result, both the
> authenticated system and GA know the same secret key, and can compute the
> time-based 2nd factor OTP just as hardware tokens do.
>
> There are two algorithms: HOTP and TOTP. The main difference is in OTP
> expiration time: with HOTP, the OTP is valid until it hasn’t been used;
> TOTP times out after some specified interval - usually 30 or 60 seconds.
> For TOTP, the system time must be synced, otherwise the generated OTPs 
> will
> be wrong. But you can get accurate enough clock time without the Internet,
> either manually using some radio source such as WWV, or by GPS or cellular
> system synchronization.
>
>  -mel
>
> > On Apr 18, 2021, at 5:46 AM, Mark 

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mel Beckman]

I don’t see any data showing that poor people are targets of Account access 
attacks. Can you point out the specific data you think supports your claim?

-mel via cell

On Apr 19, 2021, at 7:33 AM, Tom Beecher  wrote:


https://www.ftc.gov/system/files/documents/reports/consumer-sentinel-network-data-book-2020/csn_annual_data_book_2020.pdf

https://www.bjs.gov/content/pub/pdf/vit18.pdf




On Mon, Apr 19, 2021 at 10:10 AM Mel Beckman 
mailto:m...@beckman.org>> wrote:
Can you cite data? Or provide a rational argument other than “they are”?

-mel via cell

On Apr 19, 2021, at 7:01 AM, Tom Beecher  wrote:


These low-income people are not the targets of identity thieves, spear fishers, 
or data ransomers.

This is patently false. Low-income / disabled / minority / non-english speakers 
are absolutely targets of scams like those, and in significant numbers.



On Mon, Apr 19, 2021 at 9:33 AM Mel Beckman 
mailto:m...@beckman.org>> wrote:
Tom,

Well, yes, not everyone can afford all technology options. That’s life. One has 
to wonder how someone who needs to protect online accounts cannot afford a $30 
hardware token (which can be shared across several accounts). These low-income 
people are not the targets of identity thieves, spear fishers, or data 
ransomers. Unlike you, I AM arguing against something: SMS as a 2FA token. In 
this case I don’t think we have ignored low-income users, for the same reason 
that home alarm security aren't ignoring low-income users who can’t afford 
their products. It’s certainly no reason to hobble security for the rest of us.

 -mel


On Apr 19, 2021, at 6:07 AM, Tom Beecher 
mailto:beec...@beecher.cc>> wrote:

HW tokens are great, sure.

Except there is a lot of overlap in the Venn diagram between those who still 
use feature phones and those that spending $30 on said hardware token is 
financially obtrusive. ( Not to mention that every hardware token I can 
remember looking at requires an app to set themselves up in the first place, 
and if this is for the people who can't install apps, that's an interesting 
circular dependency. )

I'm not arguing for or against anything here honestly. I'm just pointing out 
that we ( as in the technical community we ) have a tendency to put forward 
solutions that completely ignore what might be reasonably feasible for those of 
lower income , or parts of the world not as technologically developed as we 
might be in ourselves, and we should try to shrink that gap whenever possible, 
not make it worse.

On Mon, Apr 19, 2021 at 8:47 AM Mel Beckman 
mailto:m...@beckman.org>> wrote:
Then they can buy a hardware token. Using SMS is provably insecure, and for 
people being spear-phished (a much more common occurrence now that so much net 
worth data has been breached), a huge risk

 -mel

On Apr 19, 2021, at 5:44 AM, Tom Beecher 
mailto:beec...@beecher.cc>> wrote:


As far as I know, authenticators on cell phone apps don’t require the Internet. 
For example, the Google Authenticator mobile app doesn't require any Internet 
or cellular connection

Lots of people still use feature phones that are not capable of running 
applications such as this.

On Sun, Apr 18, 2021 at 9:05 AM Mel Beckman 
mailto:m...@beckman.org>> wrote:
As far as I know, authenticators on cell phone apps don’t require the Internet. 
For example, the Google Authenticator mobile app doesn't require any Internet 
or cellular connection. The authenticated system generates a secret key - a 
unique 16 or 32 character alphanumeric code. This key is scanned by GA or can 
be entered manually and as a result, both the authenticated system and GA know 
the same secret key, and can compute the time-based 2nd factor OTP just as 
hardware tokens do.

There are two algorithms: HOTP and TOTP. The main difference is in OTP 
expiration time: with HOTP, the OTP is valid until it hasn’t been used;  TOTP 
times out after some specified interval - usually 30 or 60 seconds. For TOTP, 
the system time must be synced, otherwise the generated OTPs will be wrong. But 
you can get accurate enough clock time without the Internet, either manually 
using some radio source such as WWV, or by GPS or cellular system 
synchronization.

 -mel

> On Apr 18, 2021, at 5:46 AM, Mark Tinka 
> mailto:mark@tinka.africa>> wrote:
>
> 
>
>> On 4/18/21 05:18, Mel Beckman wrote:
>>
>> No, every SMS 2FA should be prohibited by regulatory certifications. The 
>> telcos had years to secure SMS. They did nothing. The plethora of 
>> well-secured commercial 2FA authentication tokens, many of them free, should 
>> be a mandatory replacement for 2FA in every security governance regime, such 
>> as PCI, financial account access, government web portals, etc.
>
> While I agree that SMS is insecure at the moment, I think there still needs 
> to be a mechanism that does not rely on the presence of an Internet 
> connection. One may not be able to have access to the Internet for a number 
> of reasons (traveling, coverage, outage, 

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Tom Beecher]

https://www.ftc.gov/system/files/documents/reports/consumer-sentinel-network-data-book-2020/csn_annual_data_book_2020.pdf

https://www.bjs.gov/content/pub/pdf/vit18.pdf




On Mon, Apr 19, 2021 at 10:10 AM Mel Beckman  wrote:

> Can you cite data? Or provide a rational argument other than “they are”?
>
> -mel via cell
>
> On Apr 19, 2021, at 7:01 AM, Tom Beecher  wrote:
>
> 
>
>> These low-income people are not the targets of identity thieves, spear
>> fishers, or data ransomers.
>>
>
> This is patently false. Low-income / disabled / minority / non-english
> speakers are absolutely targets of scams like those, and in
> significant numbers.
>
>
>
> On Mon, Apr 19, 2021 at 9:33 AM Mel Beckman  wrote:
>
>> Tom,
>>
>> Well, yes, not everyone can afford all technology options. That’s life.
>> One has to wonder how someone who needs to protect online accounts cannot
>> afford a $30 hardware token (which can be shared across several accounts).
>> These low-income people are not the targets of identity thieves, spear
>> fishers, or data ransomers. Unlike you, I AM arguing against something: SMS
>> as a 2FA token. In this case I don’t think we have ignored low-income
>> users, for the same reason that home alarm security aren't ignoring
>> low-income users who can’t afford their products. It’s certainly no reason
>> to hobble security for the rest of us.
>>
>>  -mel
>>
>>
>> On Apr 19, 2021, at 6:07 AM, Tom Beecher  wrote:
>>
>> HW tokens are great, sure.
>>
>> Except there is a lot of overlap in the Venn diagram between those who
>> still use feature phones and those that spending $30 on said hardware token
>> is financially obtrusive. ( Not to mention that every hardware token I can
>> remember looking at requires an app to set themselves up in the first
>> place, and if this is for the people who can't install apps, that's an
>> interesting circular dependency. )
>>
>> I'm not arguing for or against anything here honestly. I'm just pointing
>> out that we ( as in the technical community we ) have a tendency to put
>> forward solutions that completely ignore what might be reasonably feasible
>> for those of lower income , or parts of the world not as technologically
>> developed as we might be in ourselves, and we should try to shrink that gap
>> whenever possible, not make it worse.
>>
>> On Mon, Apr 19, 2021 at 8:47 AM Mel Beckman  wrote:
>>
>>> Then they can buy a hardware token. Using SMS is provably insecure, and
>>> for people being spear-phished (a much more common occurrence now that so
>>> much net worth data has been breached), a huge risk
>>>
>>>  -mel
>>>
>>> On Apr 19, 2021, at 5:44 AM, Tom Beecher  wrote:
>>>
>>> 
>>>
 As far as I know, authenticators on cell phone apps don’t require the
 Internet. For example, the Google Authenticator mobile app doesn't require
 any Internet or cellular connection

>>>
>>> Lots of people still use feature phones that are not capable of running
>>> applications such as this.
>>>
>>> On Sun, Apr 18, 2021 at 9:05 AM Mel Beckman  wrote:
>>>
 As far as I know, authenticators on cell phone apps don’t require the
 Internet. For example, the Google Authenticator mobile app doesn't require
 any Internet or cellular connection. The authenticated system generates a
 secret key - a unique 16 or 32 character alphanumeric code. This key is
 scanned by GA or can be entered manually and as a result, both the
 authenticated system and GA know the same secret key, and can compute the
 time-based 2nd factor OTP just as hardware tokens do.

 There are two algorithms: HOTP and TOTP. The main difference is in OTP
 expiration time: with HOTP, the OTP is valid until it hasn’t been used;
 TOTP times out after some specified interval - usually 30 or 60 seconds.
 For TOTP, the system time must be synced, otherwise the generated OTPs will
 be wrong. But you can get accurate enough clock time without the Internet,
 either manually using some radio source such as WWV, or by GPS or cellular
 system synchronization.

  -mel

 > On Apr 18, 2021, at 5:46 AM, Mark Tinka  wrote:
 >
 > 
 >
 >> On 4/18/21 05:18, Mel Beckman wrote:
 >>
 >> No, every SMS 2FA should be prohibited by regulatory certifications.
 The telcos had years to secure SMS. They did nothing. The plethora of
 well-secured commercial 2FA authentication tokens, many of them free,
 should be a mandatory replacement for 2FA in every security governance
 regime, such as PCI, financial account access, government web portals, etc.
 >
 > While I agree that SMS is insecure at the moment, I think there still
 needs to be a mechanism that does not rely on the presence of an Internet
 connection. One may not be able to have access to the Internet for a number
 of reasons (traveling, coverage, outage, device, money, e.t.c.), and a
 fallback needs to be available to authenticate.
 >
 

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mel Beckman]

Can you cite data? Or provide a rational argument other than “they are”?

-mel via cell

On Apr 19, 2021, at 7:01 AM, Tom Beecher  wrote:


These low-income people are not the targets of identity thieves, spear fishers, 
or data ransomers.

This is patently false. Low-income / disabled / minority / non-english speakers 
are absolutely targets of scams like those, and in significant numbers.



On Mon, Apr 19, 2021 at 9:33 AM Mel Beckman 
mailto:m...@beckman.org>> wrote:
Tom,

Well, yes, not everyone can afford all technology options. That’s life. One has 
to wonder how someone who needs to protect online accounts cannot afford a $30 
hardware token (which can be shared across several accounts). These low-income 
people are not the targets of identity thieves, spear fishers, or data 
ransomers. Unlike you, I AM arguing against something: SMS as a 2FA token. In 
this case I don’t think we have ignored low-income users, for the same reason 
that home alarm security aren't ignoring low-income users who can’t afford 
their products. It’s certainly no reason to hobble security for the rest of us.

 -mel


On Apr 19, 2021, at 6:07 AM, Tom Beecher 
mailto:beec...@beecher.cc>> wrote:

HW tokens are great, sure.

Except there is a lot of overlap in the Venn diagram between those who still 
use feature phones and those that spending $30 on said hardware token is 
financially obtrusive. ( Not to mention that every hardware token I can 
remember looking at requires an app to set themselves up in the first place, 
and if this is for the people who can't install apps, that's an interesting 
circular dependency. )

I'm not arguing for or against anything here honestly. I'm just pointing out 
that we ( as in the technical community we ) have a tendency to put forward 
solutions that completely ignore what might be reasonably feasible for those of 
lower income , or parts of the world not as technologically developed as we 
might be in ourselves, and we should try to shrink that gap whenever possible, 
not make it worse.

On Mon, Apr 19, 2021 at 8:47 AM Mel Beckman 
mailto:m...@beckman.org>> wrote:
Then they can buy a hardware token. Using SMS is provably insecure, and for 
people being spear-phished (a much more common occurrence now that so much net 
worth data has been breached), a huge risk

 -mel

On Apr 19, 2021, at 5:44 AM, Tom Beecher 
mailto:beec...@beecher.cc>> wrote:


As far as I know, authenticators on cell phone apps don’t require the Internet. 
For example, the Google Authenticator mobile app doesn't require any Internet 
or cellular connection

Lots of people still use feature phones that are not capable of running 
applications such as this.

On Sun, Apr 18, 2021 at 9:05 AM Mel Beckman 
mailto:m...@beckman.org>> wrote:
As far as I know, authenticators on cell phone apps don’t require the Internet. 
For example, the Google Authenticator mobile app doesn't require any Internet 
or cellular connection. The authenticated system generates a secret key - a 
unique 16 or 32 character alphanumeric code. This key is scanned by GA or can 
be entered manually and as a result, both the authenticated system and GA know 
the same secret key, and can compute the time-based 2nd factor OTP just as 
hardware tokens do.

There are two algorithms: HOTP and TOTP. The main difference is in OTP 
expiration time: with HOTP, the OTP is valid until it hasn’t been used;  TOTP 
times out after some specified interval - usually 30 or 60 seconds. For TOTP, 
the system time must be synced, otherwise the generated OTPs will be wrong. But 
you can get accurate enough clock time without the Internet, either manually 
using some radio source such as WWV, or by GPS or cellular system 
synchronization.

 -mel

> On Apr 18, 2021, at 5:46 AM, Mark Tinka 
> mailto:mark@tinka.africa>> wrote:
>
> 
>
>> On 4/18/21 05:18, Mel Beckman wrote:
>>
>> No, every SMS 2FA should be prohibited by regulatory certifications. The 
>> telcos had years to secure SMS. They did nothing. The plethora of 
>> well-secured commercial 2FA authentication tokens, many of them free, should 
>> be a mandatory replacement for 2FA in every security governance regime, such 
>> as PCI, financial account access, government web portals, etc.
>
> While I agree that SMS is insecure at the moment, I think there still needs 
> to be a mechanism that does not rely on the presence of an Internet 
> connection. One may not be able to have access to the Internet for a number 
> of reasons (traveling, coverage, outage, device, money, e.t.c.), and a 
> fallback needs to be available to authenticate.
>
> I know some companies have been pushing for voice authentication for their 
> services through a phone call, in lieu of SMS or DTMF-based PIN's.
>
> We need something that works at the lowest common denominator as well, 
> because as available as the Internet is worldwide, it's not yet at a level 
> that one would consider "basic access".
>
> Mark.

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Tom Beecher]

>
> These low-income people are not the targets of identity thieves, spear
> fishers, or data ransomers.
>

This is patently false. Low-income / disabled / minority / non-english
speakers are absolutely targets of scams like those, and in
significant numbers.



On Mon, Apr 19, 2021 at 9:33 AM Mel Beckman  wrote:

> Tom,
>
> Well, yes, not everyone can afford all technology options. That’s life.
> One has to wonder how someone who needs to protect online accounts cannot
> afford a $30 hardware token (which can be shared across several accounts).
> These low-income people are not the targets of identity thieves, spear
> fishers, or data ransomers. Unlike you, I AM arguing against something: SMS
> as a 2FA token. In this case I don’t think we have ignored low-income
> users, for the same reason that home alarm security aren't ignoring
> low-income users who can’t afford their products. It’s certainly no reason
> to hobble security for the rest of us.
>
>  -mel
>
>
> On Apr 19, 2021, at 6:07 AM, Tom Beecher  wrote:
>
> HW tokens are great, sure.
>
> Except there is a lot of overlap in the Venn diagram between those who
> still use feature phones and those that spending $30 on said hardware token
> is financially obtrusive. ( Not to mention that every hardware token I can
> remember looking at requires an app to set themselves up in the first
> place, and if this is for the people who can't install apps, that's an
> interesting circular dependency. )
>
> I'm not arguing for or against anything here honestly. I'm just pointing
> out that we ( as in the technical community we ) have a tendency to put
> forward solutions that completely ignore what might be reasonably feasible
> for those of lower income , or parts of the world not as technologically
> developed as we might be in ourselves, and we should try to shrink that gap
> whenever possible, not make it worse.
>
> On Mon, Apr 19, 2021 at 8:47 AM Mel Beckman  wrote:
>
>> Then they can buy a hardware token. Using SMS is provably insecure, and
>> for people being spear-phished (a much more common occurrence now that so
>> much net worth data has been breached), a huge risk
>>
>>  -mel
>>
>> On Apr 19, 2021, at 5:44 AM, Tom Beecher  wrote:
>>
>> 
>>
>>> As far as I know, authenticators on cell phone apps don’t require the
>>> Internet. For example, the Google Authenticator mobile app doesn't require
>>> any Internet or cellular connection
>>>
>>
>> Lots of people still use feature phones that are not capable of running
>> applications such as this.
>>
>> On Sun, Apr 18, 2021 at 9:05 AM Mel Beckman  wrote:
>>
>>> As far as I know, authenticators on cell phone apps don’t require the
>>> Internet. For example, the Google Authenticator mobile app doesn't require
>>> any Internet or cellular connection. The authenticated system generates a
>>> secret key - a unique 16 or 32 character alphanumeric code. This key is
>>> scanned by GA or can be entered manually and as a result, both the
>>> authenticated system and GA know the same secret key, and can compute the
>>> time-based 2nd factor OTP just as hardware tokens do.
>>>
>>> There are two algorithms: HOTP and TOTP. The main difference is in OTP
>>> expiration time: with HOTP, the OTP is valid until it hasn’t been used;
>>> TOTP times out after some specified interval - usually 30 or 60 seconds.
>>> For TOTP, the system time must be synced, otherwise the generated OTPs will
>>> be wrong. But you can get accurate enough clock time without the Internet,
>>> either manually using some radio source such as WWV, or by GPS or cellular
>>> system synchronization.
>>>
>>>  -mel
>>>
>>> > On Apr 18, 2021, at 5:46 AM, Mark Tinka  wrote:
>>> >
>>> > 
>>> >
>>> >> On 4/18/21 05:18, Mel Beckman wrote:
>>> >>
>>> >> No, every SMS 2FA should be prohibited by regulatory certifications.
>>> The telcos had years to secure SMS. They did nothing. The plethora of
>>> well-secured commercial 2FA authentication tokens, many of them free,
>>> should be a mandatory replacement for 2FA in every security governance
>>> regime, such as PCI, financial account access, government web portals, etc.
>>> >
>>> > While I agree that SMS is insecure at the moment, I think there still
>>> needs to be a mechanism that does not rely on the presence of an Internet
>>> connection. One may not be able to have access to the Internet for a number
>>> of reasons (traveling, coverage, outage, device, money, e.t.c.), and a
>>> fallback needs to be available to authenticate.
>>> >
>>> > I know some companies have been pushing for voice authentication for
>>> their services through a phone call, in lieu of SMS or DTMF-based PIN's.
>>> >
>>> > We need something that works at the lowest common denominator as well,
>>> because as available as the Internet is worldwide, it's not yet at a level
>>> that one would consider "basic access".
>>> >
>>> > Mark.
>>>
>>
>

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Randy Bush]

> I'd add to that that people probably shouldn't treat phones as a
> significant increase in security, it's not really the out-of-band
> device that it used to be/was in the 1990s. Today, it basically
> equates to a second computer and the probability that the second
> computer is also compromised isn't overly unrealistic.

by the same attacker?  raises the bar a bit.  it's just a second factor,
not a guarantee.

i am a fan of the google token and don't like having to carry a
different hw token for everyone who wants to hw 2fa me.

but i think $ubject is correct.  sms 2fa is roadkill.

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mel Beckman]

Tom,

Well, yes, not everyone can afford all technology options. That’s life. One has 
to wonder how someone who needs to protect online accounts cannot afford a $30 
hardware token (which can be shared across several accounts). These low-income 
people are not the targets of identity thieves, spear fishers, or data 
ransomers. Unlike you, I AM arguing against something: SMS as a 2FA token. In 
this case I don’t think we have ignored low-income users, for the same reason 
that home alarm security aren't ignoring low-income users who can’t afford 
their products. It’s certainly no reason to hobble security for the rest of us.

 -mel


On Apr 19, 2021, at 6:07 AM, Tom Beecher 
mailto:beec...@beecher.cc>> wrote:

HW tokens are great, sure.

Except there is a lot of overlap in the Venn diagram between those who still 
use feature phones and those that spending $30 on said hardware token is 
financially obtrusive. ( Not to mention that every hardware token I can 
remember looking at requires an app to set themselves up in the first place, 
and if this is for the people who can't install apps, that's an interesting 
circular dependency. )

I'm not arguing for or against anything here honestly. I'm just pointing out 
that we ( as in the technical community we ) have a tendency to put forward 
solutions that completely ignore what might be reasonably feasible for those of 
lower income , or parts of the world not as technologically developed as we 
might be in ourselves, and we should try to shrink that gap whenever possible, 
not make it worse.

On Mon, Apr 19, 2021 at 8:47 AM Mel Beckman 
mailto:m...@beckman.org>> wrote:
Then they can buy a hardware token. Using SMS is provably insecure, and for 
people being spear-phished (a much more common occurrence now that so much net 
worth data has been breached), a huge risk

 -mel

On Apr 19, 2021, at 5:44 AM, Tom Beecher 
mailto:beec...@beecher.cc>> wrote:


As far as I know, authenticators on cell phone apps don’t require the Internet. 
For example, the Google Authenticator mobile app doesn't require any Internet 
or cellular connection

Lots of people still use feature phones that are not capable of running 
applications such as this.

On Sun, Apr 18, 2021 at 9:05 AM Mel Beckman 
mailto:m...@beckman.org>> wrote:
As far as I know, authenticators on cell phone apps don’t require the Internet. 
For example, the Google Authenticator mobile app doesn't require any Internet 
or cellular connection. The authenticated system generates a secret key - a 
unique 16 or 32 character alphanumeric code. This key is scanned by GA or can 
be entered manually and as a result, both the authenticated system and GA know 
the same secret key, and can compute the time-based 2nd factor OTP just as 
hardware tokens do.

There are two algorithms: HOTP and TOTP. The main difference is in OTP 
expiration time: with HOTP, the OTP is valid until it hasn’t been used;  TOTP 
times out after some specified interval - usually 30 or 60 seconds. For TOTP, 
the system time must be synced, otherwise the generated OTPs will be wrong. But 
you can get accurate enough clock time without the Internet, either manually 
using some radio source such as WWV, or by GPS or cellular system 
synchronization.

 -mel

> On Apr 18, 2021, at 5:46 AM, Mark Tinka 
> mailto:mark@tinka.africa>> wrote:
>
> 
>
>> On 4/18/21 05:18, Mel Beckman wrote:
>>
>> No, every SMS 2FA should be prohibited by regulatory certifications. The 
>> telcos had years to secure SMS. They did nothing. The plethora of 
>> well-secured commercial 2FA authentication tokens, many of them free, should 
>> be a mandatory replacement for 2FA in every security governance regime, such 
>> as PCI, financial account access, government web portals, etc.
>
> While I agree that SMS is insecure at the moment, I think there still needs 
> to be a mechanism that does not rely on the presence of an Internet 
> connection. One may not be able to have access to the Internet for a number 
> of reasons (traveling, coverage, outage, device, money, e.t.c.), and a 
> fallback needs to be available to authenticate.
>
> I know some companies have been pushing for voice authentication for their 
> services through a phone call, in lieu of SMS or DTMF-based PIN's.
>
> We need something that works at the lowest common denominator as well, 
> because as available as the Internet is worldwide, it's not yet at a level 
> that one would consider "basic access".
>
> Mark.

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Nathaniel Ferguson]

I'd add to that that people probably shouldn't treat phones as a significant increase in security, it's not really the out-of-band device that it used to be/was in the 1990s. Today, it basically equates to a second computer and the probability that the second computer is also compromised isn't overly unrealistic. While the focus is rightfully on SMS, I'd basically consider anything that isn't a hardware token to be more or less the same-- although in fairness the specifics of what we're talking about here doesn't include any of the computers involved, which is a different problem. 18.04.2021, 06:21, "Mel Beckman" :No, every SMS 2FA should be prohibited by regulatory certifications. The telcos had years to secure SMS. They did nothing. The plethora of well-secured commercial 2FA authentication tokens, many of them free, should be a mandatory replacement for 2FA in every security governance regime, such as PCI, financial account access, government web portals, etc.  -mel via cell On Apr 17, 2021, at 6:27 PM, Tim Jackson  wrote: Every SMS 2FA should check the current carrier against the carrier when enrolled and unenroll SMS for 2FA when a number is ported out. BofA and a few others do this. --Tim On Sat, Apr 17, 2021, 8:02 PM Eric Kuhnke  wrote:https://lucky225.medium.com/its-time-to-stop-using-sms-for-anything-203c41361c80 https://krebsonsecurity.com/2021/03/can-we-stop-pretending-sms-is-secure-now/  Anecdotal: With the prior consent of the DID holders, I have successfully ported peoples' numbers using nothing more than a JPG scan of a signature that looks like an illegible 150 dpi black and white blob, pasted in an image editor on top of a generic looking 'phone bill'.  

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mark Tinka]

On 4/19/21 15:07, Tom Beecher wrote:



I'm not arguing for or against anything here honestly. I'm just 
pointing out that we ( as in the technical community we ) have a 
tendency to put forward solutions that completely ignore what might be 
reasonably feasible for those of lower income , or parts of the world 
not as technologically developed as we might be in ourselves, and we 
should try to shrink that gap whenever possible, not make it worse.


This!

Nowadays, the businesses that tend to do very well while seeming like a 
black box to most of their customers, are the ones who are consistently 
solving problems from the perspective of real people, at scale.


If you solve it for 1, you solve it for 10,000 - and then the rest of 
exponential impact.


Mark.

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Tom Beecher]

HW tokens are great, sure.

Except there is a lot of overlap in the Venn diagram between those who
still use feature phones and those that spending $30 on said hardware token
is financially obtrusive. ( Not to mention that every hardware token I can
remember looking at requires an app to set themselves up in the first
place, and if this is for the people who can't install apps, that's an
interesting circular dependency. )

I'm not arguing for or against anything here honestly. I'm just pointing
out that we ( as in the technical community we ) have a tendency to put
forward solutions that completely ignore what might be reasonably feasible
for those of lower income , or parts of the world not as technologically
developed as we might be in ourselves, and we should try to shrink that gap
whenever possible, not make it worse.

On Mon, Apr 19, 2021 at 8:47 AM Mel Beckman  wrote:

> Then they can buy a hardware token. Using SMS is provably insecure, and
> for people being spear-phished (a much more common occurrence now that so
> much net worth data has been breached), a huge risk
>
>  -mel
>
> On Apr 19, 2021, at 5:44 AM, Tom Beecher  wrote:
>
> 
>
>> As far as I know, authenticators on cell phone apps don’t require the
>> Internet. For example, the Google Authenticator mobile app doesn't require
>> any Internet or cellular connection
>>
>
> Lots of people still use feature phones that are not capable of running
> applications such as this.
>
> On Sun, Apr 18, 2021 at 9:05 AM Mel Beckman  wrote:
>
>> As far as I know, authenticators on cell phone apps don’t require the
>> Internet. For example, the Google Authenticator mobile app doesn't require
>> any Internet or cellular connection. The authenticated system generates a
>> secret key - a unique 16 or 32 character alphanumeric code. This key is
>> scanned by GA or can be entered manually and as a result, both the
>> authenticated system and GA know the same secret key, and can compute the
>> time-based 2nd factor OTP just as hardware tokens do.
>>
>> There are two algorithms: HOTP and TOTP. The main difference is in OTP
>> expiration time: with HOTP, the OTP is valid until it hasn’t been used;
>> TOTP times out after some specified interval - usually 30 or 60 seconds.
>> For TOTP, the system time must be synced, otherwise the generated OTPs will
>> be wrong. But you can get accurate enough clock time without the Internet,
>> either manually using some radio source such as WWV, or by GPS or cellular
>> system synchronization.
>>
>>  -mel
>>
>> > On Apr 18, 2021, at 5:46 AM, Mark Tinka  wrote:
>> >
>> > 
>> >
>> >> On 4/18/21 05:18, Mel Beckman wrote:
>> >>
>> >> No, every SMS 2FA should be prohibited by regulatory certifications.
>> The telcos had years to secure SMS. They did nothing. The plethora of
>> well-secured commercial 2FA authentication tokens, many of them free,
>> should be a mandatory replacement for 2FA in every security governance
>> regime, such as PCI, financial account access, government web portals, etc.
>> >
>> > While I agree that SMS is insecure at the moment, I think there still
>> needs to be a mechanism that does not rely on the presence of an Internet
>> connection. One may not be able to have access to the Internet for a number
>> of reasons (traveling, coverage, outage, device, money, e.t.c.), and a
>> fallback needs to be available to authenticate.
>> >
>> > I know some companies have been pushing for voice authentication for
>> their services through a phone call, in lieu of SMS or DTMF-based PIN's.
>> >
>> > We need something that works at the lowest common denominator as well,
>> because as available as the Internet is worldwide, it's not yet at a level
>> that one would consider "basic access".
>> >
>> > Mark.
>>
>

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mark Tinka]

On 4/19/21 14:47, Mel Beckman wrote:

Then they can buy a hardware token. Using SMS is provably insecure, 
and for people being spear-phished (a much more common occurrence now 
that so much net worth data has been breached), a huge risk


Most regular folk (especially those that may not have smartphones) who 
have the option of SMS or a key fob will end up using SMS because it 
does not cause them to spend time standing in a queue in a building to 
give up cash.


Their belief that SMS is secure (enough) has nothing to do with whether 
it actually is. It's all about convenience, and how much they can get 
done without speaking to human.


If a key fob can be sent to them - preferably for free - that would help.

Mark.

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mel Beckman]

Then they can buy a hardware token. Using SMS is provably insecure, and for 
people being spear-phished (a much more common occurrence now that so much net 
worth data has been breached), a huge risk

 -mel

On Apr 19, 2021, at 5:44 AM, Tom Beecher  wrote:


As far as I know, authenticators on cell phone apps don’t require the Internet. 
For example, the Google Authenticator mobile app doesn't require any Internet 
or cellular connection

Lots of people still use feature phones that are not capable of running 
applications such as this.

On Sun, Apr 18, 2021 at 9:05 AM Mel Beckman 
mailto:m...@beckman.org>> wrote:
As far as I know, authenticators on cell phone apps don’t require the Internet. 
For example, the Google Authenticator mobile app doesn't require any Internet 
or cellular connection. The authenticated system generates a secret key - a 
unique 16 or 32 character alphanumeric code. This key is scanned by GA or can 
be entered manually and as a result, both the authenticated system and GA know 
the same secret key, and can compute the time-based 2nd factor OTP just as 
hardware tokens do.

There are two algorithms: HOTP and TOTP. The main difference is in OTP 
expiration time: with HOTP, the OTP is valid until it hasn’t been used;  TOTP 
times out after some specified interval - usually 30 or 60 seconds. For TOTP, 
the system time must be synced, otherwise the generated OTPs will be wrong. But 
you can get accurate enough clock time without the Internet, either manually 
using some radio source such as WWV, or by GPS or cellular system 
synchronization.

 -mel

> On Apr 18, 2021, at 5:46 AM, Mark Tinka  wrote:
>
> 
>
>> On 4/18/21 05:18, Mel Beckman wrote:
>>
>> No, every SMS 2FA should be prohibited by regulatory certifications. The 
>> telcos had years to secure SMS. They did nothing. The plethora of 
>> well-secured commercial 2FA authentication tokens, many of them free, should 
>> be a mandatory replacement for 2FA in every security governance regime, such 
>> as PCI, financial account access, government web portals, etc.
>
> While I agree that SMS is insecure at the moment, I think there still needs 
> to be a mechanism that does not rely on the presence of an Internet 
> connection. One may not be able to have access to the Internet for a number 
> of reasons (traveling, coverage, outage, device, money, e.t.c.), and a 
> fallback needs to be available to authenticate.
>
> I know some companies have been pushing for voice authentication for their 
> services through a phone call, in lieu of SMS or DTMF-based PIN's.
>
> We need something that works at the lowest common denominator as well, 
> because as available as the Internet is worldwide, it's not yet at a level 
> that one would consider "basic access".
>
> Mark.

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Tom Beecher]

>
> As far as I know, authenticators on cell phone apps don’t require the
> Internet. For example, the Google Authenticator mobile app doesn't require
> any Internet or cellular connection
>

Lots of people still use feature phones that are not capable of running
applications such as this.

On Sun, Apr 18, 2021 at 9:05 AM Mel Beckman  wrote:

> As far as I know, authenticators on cell phone apps don’t require the
> Internet. For example, the Google Authenticator mobile app doesn't require
> any Internet or cellular connection. The authenticated system generates a
> secret key - a unique 16 or 32 character alphanumeric code. This key is
> scanned by GA or can be entered manually and as a result, both the
> authenticated system and GA know the same secret key, and can compute the
> time-based 2nd factor OTP just as hardware tokens do.
>
> There are two algorithms: HOTP and TOTP. The main difference is in OTP
> expiration time: with HOTP, the OTP is valid until it hasn’t been used;
> TOTP times out after some specified interval - usually 30 or 60 seconds.
> For TOTP, the system time must be synced, otherwise the generated OTPs will
> be wrong. But you can get accurate enough clock time without the Internet,
> either manually using some radio source such as WWV, or by GPS or cellular
> system synchronization.
>
>  -mel
>
> > On Apr 18, 2021, at 5:46 AM, Mark Tinka  wrote:
> >
> > 
> >
> >> On 4/18/21 05:18, Mel Beckman wrote:
> >>
> >> No, every SMS 2FA should be prohibited by regulatory certifications.
> The telcos had years to secure SMS. They did nothing. The plethora of
> well-secured commercial 2FA authentication tokens, many of them free,
> should be a mandatory replacement for 2FA in every security governance
> regime, such as PCI, financial account access, government web portals, etc.
> >
> > While I agree that SMS is insecure at the moment, I think there still
> needs to be a mechanism that does not rely on the presence of an Internet
> connection. One may not be able to have access to the Internet for a number
> of reasons (traveling, coverage, outage, device, money, e.t.c.), and a
> fallback needs to be available to authenticate.
> >
> > I know some companies have been pushing for voice authentication for
> their services through a phone call, in lieu of SMS or DTMF-based PIN's.
> >
> > We need something that works at the lowest common denominator as well,
> because as available as the Internet is worldwide, it's not yet at a level
> that one would consider "basic access".
> >
> > Mark.
>

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mark Tinka]

On 4/19/21 11:17, Eric Kuhnke wrote:

I would start with cellular carriers and nations that intentionally 
take steps to block anything VoIP as a threat to their revenue model. 
Or because anything vpn/ipsec/whatever related is a threat to local 
Internet censorship laws.


Plenty of places the sort of ipsec tunnel used for vowifi is not 
usable on whatever consumer-grade cellular or local broadband ISP you 
might find.


Not sure what that says for the US of A, as that is where this has hit 
me so far.


Mark.

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Eric Kuhnke]

I would start with cellular carriers and nations that intentionally take
steps to block anything VoIP as a threat to their revenue model. Or because
anything vpn/ipsec/whatever related is a threat to local Internet
censorship laws.

Plenty of places the sort of ipsec tunnel used for vowifi is not usable on
whatever consumer-grade cellular or local broadband ISP you might find.




On Sun, Apr 18, 2021 at 11:11 PM Mark Tinka  wrote:

>
>
> On 4/19/21 06:50, Julien Goodwin wrote:
>
> > This is already probably past the point of being on topic here, but you
> > tickled my personal favorite one of these.
> >
> > My airline of choice (Qantas) has mandatory SMS second factor, after
> > perhaps a mobile carrier requiring it for support one of the most
> > facepalm-worthy uses of SMS 2FA I've seen.
>
> It's interesting that VoWiFi is meant to support both voice and SMS,
> domestically and when one travels. So I'm curious why SMS's would not
> work with VoWiFi when traveling to a country that won't deliver your
> SMS's generically. After all, VoWiFi is, as far as I understand it,
> meant to be a direct IP tunnel back to your home network for both
> billing and service.
>
> If anyone has more clue about this on the list, I'd really like to know,
> as my mobile service providers hardly know what I'm talking about when I
> ring them up with questions.
>
> Mark.
>
>

Re: Malicious SS7 activity and why SMS should never by used for 2FA

[Mark Tinka]

On 4/19/21 06:50, Julien Goodwin wrote:


This is already probably past the point of being on topic here, but you
tickled my personal favorite one of these.

My airline of choice (Qantas) has mandatory SMS second factor, after
perhaps a mobile carrier requiring it for support one of the most
facepalm-worthy uses of SMS 2FA I've seen.


It's interesting that VoWiFi is meant to support both voice and SMS, 
domestically and when one travels. So I'm curious why SMS's would not 
work with VoWiFi when traveling to a country that won't deliver your 
SMS's generically. After all, VoWiFi is, as far as I understand it, 
meant to be a direct IP tunnel back to your home network for both 
billing and service.


If anyone has more clue about this on the list, I'd really like to know, 
as my mobile service providers hardly know what I'm talking about when I 
ring them up with questions.


Mark.