Hacker News Reader

Comment by TomVDB | Hacker News Reader

Reminds me of a friend of mine who wanted the ability to have Unix shell access on his work machine from home. (This was early nineties, when Internet log in to work was not a thing.)

He ran a service that piped all income emails to a script. If the email contained a magic cookie, the subsequent commands were executed on a shell, and the results emailed back to sender. There were no checks on who the sender was. :-)

I don’t think the IT people at his very big telecom equipment company would have approved. They never found out about this stunt, but he was later fired for running a password cracker on the company server farm.

View on HN

This reminds me of somebody who held my job before I joined.

He had questionable test/release/deployment practices, so they took his root privs away in prod, and instead made him build packages (that was mostly already done before) and hand them to the admin team.

Not to be deterred by useless administrative overhead, he added an environment variable where the application would look for code files, defaulting it to somewhere under /tmp. Then he could deploy his own hotfixes as a user.

The company only found out when one of the two prod servers was rebooted, /tmp/ was wiped, and suddenly one of the two servers exhibited lots of old, already fixed bugs.

I disagree with "There were no checks on who the sender was." - there was a password/token authentication. That was the check, and it's harder to spoof than a regular sender check would have been back then (nowadays with DKIM etc. the situation is a bit better).

I don’t think the magic cookie was anything deliberately complex, but you’re right that guessing wouldn’t have been very practical.

In the early 1990s, all email was plaintext and transports were unencrypted.

In the very early 1990s, PGP didn't exist, and the odds that the email content was independently encrypted were low.

Any network sniffer or filesystem access would have exposed the cookie.

> the early 1990s, all email was plaintext and transports were unencrypted.

I thought all email is still plaintext? The protocol does not support encryption?

I was trying more to cover the distinction between in-flight and at-rest encryption rather than imply that contents are routinely end-to-end encrypted now. That's sometimes but not always the case.

There is an increasing use of encryption-at-rest services (AFAIU Gmail is, though that's using a system-level, not user-level, key). There are some encrypted email services (e.g., Protonmail), in which contents are encrypted both in-flight and at-rest.

Not especially relevant to the anecdote here, but a critical concern for messaging opsec: email metadata, including sender, receiver, and subject, are not encrypted at rest or to the originating, receiving, and possibly transit systems, may also leak information, and are often more valuable and useful than contents themselves.

I find myself wondering if my correspondents who can't seem to provide contextually useful subject lines are actually doing me a favour, despite the annoyance factor ....

SMTP over TLS is very common today. It's not guaranteed, but many emails sent between major providers should actually be encrypted in transit. Gmail actually flags email that was received without TLS with a little red icon indicating its relative insecurity.

Back in the 90s, though... not so much.

SMTP over TLS is first proposed in RFC 2487, dated January of 1999, AFAIU.

https://datatracker.ietf.org/doc/html/rfc2487

Actual widespread implementation didn't occur until the 2010s.

STARTLS Everywhere launched in 2014. https://www.eff.org/deeplinks/2020/04/winding-down-starttls-...

Google have tracked the prevalence of TLS-based email connections ... since 2014: https://transparencyreport.google.com/safer-email

Reply on news.ycombinator.com