3

I'm developing a mobile app (Android only for now) to provide a disposable e-mail service to users. Users will be given temporary e-mail addresses so they can receive and read e-mails for a certain period of time, then accounts are completely destroyed.

In this architecture, I'm not interested in users knowing the passwords for their e-mail accounts, because they could log-in via a common client and send mails or even spam (currently I want to allow only incoming e-mails, not outgoing).

My idea is to generate a pseudo-random password inside the app each time the user wants to create a disposable e-mail, send it through a HTTPS POST request to the remote server so the account can be created, and then allow the user log into the account using a small client via IMAPS.

I know both HTTPS and IMAPS should provide enough security as far as the client <-> server data goes, but I'm concerned about the possibility users could break the code (or introduce a device before their router so the HTTPS mailbox creation request might be read before sent, or alike) and somehow get the password for the temporary account while the account still exists.

How real is this situation? If users can get the passwords with the above schema, is there a way I can achieve my purpose in a secure way?

Thanks.

Improve this question

3 Answers 3

Reset to default
1

I Think you are doing the thing wrong from the very beginning. You say you want to prevent users from Learning the password to prevent them from sending spam.

Of course, the SMTP server should be configured to allow no relaying, not even for local users, it should only accept emails for your disposable service. Then you can easily give out random passwords to your app, completely unencrypted and you can let them read the mails without SSL too. It wont matter if your end users get at hold of them, all they can do is read the email for their own disposable email account in the IMAP box. They wont get any advantage by knowing the password.

To prevent users from using a Another email client and Another SMTP server (like a ISP server) to send spam using your disposable service email adresses as spoofed sender (they wont need to know the password for this type of abuse), configure the disposable service to have a SPF record of "v=spf1 -all". This will ensure all outgoing mails from the disposable service is discarded as fraudulent/spoofed from receivers that adhere to the SPF standard.

Improve this answer
1
  • This is a good answer. I'm guessing the OP needs the email protocol for some reason and can't use HTTPS (why, I have no clue). This allows continued use of the SMTP protocol along with policies which describe the behavior of the system (Policy: no mail forwarding). All other comments and ideas, so far, sound like roll-your-own encryption, an ill-advised process for the uninitiated. I'm still not clear why the HTTPS channel isn't sufficient for sending the messages in question, but as this is from Apr 11, I'm not sure we will ever find out.
    – Andrew Philips
    Commented Nov 8, 2015 at 1:20
0

You can use an encryption algorithm like RC4 or AES. You can encrypt the auto generated password in your app with a key and decrypt the same at server before account creation. If any user catches the transfer he will only see some random sequence of letters. If your users have an account on your server than you can also generate a unique encryption key for a every user.

Improve this answer
7
  • Thanks. But what advantage provides a symmetric encryption system like AES in relation to an assymetric system like SSL/TLS? My worry is about the capability of the user of getting the plain password before sending the HTTPS POST request to the remote server. As I understand it, using RC4 or AES would produce the same situation, or not?
    – nKn
    Commented Apr 11, 2015 at 18:10
  • 1
    If you are worried about the user getting the plan password before it is sent to the server, then why not just generate the password on the server, encrypt it, and send it back to the client/app?
    – Spencer D
    Commented Apr 11, 2015 at 18:48
  • Correction to prior comment: Plain* Anyway, there are some benefits to using encryption on top of HTTPS (ssl/tls). A client could decrypt your HTTPS traffic by installing a custom certificate & proxying the traffic. I have personally done this using the Charles Web Debugger Proxy application. So if you mix in encryption on top of HTTPS, the attacker not only has to decrypt the HTTPS, but they must reverse engineer your app to decrypt the second layer of encryption.
    – Spencer D
    Commented Apr 11, 2015 at 19:06
  • Thanks @SpencerDoak. Ok, I get the point, however, AFAIK, this in turn has some other security implications, as to use AES the secret key should be shared between the user and the server. If I set the same password for all users, simply breaking the app with some decrypting tool they could get the AES key + using an application like you mentioned I have the same issue. If I generate an AES key for each user, then I somehow have to share it with the server, so the password would be sent simply over TLS and again is there the same problem. So how to deal with this?
    – nKn
    Commented Apr 11, 2015 at 19:30
  • @nKn, I'm not sure I understand your concern here. You can use encryption on top of TLS for your apps transmissions and you can use the same key for this encryption safely. No, users should not have the same "password"; however, I'm a bit confused as to why you even want them to have a password if they do not know it. Why not just use a session with a session token that's stored client-side?
    – Spencer D
    Commented Apr 12, 2015 at 0:12
0

You should NEVER use state based authentication(user name and passwords) for a stateless based application. Always use stateless authentication.

Stateless authentication is a great way to do this since you can make each request a new request with a new state that eventually dies. Also just check to make sure that if another request comes in with the old token, that you kill the box immediately(build a panic mode). This would then make it so that to get this information and abuse your service, a user would have to reverse engineer your application.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .