1

I'm of the opinion that HTTPS is sufficient for securing passwords from would-be MITM (man-in-the-middle) attacks, but I'm curious to know if there's anything else I should be doing.

During signup, the password is collected on a server that forces HTTPS. Since we collect the password from a form in jQuery from the password input using something similar to

newpass: $("#newpassword").val(),

and then send that via AJAX POST to a call for something similar to:

password_hash($newpass,PASSWORD_ARGON2I);

I'm wondering if that's all I need, or if there's a way to further reduce vulnerability in the web-based app.

2

There's not really anything else major you can do. There's a few minor things, which I'll get to, but the basic pattern you describe is used near-universally for good reason. Just based on the steps you describe, if somebody were to have their credentials compromised, I would very strongly suspect it to have nothing to do with your HTTPS or password handling, and to be much more likely due to a largely-unrelated issue such as credential reuse on a compromised site, phishing, SQL injection, remote code execution on the server, XSS on the login page (or in a context where the user could be convinced to enter their credentials), or so on, in roughly descending order of likelihood.

The things you can do to improve your login security fall into a number of rough groupings, which I'll lay out below. For any given item, if you want more information about it, I suggest looking for (and asking if needed) other security.SE questions and/or general search results.

  • Considerations about the credentials themselves:
    • Support and encourage multi-factor authentication, ideally using things more secure than SMS.
    • Prohibit the use of common passwords, identifiable from past breaches.
    • Instead of arbitrary "complexity" requirements on passwords, just have a reasonable minimum length and encourage the use of passphrases and/or password managers.
    • Avoid forced password rotations for arbitrary reasons like passage of time, but immediately lock any credentials suspected of being compromised.
    • Any password-reset or direct-login links should be short-lived and ideally single-use (they are effectively credentials while valid).
    • Don't allow the use of things that are weaker than passwords, such as SMS or "secret questions" (actually, don't use the latter at all), as alternative credentials.
    • Consider allowing highly-secure physical-token based authentication (such as using a Yubikey) as an alternative to passwords.
    • If relevant, consider allowing authentication using secret tokens (like how AWS secret keys work) as an alternative to passwords, especially for programmatic access.
    • If practical, consider allowing public key-based authentication (TLS client certificates and/or SSH public key auth) as an alternative to passwords.
    • Consider requiring additional authentication (especially if the user is using a relatively weak single factor, like a password) when logging in from a new device or region.
  • Considerations about transport security:
    • Use HSTS, on all domains and with preloading, to prevent SSL-stripping attacks and possibly others.
    • If you have client apps, consider using public key pinning (consider also HPKP for browsers, though it has very little support now).
    • Ensure you support the latest standardized TLS protocols and cipher suites, and not any deprecated ones.
  • Credential hashing and storage:
    • Use parameterized queries / stored procedures, and/or bound variables, instead of constructing database queries (in SQL or a non-SQL language) using string concatenation or similar.
    • Consider using a secret salt ("pepper") that is stored outside of your database when hashing passwords.
    • Consider using an HSM of some sort to store the pepper (and other secret keys).
    • Periodically update your hashing algorithm (at least the work factor(s)) to keep it as secure as possible.
    • Consider encrypting your database using an externally-supplied key so that a copy of the DB (for example, from a backup) is useless to an attacker.
  • Password change considerations:
    • Check for common / compromised passwords at all password changes, not just at initial account creation.
    • Consider checking for weak passwords periodically when a user logs in, and updating the banned password list as new breaches come to light (force users to change weak passwords).
    • Password reset needs to be at least as secure as password authentication (for example, no allowing single-factor auth for password reset if you require multi-factor when using a password to log in).
    • Require the old password when adding or changing (as opposed to resetting) any credentials (including passwords but also things like public keys).
  • General web security:
    • Keep pages that interact with credentials as simple and well-reviewed as possible, to avoid things like XSS risks.
    • Be especially careful of open redirects from login pages, as they can be useful for phishing attacks or even for XSS that is able to steal the credentials directly.
    • Consider including CSRF protection on both log in and log out actions, as otherwise an attacker can potentially "plant" their own session on a victim (which is less serious than stealing credentials outright but can have an affect similar to session hijacking).
    • Create a highly-restrictive Content Security Policy and enforce it as soon as you can.
    • Ensure you keep all programs and libraries (including OS, web server, application framework, and third-party libraries on both client and server) up to date, and monitor security disclosure lists for announcements of vulnerabilities in packages you use.
    • Ensure any third-party libraries you use come from reputable sources, and consider reviewing them yourself and then freezing their version to avoid supply-chain attacks.

... I could go on for a while. Auth is hard, and security in general is even harder.

  • After some cursory research on HPKP, it seems that Google recommends using the Expect-CT open standard as a safer alternative to HPKP, and many browsers seem to be following that. However, adoption isn't even close to universal. – JediGanesh Jul 18 at 0:34

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.