FaxLine

[gimpelevichtrust]

Since we're worried about assumptions, if the service only emailed a link (that you had to retrieve over authenticated TLS), that wouldn't preclude the service from transmitting the data between servers in the clear, possibly outside of Sonic's network.

The banks do not use a direct link. It is merely a notification of availability. A secure login to retrieve anything is still required. This would render any issue of inside/outside Sonic's network irrelevant.

[toast0]

Since we're worried about assumptions, if the service only emailed a link (that you had to retrieve over authenticated TLS), that wouldn't preclude the service from transmitting the data between servers in the clear, possibly outside of Sonic's network.

The banks do not use a direct link. It is merely a notification of availability. A secure login to retrieve anything is still required. This would render any issue of inside/outside Sonic's network irrelevant.

Yes, you have to login securely, and see the bank's cross sell promotions, and then they give you the statement content, that may be stored on their systems in plaintext*, and may be transfered between their servers in plain text (possibly over networks they don't control) before being delivered to your computer via TLS.

* If they data is stored encrypted, you also have to ask with what key, and if someone with access to their systems could easily find the key, or create a session for your account without your login information.

[gimpelevichtrust]

These possibilities do not affect whether or not Sonic would engage in the blatant disregard for security you describe. It is perfectly possible for a retrieve-by-HTTPS arrangement to be set up in a way that avoids the security problems that go along with it. It is equally possible for the current arrangement to avoid the security problems that go along with it. However, overall, the retrieve-by-HTTPS arrangement would provide Sonic with a greater degree of control over end-to-end security with fewer layers of complexity. So far, no one has said it cannot be made not to be less secure than the current arrangement.

[toast0]

These possibilities do not affect whether or not Sonic would engage in the blatant disregard for security you describe.

Store in plaintext is not disregard for security; it's security realism; their servers must be able to retrieve the plaintext to send to you (via HTTPS, or POP + TLS or IMAP + TLS); and presumably you don't want your unretrieved messages to be unreadable if you change your password, so there's really nothing that they can use that only you know.

It is perfectly possible for a retrieve-by-HTTPS arrangement to be set up in a way that avoids the security problems that go along with it. It is equally possible for the current arrangement to avoid the security problems that go along with it. However, overall, the retrieve-by-HTTPS arrangement would provide Sonic with a greater degree of control over end-to-end security with fewer layers of complexity. So far, no one has said it cannot be made not to be less secure than the current arrangement.

Sonic already controls all the moving parts, except your email client, and your choice of password. Asking security conscious users to use TLS and not forward their email is less complex than setting up another user specific storage system. Delivery via HTTPS certainly can be as secure as delivery to a mailbox in the same network retrieved via TLS; but the real security issue is that the FAX is sent in the clear, and all the communications providers in the path can read it, regardless of the window dressing you put before sending and after receiving.

Banks don't send emailed statements not because email is inherently insecure, but because it would be hard for them to distinguish between a destination where the message could not be observed and one where it could, and it would be confusing for users; and PGP/GPG would also be confusing... plus they get to show you pretty interactive ads and build their brand if you come to their site.

[gimpelevichtrust]

it would be hard for them to distinguish between a destination where the message could not be observed and one where it could

By your argument, this can be avoided through user behavior. If it were, and the user acted in a less-than-optimal-security manner, the bank would be in a position of blaming the user for doing so. For obvious reasons, this would be bad for everyone. Sonic shouldn't create a blame-the-user situation, either.

[virtualmike]

Nevertheless, I would say the most vulnerable portion is of the process is the FAX transmission,

I'd narrow it to the human controlling the fax transmission.


A couple of months ago, I received, via Faxline, a fax from a doctor's office ordering some medical tests on a patient. The fax included the patient's name, address, phone number, SSN, and medical record number, along with the list of tests.

I called the doctor's office, informed the clerk who answered the phone of the error, and while still on the phone, deleted the message.

Of course, the idiot got upset with me, claiming I intercepted the fax. I asked her the destination number for the fax, and she cited my Faxline number. I told her that was my number, and asked why she was faxing to it. She repeated her accusation, so I bailed and hung up.

[digitalbitstream]

I get faxes so infrequently (once every few years) I'd be willing to take a "temporary" fax line. Maybe I'd sign up for it for 24 hours at a time, then relinquish it to others.