130

By itself, the rule of only allowing one password change per day adds no security. But it often comes in addition to another rule that says that the new password must be different from the n (generally 2 or 3) previous ones. The one change per day rule is an attempt to avoid this trivial perversion: a user has to change his password because it has reached ...


104

Lets say an attacker has your password. You log in and reset it. If the reset doesn't invalidate all existing sessions, the attacker still has access, as long as they don't let their session expire. The reset hasn't actually achieved anything in this scenario. Depending on what the site does, there could also be issues with having you signed in under a ...


102

Don't indicate that the attempt "failed". A user (legitimate or otherwise), asks for a password reset link, and gives you an email address. All you should say here is along the lines of Your submissions has been received. If we have an account matching your email address, you will receive an email with a link to reset your password. The user will still ...


86

Yes. This is a problem - a big problem. Lately I found a design flaw in a business' webshop that allowed me to insert innocent notes in other visitors' charts. Seems innocent, and only annoying, until I looked further and found that I was also able to insert Javascript code (XSS) into those notes. So in other words, I could exploit XSS on every visitor's ...


71

Use HTTPS only for this, and then we'll get onto details of implementation. First of all you're going to want to protect against user enumeration. That is, don't reveal in the page whether the user exists or not. This should only be disclosed in the email itself. Secondly you will want to avoid referrer leakage. Ensure no external links or external ...


61

You pretty much hit the nail on the head when you said that you need physical access to the machine. If you have physical access, you don't need to go through the official steps to reset the root password, as you can flips bits on the hard drive directly, if you know what you're doing. I.e., you can boot up a recovery OS from a DVD or flash drive, and ...


59

Your question is: Are security flaws acceptable if no much harm can derive from them? The answer is yes, if decided by business while understanding the consequences. What you are doing is called a risk assessment. For each risk you must highlight the consequences for your company when it is instantiated. Based on that assessment you (you = someone who has ...


52

To, answer your question, Yes, you can and SHOULD log password-changes, and there's nothing fundamentally wrong with doing so, as long as you don't e.g. record the password itself" What to log? When designing logging for Security purposes you want to address these questions: When did the event happen? The date and time the event occurred (Use the common ...


52

This is what I usually do: The user asks for a password reset. The system asks for the registered email. The user enters email, and no matter if email exists or not, you say that you sent a reset link. The server stores email, expiration and reset token on a reset_password table When the link is accessed, expiration is checked and a form to reset the ...


45

This is a known problem without an existing solution. Some password management tools are working on it, but it is not complete or fool-proof. For example: https://helpdesk.lastpass.com/generating-a-password/ Auto-Password Change will change a site’s password with a single-click. This feature currently supports 75 of the most popular websites. You ...


43

Protecting sessions on possibly compromised account There is no need to actually redirect to the login page if session management upon password change is done securely. That is, as long as all current session identifiers are invalidated and the current session is attached to a new session identifier (usually issued as a token in an authentication cookie - ...


42

Since this question is not a technical one, rather more about human behaviour, you won't get the answer. What you describe is very typical though and I made the same experience. Complex password rules will usually not lead to more safe passwords, really important is only a minimum length, and a check against a list of the most used passwords. People cannot ...


35

No, not really - they all have different processes for verifying your identity for password reset requests, and there isn't any standard for bulk password resets. For example, Apple may use a device which is registered to the account as a confirmation that it's you sending the request, while Facebook uses different schemes depending on whether you're ...


34

The other answers are probably more correct from a netsec perspective, but I wanted to add that you also get to make sure that the user is actually able to log in with their new password. This makes it obvious if something is going wrong, like the browser autofilling an old password. It also prevents users from using the password reset as a login. On one ...


34

In addition to what nobody said there's a more practical, but mostly internal, requirement here. Changing a local password in Windows without knowing the original password is called a reset. Resets cause DPAPI keys to be invalidated (because they're protected by a primary secret based on the user password). Once the reset happens those original keys are dead ...


32

The reason for this finding is that a user gets different responses, depending on the existence of the email address. This can be as simple as telling them that the address is not known, or something more subtle in the response. The easiest implementation to avoid this kind of problem is giving back the exact same response, no matter whether the email ...


31

The problem that I see with such a simple password reset scheme is that it suggests further vulnerabilities in the platform. A flawed concept of security is rarely so isolated as to only happen once, since such flaws are usually related to a developer's practices regarding security. At minimum, I'd suspect that their internal login procedures might also be ...


27

How is this not a glaring security vulnerability? It is. Physical access to your system is the ultimate vulnerability. Is there a way to disable this 'feature' so that it cannot be changed from GRUB like this? Can you do this in all other Linux distros as well? Or is this a Redhat exclusive ability? Make yourself aware of what is happening here: ...


26

Yes, you should hash password reset tokens, exactly for the reasons you mentioned. But no, it's not quite as bad as unhashed passwords, because reset tokens expire and not every user has an active one users notice when their passwords are changed, but not when their passwords are cracked, and can thus take steps to limit the damage (change password and ...


26

Technically, this is a question about how you should implement 2FA (or how you should expect it to be implemented), since there's nothing inherent in 2FA that answers your questions in either direction. With that said, there are certainly best practices. 2FA (or multi-factor authentication in general) should apply whenever the user is being asked to prove ...


24

Other answers have covered possible security benefits, however one significant drawback occurs to me: if an attacker takes control of an account and changes the password, they are guaranteed a minimum 24 hour window of access, during which the legitimate user cannot regain access to their account and lock out the attacker. Worse, by changing the password ...


20

As an addition to the answers above (Would be better suited as a comment but can't do that yet) another step the hacker can take is to measure the TIME of your response to the form. It might take you 10ms to determine the email doesn't exists, while it takes you 100ms to generate a reset link and send an email. The hacker can know if the response is slower ...


20

What are we protecting against? First of all one should ask what they are protecting against exactly. In this case there are two different threats: Threat 1 An attacker brute forces random emails to find valid registered emails. This could be theoretically used to create spam lists, but as far as I know has never been done as it's simpler to just sent the ...


17

No, there is no overwhelming need to hash password reset tokens, as long as they are time-limited and single-use. There's some benefit to hashing reset tokens, but the benefit is less than with passwords, so I wouldn't consider hashing of reset tokens absolutely necessary. Typically, password reset tokens are time-limited. For instance, they might be good ...


16

If I see this scenario right, they can change E-Mail address and password of any account, then start a repair-form and continue the repair-process via mail. The support team will probably assume that the E-Mail address is legit and sensitive information can be exchanged with the recipient - and if it is a know customer, you might even start working on an ...


16

You should not trust the client. So if the client is able to send their username during the stage where the new password is entered, what happens if they change the username to someone else's? They will be able to reset the account of another user and take over the account. @ThoriumBR's answer is of course correct. Another option is to store no state on the ...


15

No, this is a steaming mess. In fact it would be a misnomer to even call this 2FA. Really what you've done is eliminate one of the factors and this is closer to side channel authentication than two factor authentication. In addition to not having a proper second factor you've created a system with unnecessary complexities and a non-standard interface. This ...


14

The best solution is to train your user base to use passphrases. Passphrases are easier to remember, easier to type - and harder to crack. And the NIST rules that @martinstoeckli mentioned are designed to be passphrase-friendly. Five random words, drawn from a dictionary of at least 20,000 words or so, would be a nice middle ground. Training will be key, ...


13

Your line of thinking is on the right track. However, I would suggest describing the flow for your forgotten password functionality from one step earlier. Somebody claims to have forgotten their password, you need to make sure you identify that this person is indeed the owner of the account for which you will start the password recovery procedure. The flow ...


Only top voted, non community-wiki answers of a minimum length are eligible