61–70 of 271 posts
I built a small Go web app to do some security testing. When a user registers for an account, I generate a 128-bit secure token and email it to the address they provided (as a URL). Token URLs look like this: /validate/email/1d00a5c2648c211befd33f5a8a7cbfab The token is cryptographically strong and disappears after access. It can't be guessed and no one but the email account holder should click it, but I am seeing th…
A better solution is to assume that some middleman (email server or client) will always try to access links in the email. Instead send the user a code and have them manually enter it on the linked page.
I always wondered when single-click unsubscribe was going to be a problem because of exactly this. I mean, how do you expect to give a URL to Google and have them just never crawl it?
To put succinctly what others are saying: it was never not a problem; it never should have been happening.
I built a small Go web app to do some security testing. When a user registers for an account, I generate a 128-bit secure token and email it to the address they provided (as a URL). Token URLs look like this: /validate/email/1d00a5c2648c211befd33f5a8a7cbfab The token is cryptographically strong and disappears after access. It can't be guessed and no one but the email account holder should click it, but I am seeing th…
I always wondered when single-click unsubscribe was going to be a problem because of exactly this. I mean, how do you expect to give a URL to Google and have them just never crawl it?
It specifically mentions in section 3.2 that mail receivers are not to crawl this URL without user consent:
> The mail receiver MUST NOT perform a POST on the HTTPS URI without user consent. When and how the user consent is obtained is not part of this specification.
I haven't seen any statistics on how widespread adoption of this RFC is among the major mail providers, though.
Earlier quoted context omitted.
True. Phish testing campaigns in companies that send fake phishing emails to employees, are probably full of inaccurate data due to this. "Why did you click that link? But, I didn't."
Many phishing test as a service companies will report clicks vs. people who actually interact with the page.
Earlier quoted context omitted.
But to be fair, 1-click unsubscribe is a very user friendly thing to do. As a user, if I have to jump through a bunch of hoops to unsubscribe, I'm just going to mark your message as spam and move on with my life.
Exactly. And it's not just one-click unsubscribe. Using a secret link sent to an account's email address as a way to implicitly log in instead of having to remember a password is increasingly common and also an interesting idea in terms of user experience and security. If it's OK for your mail service to open one secret link, where does it stop? Is it also OK for them to spider the content they can reach from that li…
"Secret link" is an oxymoronical concept. Resource identifiers are exactly that: identifiers. They're not private names, and any design that relies on keeping them secret is inherently flawed. If it's accessible on the openly resolvable web, then the content needs to be treated as if it's public. If your use calls for authentication or authorization, then actually use an authentication or authorization system.
Earlier quoted context omitted.
But to be fair, 1-click unsubscribe is a very user friendly thing to do. As a user, if I have to jump through a bunch of hoops to unsubscribe, I'm just going to mark your message as spam and move on with my life.
Exactly. And it's not just one-click unsubscribe. Using a secret link sent to an account's email address as a way to implicitly log in instead of having to remember a password is increasingly common and also an interesting idea in terms of user experience and security. If it's OK for your mail service to open one secret link, where does it stop? Is it also OK for them to spider the content they can reach from that li…
The user experience with this is terrible if email is not set up on the device you want to log in from