4

I am creating a mobile app where my password recovery feature involves sending a password recovery code (randomly generated string) to the user's email address. They get the code, then enters it within the app. The webservices check if the code is valid (this expires after 24 hours) and then if it is, the app takes the user to update their password.

I would use a password reset link but I'm not great at programming and I'm looking at alternatives for now.

In terms of security, is sending the randomized code to the user's email just as bad as emailing the password in plain text? Even though I will be using the Blowfish cipher to encrypt the code when it is stored in the database?

To clarify this is asking about emailing password recovery codes/tokens and not about passwords

Theman
  • 149
  • 2
  • If anything, you could call it a dup of this question: https://security.stackexchange.com/questions/1918/can-anyone-provide-references-for-implementing-web-application-self-password-res – Mike Ounsworth Mar 17 '16 at 18:15
  • @drewbenn I was referring to emailing the original password. But I would imagine emailing a newly generated password is equally as dangerous as emailing the original password? – Theman Mar 17 '16 at 18:33
  • 1
    @MikeOunsworth How are they not dupes? – Xander Mar 17 '16 at 18:48
  • @Xander ah, I see Ulkoma edited his comment to change the question he was linking to. Now it's a good fit. – Mike Ounsworth Mar 17 '16 at 18:58
  • @MikeOunsworth Ah, no wonder I was confused! – Xander Mar 17 '16 at 19:02

3 Answers3

4

No, it's not as bad. Personally, I'm not a huge fan of using email as a password-recovery mechanism just because there are so many "what if"s, but lots of respectable sites do it, so shrug.

The reason it's not as bad is that if you email a password, the attacker will have silent access to the account and the user will be none-the-wiser. And as @drewbenn points out, it also compromises every other site for which the user uses the same password, helps attackers build dictionaries around password patterns (if any), etc. With a recovery code, the code should be one-time use, and the user will know very quickly if it's already been used.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
1

I think you're asking the wrong question. This was touched on in the comments on your question; you confirmed you're asking about sending a reset code vs. sending the original password in plain text.

If you are even able to send the user their password, then your code is not secure. You should never be able to recover a user password if you are doing things correctly. You should have a slow, one-way hash of the password stored, along with a salt. It is not possible to recover a plaintext password from a slow one-way hash. That is the entire purpose of using them.

So I'd say: it's definitely more secure to send a reset code in email than a plaintext password. Because, if you can send a plaintext password, your system is necessarily insecure by that very fact. But there are ways to send reset codes without your entire system being flawed, so at least if you're doing that, there is hope of security.

Ben
  • 3,846
  • 1
  • 9
  • 22
  • most sites that email passwords generate a random *new* password on the fly, and email that new password out. I agree with your last paragraph if a site sends the existing password without generating a new one, but I doubt that's the norm. – TTT Mar 17 '16 at 19:09
  • While you're probably correct in general, the OP clarified in the comments "I was referring to emailing the original password. But I would imagine emailing a newly generated password is equally as dangerous as emailing the original password." So in this case, this answer applies. – Ben Mar 17 '16 at 19:11
  • Sorry, I missed that comment. Wow, ok. Big difference. – TTT Mar 17 '16 at 19:13
0

How the code is stored in the database is (almost) completely irrelevant given the transient nature of these codes, especially since if someone already has access to your database to find these values, they could probably do a lot more damage than just resetting people's passwords; they're only slightly more "dangerous" than knowing a user's login name. Sending the value in plain text is perfectly fine, so long as it expires once the password is changed successfully or the timer expires (24 hours, as you've noted). From a UX perspective, I'd suggest not expiring the ticket until a successful change, because a poor network connection could cause the ticket to become invalid without the user being able to reset their password. Of course, you'd want to send an email and preferably a second communication (say, SMS) once the password changes.

phyrfox
  • 5,724
  • 20
  • 24
  • If you don't expire the tickets until a successful change, you lose the transient nature of it - it would be possible to try break the token with no limit on it expiring if, for example, the email ended up in a spam bin. – Matthew Mar 17 '16 at 18:27
  • @Matthew I think you're misunderstanding the purpose of a token. You should definitely expire *all* tokens if more than some number of attempts occur on a given user account, the same as if it were a password. However, entering the right token allows the user to change the password, after which point it's invalid, maintaining the intended nature of the token. You can't "brute force" the token itself, because you'd already know what it was, or you'd max out the reset attempts per time window. – phyrfox Mar 17 '16 at 18:37
  • That's not what you've said in your answer: you've said not to expire it until a successful change. I'd say that you expire it after a fixed period, whether it has been used or not - the UX comes down to "a legitimate user wants to change password, so will check email soon". Even a 60 minute token validity is fine, since if they haven't changed the password in that time, it's probably better for them to restart the process (since they have given up on the change for now). You should warn them of this time limit though. – Matthew Mar 17 '16 at 18:40
  • @Matthew A change *or* the timer expires. The natural assumption is whichever comes first. – phyrfox Mar 17 '16 at 18:41
  • @Matthew Not expiring as soon as the page load prevents all sorts of UX annoyances. I couldn't "authorize" my TurboTax account on my phone without my laptop handy, because checking my email reloaded the page and wiped out my token prompt, for example. Or if you have spotty WiFi or cellular and the page load was interrupted. Or you accidentally typed the password verification wrong. Any number of things. But you don't know if the token is correct until you Blowfish it and compare to the database anyways, so there's no way to expire *the token itself*. – phyrfox Mar 17 '16 at 18:44