I have an application that sends username and a password by email (random temporary password, mandatory change on first login).

A big customer has this policy of "never send username and password in the same message" - and they are demanding a change in order to split it in two email messages, one containing the username and other with the password.

I would understand if the demand was to send information using distinct channels, lets say, send the username by email and password by SMS, because compromising both channels is harder. But sending the information splitted in two messages over the same channel makes no sense for me: if you think your email can be compromised, you must assume the attacker will be able to read both messages, so what is the fracking point?

Is there any logic behind this policy?

  • 1
    For what it's worth, the U.S. federal government does this across the board. It's a very CISSP-y thing to do. – Mark E. Haase Feb 2 '15 at 16:02

I would characterize this security recommendation as Cargo Cult Security. I don't know of an exploit that only compromises a single email. There isn't a weakest link that is being removed by sending this in two emails, its just annoying as hell to users.

A temporary password or token passed as a GET parameter is commonly sent via email. I have never seen this process broken into two emails.

I would ask the security analyst that recommended this change to give you a specific scenario in which this improves security.

  • 3
    We used to send a link but many users are indoctrinated into never following email links (too dumb to detect phishing) - they prefer to cut & paste, our A/B tests shows that sending a random passcode instead of a link reduced support calls in 25%. – Paulo Scardine Sep 19 '13 at 0:02
  • 3
    @Paulo Scardine interesting, I think that sending two emails will see a massive increase in support calls because no one has ever encountered this before. – rook Sep 19 '13 at 0:05
  • 2
    @PauloScardine fascinating. You could collapse the username and password into one single authentication code. e.g. "ea3738b431a564ad8cc70a826e0066b8". This way you only need a single email and the security of human-selected usernames for logins has always iffy to begin with. – LateralFractal Sep 19 '13 at 0:09
  • @LateralFractal: great idea! – Paulo Scardine Sep 19 '13 at 0:14
  • @LateralFractal that would solve this checkbox... but my argument is that this doesn't make the system more secure it doesn't prevent a real world attack. – rook Sep 19 '13 at 0:15

Sounds like a checkbox item on an audit list.

I don't see any true security other than perhaps making it harder for the user to accidentally forward on both emails to the same third party or mailing list. Anything cryptic enough about the emails to decouple them from each other would also make them harder for the user to use. Besides, unless the user gets a profound amount of spam, the two emails will also be directly sequential in the user's inbox regardless of how dissimilar the emails pretend to be in content and origin.

You can sidestep the audit problem if your application has a website - just include a one-shot account creation URL that takes the user to a HTTPS page for entering the new password.


For the most part, you are exactly right about the policy only making sense when the second message is sent out of band. There are cases I can think of that benefit from splitting the pair across two emails:

  1. An attacker may be able to use to username + original password to more easily social engineer their way into your account through customer support. The username email can be archived and the password one deleted. Though if they control your email account then they can probably just do a password reset.

  2. Out in the wild of the Net, the routes that message packets travel can vary significantly. If that route ends up going through a less-than-reputable router, it could record the username/password pair. Separate messages can take separate routes.

  3. Eavesdroppers, for instance when someone checked their email on the Starbucks WiFi. If they don't open both together, then there is less chance of both being recorded.

Yes, 2 can be significantly mitigated by sticking to services that exclusively use HTTPS and 3 is addressed completely by it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.