Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

[Request] Send Encrypted Token Emails

Freewheeling spot to chew the fat on anything cryptostorm-related that doesn't fit elsewhere (i.e. support, howto, &c.). Criticism & praise & brainstorming & requests for explanation... this is where it goes when it's hot & ready for action! :-)
User avatar

Topic Author
parityboy
Site Admin
Posts: 1096
Joined: Wed Feb 05, 2014 3:47 am

[Request] Send Encrypted Token Emails

Postby parityboy » Sat Jun 10, 2017 5:18 pm

The idea here is that when paying for a token, the TokenBot is able to use a PGP public key (supplied from either a keyserver or by the payment form) to encrypt token-bearing emails.


tweetnacltooo

Re: [Request] Send Encrypted Token Emails

Postby tweetnacltooo » Tue Jun 13, 2017 10:07 am

Perhaps tweetnacl based crypted token emails as well ?

all that is required is the recipients minilock or tweetnacl public key --> minilock/ nacl based pub ids are nearly pseudonymous.

wallah and what do we have xD

User avatar

df
Site Admin
Posts: 283
Joined: Thu Jan 01, 1970 5:00 am

Re: [Request] Send Encrypted Token Emails

Postby df » Mon Sep 18, 2017 3:55 pm

I would like to implement this, but the problem is that a lot of people create PGP keys tied to their email address just to test out PGP, without actually using it.
If tokenbot were to send an encrypted email to them, they might not still have the key/password needed to decrypt it.
Plus, there could be multiple keys for the same address, and we don't know which one is their active/valid one (maybe the one on the keyservers is different than the one they actually use).

If sending tokens in plaintext email is the issue, I think one solution would be to instead send token emails that contain a link to a webpage that displays their token. In order to avoid the whole account creation requirement, that link would show them their token only once. The added benefit to that is if the token link is invalid by the time the customer goes to the page, then their email was obviously intercepted.
The obvious problem is the same thing we have now where people accidentally delete the welcome email, or an overzealous spam filter prevents them from receiving the email.

Either way, tokens were designed to be nothing more than authorization tokens. If someone were to intercept the welcome email containing a customer's token, the most they could do with it is DoS that person by using up their token before the customer could. They can't decrypt traffic, or anything like that, with the token.


Return to “general chat, suggestions, industry news”

Who is online

Users browsing this forum: No registered users and 10 guests

cron

Login