12

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?

LateralFractal
  • 5,143
  • 18
  • 41
Paulo Scardine
  • 223
  • 3
  • 9

4 Answers4

12

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.

Community
  • 1
rook
  • 46,916
  • 10
  • 92
  • 181
  • 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 00: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 00: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 00:09
  • @LateralFractal: great idea! – Paulo Scardine Sep 19 '13 at 00: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 00:15
  • @Rook: thanks for the Cargo Cult Security link. Good to have a name for this silliness. – Paulo Scardine Sep 19 '13 at 00:19
  • @Rook Yes the credentials may be human and weak however they're stored. So one hopes that two-factor authentication is an option. – LateralFractal Sep 19 '13 at 00:45
6

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.

LateralFractal
  • 5,143
  • 18
  • 41
2

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.

SecsAndCyber
  • 616
  • 5
  • 4
-2

I was thinking of doing something like this. i.e. send an account Id by email and then when users log in for the first time they receive a temporary code by a separate email and then after they've submitted that they must set a password.

The logic is that if the login code is in the original email and it expires or is reset then the original email contains a valid account Id but also an invalid code. Whereas if the login code is sent separately then the original email is always completely up-to-date.

Additionally, if the login code is always sent using a separate email then if it expires or is reset then it's always delivered to the user the same way. i.e. not in the account email to begin with and then in a different format email from then on.

So it's normalisation for emails... one account - many tokens.

This may not be the logic that the customer in the original post had in mind but I think it's logical nonetheless - more UX than security.

Ian Warburton
  • 1,147
  • 1
  • 10
  • 16