We’re rewarding the question askers & reputations are being recalculated! Read more.
128

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 ...


106

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 ...


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 ...


66

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 ...


58

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 ...


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 ...


42

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 ...


33

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 ...


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: ...


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 ...


23

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 ...


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 ...


15

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 ...


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 ...


13

Send a unique string of text, a.k.a. a token (cryptographically secure, randomly generated), to the user via some other band besides e-mail, such as SMS or even snail mail. They can change their password in your app only if they input that token in a Web form on your site. Or use physical devices, like SmartCards, that all users must have in order to use ...


12

Basically, people are rubbish at coming up with questions. They come up with things like "Type 'secret'" or "My name" - they're worthless at best, and actively harmful at worst ("Usual password" - the answer to the question will tend to be stored in plain text...). Even pre-determined questions are fairly bad - they tend to either be easily guessed, or ...


11

Help everyone in your organization use a good password manager. (I should disclose that I work for the makers of a very fine password manager.) Seriously, you have a password management problem, and using a password manager within your organization is the best shot at addressing it. This is what password managers are designed to deal with. Addressing ...


10

This might be a problem without a really good solution. Here are some suggestions. They all fall in two groups - not very effective but practical (1-4) or effective but a bit unpractical (5-6). Please note that they could, or perhaps should, be used in combination with an ordinary email. Limit the amount of time the token is valid. Check that the IP that ...


10

I can't give you a reason not to log something; you have to give me a reason why you need to log it. You can theoretically log everything the users does, (down to mouse pointer movement, clicks, and when a window is the foreground or not). But, do you NEED to log everything? Can you log everything without sacrificing performance? Can you store the logs for ...


9

When something like a password is changed on a distributed system, it may take a while for the change to take effect. If multiple change requests could be pending simultaneously, extra code complexity would be required to ensure that they are all resolved correctly, especially if the requests are required to include information about the old and new ...


9

I would argue that yes, you should invalidate them. The email change may be because the email account is compromised. And there is no harm in invalidating them, as the user is clearly logged in and can just request another one if they need to. That being said, it is much more important to send a verification email to the old mail before you allow a change ...


9

... the real outcome of such policies/controls are not achieving the desired outcome. Exactly. You have good identified that. 1. Review your password policy. Consider what exactly are you protecting and what would be consequences if an attacker finds out a password. If password gives only an access to your parking slot, it is not so harmful, a pretty ...


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