0

I'm working on an app where some accounts use passwordless authentication by email (using magic links) and some require a password to login. Is it okay to represent this rule in the account table by having a nullable password_digest? Would the application be more vulnerable to attack if and attacker knew which users have set a password and which ones haven't?

9
  • 1
    In my opinion there is only one correct answer to this question and it goes like this: Yes! It is unsafe.
    – Jeroen
    Commented Aug 25, 2020 at 20:18
  • @Jeroen Thanks, are you able to describe the vulnerability in more detail and prescribe a solution? Should I hash a randomly generated password for the password_digest on all accounts upon creation?
    – RackAttack
    Commented Aug 25, 2020 at 20:22
  • Having no password for user accounts is a design flaw. An attacker could attempt to send a large amount of usernames / email addresses without sending a password. Depending on the response of the application, the attacker could programmatically determine whether the username is correct or not. As far as the randomly generated passwords, I'd lock the accounts first, do a password reset by the user that was created and send an email to set a password using a temporarily generated link. If all is done successfully, unlock the account and it is ready for use.
    – Jeroen
    Commented Aug 25, 2020 at 20:26
  • Passwordless authentication via email? Like, there's only the email, or you are using magic links?
    – ThoriumBR
    Commented Aug 25, 2020 at 20:27
  • 1
    I suggest you update the question with this information about magic links @CanadaIT
    – Jeroen
    Commented Aug 25, 2020 at 20:32

2 Answers 2

1

I don't see any problem with this, as long as there is no way for the user to generate a null password digest when attempting to log in.

Otherwise, magic links are no less secure than the access offered by the password reset feature on most sites already. You could even argue that having no passwords is more secure, since there is no longer a secret that can become compromised (assuming the email account is better protected).

3
  • Would it be preferable to give every new user in the database a password digest generated from a random string, or give all new users a blank password digest? My theory is that the latter is a better option because it reduces the attack surface. An attacker could (again, theoretically) not gain access by breaking the password, their only option is to break into the user's email. Am I correct? To me this seems the same as any application with single factor authentication.
    – RackAttack
    Commented Aug 26, 2020 at 2:42
  • @CanadaIT well, a random digest may be guessable/brute-forceable, whereas a blank one is probably not forgeable. Commented Aug 26, 2020 at 11:43
  • @CanadaIT I'd say more code == more attack surface. It also means more code to maintain. As long as your password checking mechanism accounts for null passwords, which sounds pretty trivial. Random password generation isn't always completely random depending on the mechanism you use, and I'd trust a null check if all else is equal. Commented Aug 26, 2020 at 19:17
0

I would have a chat with your client regarding this "business requirement". The design does not look sound, if at least there was a good reason ? The problem is that you start with a flawed model, and then you wonder about the possible issues and try to find workarounds for the problems stemming from that design.

It shouldn't be like that. Keep it simple and secure - KISS. Don't make the job more difficult than it should be. Devise one common authentication scheme for all users, not two.

Technically speaking, there isn't much difference between the two. The 'passwordless' option is actually a token, so it's like a one-time password that has to be changed every time.

I am not in your shoes but if I am presented with unreasonable requirements I may very well walk away because I only do quality work and I don't want to endorse bad ideas. Also, in case of a data breach, you could be held liable for the vulnerabilities in your code, if the implementation turns to be insecure. Not your idea, but your code.

Notwithstanding the possible security issues there are practical concerns too: an E-mail can be delayed, or never arrive because it was trapped as spam. Then the user is stuck. What a brilliant idea. I would reconsider it.

Security issues: I don't see any obvious issues ATM but the devil is in the implementation. Inevitably, this kind of design allows targeted DDOS: if you know the username/E-mail of someone, you can send automated requests for a token non-stop, and the user will not be able to login as a result. Thus, you've created an attack vector that didn't have to be there.

You must log in to answer this question.

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