3 ms·

I not NOT get why the demo'd and encouraged way of sending is considered secure. The email is not encrypted. It contains a link in plain text. It's not stipulat

by mhdhn 6y ago

I not NOT get why the demo'd and encouraged way of sending is considered secure. The email is not encrypted. It contains a link in plain text. It's not stipulated that secure email servers (TLS) are used, and if non-secure, the plain text of the link could potentially be sniffed out by anyone with access to one of the nodes along the chain of transmission of the email data. Further, if the email server on either end is gotten to, the URL is sitting there in plain text, so the attacker has it. Now, once you have the URL, you have direct access to the secret info, without any challenge. Modulo this method making it possible to shorten the time the info is available, and to take the info away after the info has been accessed, what is secure about this? Couldn't you have the same effect essentially by sending the secret through email and then mutually agreeing on both sides to delete the email message immediately after sending (by the sender) and receiving (by the receiver)?

DistractionRect 6y ago
> Add a password to further protect the Send
- egem 6y ago
  which you must again share with the recipient but how?
  - Corrado 6y ago
    It's turtles all the way down!
justusthane 6y ago
Probably the best thing to do is set the access count limit to one. That way, no one else will be able to access it after the intended recipient does. And if a 3rd party accesses it before the intended recipient, then the intended recipient will not be able to access it and at least you'll have an indication that it was intercepted.
- tatersolid 6y ago
  > Probably the best thing to do is set the access count limit to one. You’d better use at least two. Nearly every email service in 2021 has anti-malware and anti-phishing which was inspects links as a security feature. This often breaks poorly designed “one time” links like password resets that incorrectly use non-idempotent GET requests.
  - justusthane 6y ago
    Interesting, good point. Unfortunately that means that you can no longer be sure that it hasn't also been accessed by a malicious third party though.
    - mhdhn 6y ago
      Now you're in a trust relationship with receiving party's antispamware? Great

by mhdhn 6y ago

DistractionRect 6y ago

> Add a password to further protect the Send

egem 6y ago
which you must again share with the recipient but how?
- Corrado 6y ago
  It's turtles all the way down!

justusthane 6y ago

Probably the best thing to do is set the access count limit to one. That way, no one else will be able to access it after the intended recipient does. And if a 3rd party accesses it before the intended recipient, then the intended recipient will not be able to access it and at least you'll have an indication that it was intercepted.

tatersolid 6y ago
> Probably the best thing to do is set the access count limit to one. You’d better use at least two. Nearly every email service in 2021 has anti-malware and anti-phishing which was inspects links as a security feature. This often breaks poorly designed “one time” links like password resets that incorrectly use non-idempotent GET requests.
- justusthane 6y ago
  Interesting, good point. Unfortunately that means that you can no longer be sure that it hasn't also been accessed by a malicious third party though.
  - mhdhn 6y ago
    Now you're in a trust relationship with receiving party's antispamware? Great