How should one properly secure a "password reset" feature?
Ooh, I think I can actually do this: You send the address on file an email which contains a random, time-limited, one-use token which allows them to log into their account. You should not disclose presence or absence of the account via the reset mechanism on the site (only via email), but that's a comparatively minor issues. A successful password reset should end all in-progress sessions for the account. You should also do all the table-stakes web development things like e.g. not allowing SQL injection or XSS on the page.
There's plenty of failure conditions for password resets:
1) You create non-random reset tokens, such as MD5(user.id) or MD5(user.email), potentially compromising security of accounts.
2) You allow resets of your teams' admin accounts to happen through the publicly accessible password request feature. (n.b. Almost never a good idea, for one because it means you're probably doing shared authn/authe between your app and your admin console and that is generally a very bad idea. I say this in spite of shipping it in every product I write.)
3) You allow password reset tokens to get re-used, which increases the attack surface against individual accounts by e.g. making saved-to-disk emails into attack vectors for them. (Standard reset mechanisms only make emails-in-flight into attack vectors.)
> You allow resets of your teams' admin accounts to happen through the publicly accessible password request feature. (n.b. Almost never a good idea, for one because it means you're probably doing shared authn/authe between your app and your admin console and that is generally a very bad idea. I say this in spite of shipping it in every product I write.)
Can you please elaborate more, or link to articles about why this is a bad idea? What are the common failure scenarios that splitting normal & admin users fixes?
Briefly: there are a lot of common vulnerability classes which can compromise a user of your application / their cookie / their DB record, for example mass assignment (to update the "role" attribute in a free trial account to "admin") or XSS (tweet at your support account and have them click a link to your domain, bam, the adversary now has your cookie and can log in as you).
Separating the admin app and the normal app upper-bounds the impact of those flaws at something lower than "The worst thing someone could possibly do with the admin console." Given that many admin consoles have fairly extensive functionality, that's generally a good idea. (I mean, my businesses are pretty low risk as things go, and my admin consoles would trivially do about $20k of damage just with refunds if compromised.)
Ooh, I think I can actually do this: You send the address on file an email which contains a random, time-limited, one-use token which allows them to log into their account. You should not disclose presence or absence of the account via the reset mechanism on the site (only via email), but that's a comparatively minor issues. A successful password reset should end all in-progress sessions for the account. You should also do all the table-stakes web development things like e.g. not allowing SQL injection or XSS on the page.
There's plenty of failure conditions for password resets:
1) You create non-random reset tokens, such as MD5(user.id) or MD5(user.email), potentially compromising security of accounts.
2) You allow resets of your teams' admin accounts to happen through the publicly accessible password request feature. (n.b. Almost never a good idea, for one because it means you're probably doing shared authn/authe between your app and your admin console and that is generally a very bad idea. I say this in spite of shipping it in every product I write.)
3) You allow password reset tokens to get re-used, which increases the attack surface against individual accounts by e.g. making saved-to-disk emails into attack vectors for them. (Standard reset mechanisms only make emails-in-flight into attack vectors.)