Hacker News new | ask | show | jobs
by AndrewDucker 1819 days ago
If the link is sitting in their email then surely that's just as unsafe as having the password there?
2 comments

Not exactly. Sure, if your email is compromised someone could access the secret link, and ultimately your password. But now, you will know that someone else had access to your password, since the link won't work for you anymore. This is crucial information.

Btw. You can encrypt your secret with an optional password (which may be shared via a different channel).

No, it expires after they view it.
Yes, this is a nice solution, but email security services do click on links before delivering to the client's email inbox. As such, you may need to set the link expiry click number to greater than 1. And then you lose the security due to being ephemeral. Of course, you can log the IP addresses of the clickers, but still you have the leak.
> email security services do click on links before delivering to the client's email inbox

True. This may be a problem. Like mentioned, common bots are being blocked currently, plus, I will be testing POST instead of GET requests (Since bots apparently don't do POST). An another obvious solution is to include some kind of user interaction before the secret is fetched. Although I don't like that solution so much. C.

In practice this has not been a problem. It's like saying you can't put unsubscribe links in emails because a bot will click on it... You just simply design the software so that doesn't happen.

Like I said, I've used a similar service that only allows you to view the secret once and I've used it dozens of times with no problems.

> you just simply design the software so that doesn't happen.

How do you go about doing that? disregard security service clicks based on IP address blacklists, user agent sniffing, etc?

Nope you just use a POST request...
How does a legitimate user clicking on a link inside an email generate a POST request?