Timeline for How does changing your password every 90 days increase security?
Current License: CC BY-SA 3.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 21, 2019 at 16:50 | comment | added | clickbait | Changing your password can slow down a brute force attack. The new password may be a guess that the hacker has already tried, or a guess that will take a longer time to get to. | |
| Mar 15, 2017 at 8:49 | comment | added | Andrew | @Stef Heylen I am curious if forced changing passwords regularly leads to the use of weaker passwords. It could mean that bruteforce attacks online and offline are easier with changing passwords. e.g. if the bruteforce window changed from 10 years to 30 days (which although unlikely a small reduction in complexity will lead to a parabolic drop in time to crack). Then changing passwords COULD reduce security. I suspect that any reduction IF there is one does not have a large enough effect to reduce security, but I would be curious to see if this has been studied (difficult to get data...). | |
| Nov 7, 2016 at 14:43 | comment | added | Bobort | In regards to this: "The probability that the attacker’s next guess is correct is the same..." attackers can create more sophisticated algorithms to guess the next password within a short amount of time. A UNC study found that an attacker who used such an algorithm to learn a previous password could guess the current password in 41% of accounts within 3 seconds per account. So, I guess the probability is the same, but a more reasonable statement would be, "It depends..." ftc.gov/news-events/blogs/techftc/2016/03/… | |
| Jan 13, 2016 at 8:31 | comment | added | Stef Heylen | This answer is BS. Password expiration DOES help against offline bruteforce attacks. Ofcourse it doesn't against online bruteforce attacks (since there the probability is indeed the same) however there are other counter measures at that level (e.g. account lockout after 10 wrong login attempts). | |
| Jan 22, 2015 at 20:51 | comment | added | Marsh | @BenVoigt Heh. That's what I get for reading only some of the comments. | |
| Jan 22, 2015 at 20:43 | comment | added | Ben Voigt | @MartinCarney: We've already had that conversation 4 years ago | |
| Jan 22, 2015 at 19:42 | comment | added | Marsh | @BenVoigt You can make permutations of the new plaintext password, hash them, and compare the hash to the old password hash. It's not very fast or efficient if you're checking more than, say, 10 or so permutations. But for small sets, it could work. For example, if the new password is "portland11", you could hash and compare "portland10" to see if they're incrementing the number on the previous password. | |
| Aug 30, 2012 at 16:44 | comment | added | derobert | @BenVoigt During a password change, you typically prompt for both the old and new password. So, you have both available, and can check for similarity. | |
| Jun 23, 2011 at 13:20 | comment | added | Chad | @graham For the most part I agree that simply forcing a change of password every 90 days does little if anything to improve security. However if this is complemented by a good algaritham to force a unique password each change (IE no incrementing reordering) it can help reduce your companies vulnribility to access from comprimised passwords on other sites. Though I have only worked at one place that had anything like this type of policy. | |
| Jun 23, 2011 at 10:45 | comment | added | AviD♦ | @Sheeo we're really starting to get offtopic here, CAPTCHAs are a big topic by itself. There are already some questions here discussing this... But my claim, in short - CAPTCHA solves the wrong problem, badly. | |
| Jun 23, 2011 at 9:56 | comment | added | Michael Sondergaard | @AviD♦ Uhh. How so? CAPTCHAs are designed to not allow automatized input, so if the captcha is good enough, it'll certainly fend off a direct brute force attack. | |
| Jun 23, 2011 at 8:52 | comment | added | Ben Voigt | @dannysauer: Password reuse can prevent reusing the exact same password. It can't detect "differ by only a character or two", assuming any secure hash function. You don't think the passwords are stored in plaintext so you can compare them to the new one, do you? | |
| Jun 23, 2011 at 8:50 | comment | added | Ben Voigt |
@Kevin: "install a back door" doesn't mean creating an account. Adding a line to ~/.ssh/authorized_keys might be enough.
|
|
| Jun 23, 2011 at 8:36 | comment | added | user185 | To comments that it's to protect against offline brute force attacks against your password hashes: your directory server is probably more valuable than that. I'd try to help my users by putting in exfiltration detection on that system. | |
| Jun 23, 2011 at 7:58 | comment | added | AviD♦ | @Sheeo direct brute force attacks cannot be fought with CAPTCHAs - "time limiting authentication attempts" (i.e. throttling and lockout policies) only can do the job. | |
| Jun 22, 2011 at 22:57 | comment | added | dannysauer | @Kevin: how about a Unix system. You get into a user's account, and edit .profile to include "alias passwd=$HOME/.tmp/passwd" or just prepend $HOME/.tmp to the $PATH where the passwd under .tmp is a shell script which emails the password to my throw-away hotmail account and runs the system password command? No elevated privileges required, but there's now a simple back-door in place which keeps the account compromised. | |
| Jun 22, 2011 at 22:54 | comment | added | dannysauer | @Wolf - The bank you worked in should have a better password reuse policy which requires the new password to differ from the old by more than a character or two. And it should have been comparing passwords to a dictionary so people didn't use proper nouns / words. | |
| Jun 22, 2011 at 20:39 | comment | added | Signal | Most users increment a number at the end of their password. I've worked in a bank and a common password was the name of the city followed by the number of the current month. Also, since most systems are inherently insecure, especially in a Microsoft Windows environment, it does not really matter if the user is limited or not, and it most likely is not that limited anyway. | |
| Jun 22, 2011 at 20:34 | comment | added | Michael Sondergaard | And by the way, direct brute force attacks are fought by time-limiting authentication attemps and captchas, not this policy. | |
| Jun 22, 2011 at 20:29 | comment | added | Michael Sondergaard | This is plain wrong. We know that the attacker might have a hash of your password (Which is the reason for this policy in the first place)--which essentially gives him your password given enough time, regardless of the method he uses to crack it with. Replacing your password will thus invalidate the information the attacker has. The answer above sums it up. | |
| Jun 22, 2011 at 14:38 | comment | added | kemiller2002 | I would agree with this except in the instances of non-admin users. Most people probably don't have the authority to create back door accounts etc. When gaining access to a system my goal may not to try and take it over, but to gain access and steal information. As long as I have the account password, I can have access, but I don't want to do anything that might look suspicious (like creating an account). As long as the user doesn't change the password, I don't have to try and hack the account again. Changing the password to something non-predictable causes extra work for me. | |
| Jun 22, 2011 at 13:42 | history | answered | user185 | CC BY-SA 3.0 |