I’m also currently going through a refi now, and my bank sent a email to me with [secure] in the subject line, as @Atamasama described. It included a link to the bank’s secure portal that I logged in separately. I had a simple question, and the answer came back to my inbox marked as [External], obviously a non-secure email.
I was wondering what this is all about, so this thread is very enlightening.
I actually tried that next. Something on his end restricted him from either downloading or opening the zip file.
I think we’re on the hunt for another lender now.
“Despite our technical ineptitude you can trust us with all of your money, pinky-swear!”
Is this even a real mortgage company and not some scam? Lol.
Edit: Oh wait, nevermind, I thought it was their own portal. If you just email someone a random password protected zip file, corporate antivirus might flag it as spam.
30 or so years ago, when things were even less sophisticated, i handed paper documents to my mortgage broker and to the bank.
Or as “we can’t scan this for malware”. My prior employer wouldn’t have allowed that, either.
I do think that photo attachments are less insecure than something trivially machine readable, like a pdf. Yes, computers can scan an image and read the text, but I don’t think a photo announces, “i contain text” quite as blatantly as a pdf. But i wouldn’t email something as sensitive as a mortgage application.
Back when services like PayPal were less available, i used to email my credit card number to small merchants who didn’t understand security by typing something like:
The first 5 digits are 12345 then 3 are 678 and the next 2 are 90…
My thought was that i didn’t want to be the lowest hanging fruit. But today there are many options that are actually somewhat secure, that even a small merchant can afford to implement.
It was a Dropbox link to the zip file. I can still see them being cautious about that.
I make my living supporting a secure email server. You’re not missing anything.
As far as when the email message is in transit, it is normally encased in TLS (transport layer security), which obviously encrypts the message while it is sent over the wire. There are systems such as S/Mime that can be used to encrypt the message content at rest, but servers that use it are pretty rare, and products like mine can decrypt the message so it can scan them for threats. In general, once the message reaches the receiving server, it’s clear text. Any admin (or a nefarious person who has elevated their access to admin) on the server can then read the message.
One of the products my company makes encrypts the data in an email at rest. It encrypts the contents, and stores the key on our server. When the recipient opens the message, they get its content enclosed in an application (opens in a browser, but is local to your machine) that will prompt them for their password and retrieve the key and decrypt the contents if they pass authentication. The sender can revoke the key manually or set a date for it to expire. After that happens, the recipient can’t view the contents of the message any more. It’s a good system. Your data is secure, and we don’t have it, we just have the key to decrypt it. But that product is not free, and unless your email provider is using something like it, your email data is most likely not safe at rest.
PGP/GPG is also a pretty good system, but it is kind of a pain to use.
Yep, my product will actually try to decrypt these attachments by going through the message looking for passwords that decrypt it, and will also try a dictionary of passwords against them. If it can’t decrypt it, it will mark these attachments as unscannable, and the administrator can take one of several different actions based on the verdict, up to and including ditching the email message entirely.
Isn’t that the “monkey in the middle” attack?
As someone who just recently got out of working IT for a mortgage company for the past 12 years (and interacted with Regions), the loan officer is an idiot. We used the “[SECURE]” tag as well, but it only works on outgoing emails from our system, not incoming. Unfortunately, most loan officers are idiots when it comes to IT issues, so switching banks won’t change that.
Way back when I worked in a poorly run data center, they had daisy chained many, many switches together. Normally a switch will send out data only on the one interface it knows leads to the network that data’s MAC address lies on. But when it’s seen too many MAC addresses for it to keep track of, it goes “fuck it, I’m a hub” and simply sends data out on all of its interfaces.
There I could just watch all kinds of traffic by starting up a capture on my workstation. I could see plenty of SMTP and POP3 traffic happening in clear text to servers all over this DC. I certainly wasn’t intended to read these conversations, and any of our customers could have fired up tcpdump on their server and read them as well. That place eventually cleaned up its network design, but it doesn’t take much in the way of misconfiguration to hoover up a lot of data. Of course, this was a long time ago when even HTTPS wasn’t really the norm. These days it would be a lot harder to grab an email in transit due to the ubiquity of TLS in SMTP traffic.
All of that said, I do know of at least one company that recently-ish had its LDAP traffic sniffed and its mail accounts were compromised as a result. They wisely switched to LDAP encased in TLS afterward.
I think this is what is most unfortunate with the current system… you, as an email sender, have no way of knowing whether your message would be sent through secure means.
It should’ve been possible to design a system where all the servers in a chain can prenegotiate and guarantee an encrypted channel, in a way that the user can see (e.g. an email padlock icon). But it didn’t happen that way, and so users just have to pray and hope that the email ends up encrypted.
What good is “it’s often encrypted, but not always, and you can never know which is which upfront”? 
Email was designed to be accessible, not to be secure. Post cards have their place. If you want secure communication, there are many options. I mostly use Signal. Conveying documents through a secure server is a common solution
Yep, I’ve been saying that email is a dead protocol that should go the way of the dodo since 1998. No one seems to agree with me and so they keep welding other stuff on top of it. Now it’s my living.
Hehe, in truth, this was worse. They control both ends of the LDAP conversation. They could have secured it easily, but didn’t.
But yeah, some of our customers do still allow SMTP to fall back to clear text if TLS negotiation fails or is unavailable for some reason. Bigger orgs generally don’t, though. Even then, internal SMTP communication is often sent in clear text. Those TLS sessions aren’t free, and they want their mail to flow fast once it’s on their network.
I’ve yet to hear of any bank in the US that has a strong information security culture.
What’s ironic about that?
Maybe because Google is widely seen as more or less the current incarnation of “Big Brother is Watching”?
Your email rattling around inside Google is very safe from outside intrusion. But utterly unsafe from being read by and used by Google itself. And, probably, NSA.