You can't control email.
Email is easy to intercept.
Email is not secure - unless you use pgp
Email is not real time
Trust me on this, ... I was an email sysadmin
@system32
Why can't you control email?
Email is not easy to intercept.
How are you going to intercept my email?
I'm interested.
I control the mx records for my domain. Sender looks up mx records to know who to send to.
connects to the server listed directly. Depending on which of my mail servers it connects to it either stores, or forwards to the correct server.
Are you saying you have control of one of the mail servers involved? At least on the FNB side, I can see some issues which might tilt that your way (detailed below), as mail passes through what appears to be at least two 3rd parties. (Bidvest and enterprisedd)
Email is not secure - unless you use pgp
It's certainly far more secure than sms.
FNB's servers negotiate TLS over DKIM for communications between their server and mine, so its secured between A->B - i.e. you can't sniff the traffic usefully in the event you were in between their network and mine. Their Signatures verify for their messages.
They also publish SPF so I can verify the sender. Although they have in the past screwed that up. As I've let them know once or twice when thats failed.
Received-Spf: pass (([my server]: SPF record at fnbstatements.co.za designates 41.170.90.242 as permitted sender)
What I don't like is that they use a 3rd party for emails.
EnterpriseDD
"Join the EDD Generation. Document Delivery Transformed. With its remarkably accurate, efficient and secure document delivery system, EDD will radically transform your..."
Received: from unknown (HELO relay236.enterprisedd.com) (41.170.90.242) by ([my server] with SMTP; 8 Nov 2020 18:55:52 +0000
Received: from EDD-ZACheque-01.jhb.bidvestdata.co.za (Not Verified[10.0.0.211]) by relay236.enterprisedd.com id <B5fa83f1e0001>; Sun, 08 Nov 2020 20:55:26 +0200
Received-Spf: pass ([my server]: SPF record at fnbstatements.co.za designates 41.170.90.242 as permitted sender)
<
[email protected]>
That email server also handles other mails for other clients in addition to FNB. - eg enterprisedd.com 's mail.
dig mx enterprisedd.com
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> mx enterprisedd.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51527
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;enterprisedd.com. IN MX
;; ANSWER SECTION:
enterprisedd.com. 14400 IN MX 15 relay236.enterprisedd.com.
enterprisedd.com. 14400 IN MX 15 relay246.enterprisedd.com.
enterprisedd.com. 14400 IN MX 5 za-smtp-inbound-1.mimecast.co.za.
enterprisedd.com. 14400 IN MX 5 za-smtp-inbound-2.mimecast.co.za.
To be honest I'm not quite sure why FNB doesn't handle their own mails. Would be safer.
I should ask them.
Email is not real time
So what?
Neither is sms, and nor is their app push.
Trust me on this, ... I was an email sysadmin.
Good for you. I also maintain my own email servers, and I disagree with you.
Is there a link to a successful breach of a client's banking by hijacking DNS, changing MX records or plaint-text email interception by sitting between the sending and receiving SMTP Server to get the OTP? Also considering a large portion of the population doesn't run FreeBSD under their desk for email anymore, they're using Gmail, Office365 etc.
Because there are a ton of examples of banking fraud done by SMS 2FA breaches due to to sim card cloning and other means.
And having the bank's app do the 2FA is fine, but in some cases it doesn't work. I've had at least 2 of the major banks apps just never get back to me with an OTP or Transaction Confirmation. I don't mind the use of the phone app, but there should be a fallback. And email makes a great fallback.
This ^^^^^^^