I use Windows 7 on a Lenovo laptop. When I enter a wrong password, either when I'm connected to our network or when disconnected, it takes quite a lot of time for Windows to report the password is wrong. And by 'a long time' I mean as much as 20-30 seconds sometimes. Now, even, say, 5 is a lot, I would say - so whatever I can do to reduce this, I want to do (including any artificial security-related delay for incorrect passwords).
asked Aug 23, 2013 at 20:36
-
5Have you seen this (over on ServerFault) yet? Why windows 7, “wrong password ” takes long time? I think the answer to 'how to reduce it' is: "You can't, it's a security feature hard-coded into the OS".– Ƭᴇcʜιᴇ007Commented Aug 23, 2013 at 20:48
-
3Those answers are ridiculous. That's not 'quick'. If you can enter a password - even using some computerized keyboard replacement - once every second it would still take you a ridiculous amount of time to brute-force anything. Plus, the delay could be on the 3rd, or 5th, or 10th attempt onwards. ... but regardless of this, none of the answers there says "hard-coded"; plus we're dealing with a delay that's longer than what I experience on other machines.– einpoklumCommented Aug 23, 2013 at 21:21
-
1Sorry you don't like standard security features. Just don't enter bad passwords and you'll be ok. Keyboarding classes? Roboform like password safe?– Fiasco LabsCommented Aug 24, 2013 at 4:58
-
4@FiascoLabs: Thanks for lecturing me, I feel much more enlightened. Now I really like unconfigurable default 'security' features.– einpoklumCommented Aug 25, 2013 at 15:28
-
You're very welcome! When you find the answer, you can post back and take credit for it. At least you're not hitting an unreasonable password failure lockout. Now that's really annoying. The best is 2 tries and a permanent lockout, with call needed to unlock. Then you know your IT department likes making life a pain.– Fiasco LabsCommented Aug 25, 2013 at 17:26
|
Show 1 more comment
2 Answers
First as a direct Windows 7 answer from MSDN, the OS is built with the following decision branching for password validation:
Entering a wrong password causes Windows 7 to iterate through its password caching in order to compare all entries. This causes a delay.
If nothing matched in the cache, the computer then has to contact the Domain Controller to validate the password against the account. This causes a delay.
Then when all else has failed in testing for a valid password, you hit the standard bad password delay. For the reasons mentioned over on ServerFault.
After reviewing password policy on Microsoft Technet for Windows 7, Server 2003, Server 2008, the following settings are possible:
Password History, Minimum Password Length, Maximum Password Age, Minimum Password Age, ObservationWindow, LockoutDuration, LockoutThreshold, badPasswordTime, badPwdCount, ntPwdHistory, ForceUnlockLogon
If you're on a domain, this would be set through a GPO and out of your control, however; locally for a computer on a workgroup, you can make the settings through SecPol.msc under Security Settings -> Account Lockout Policy
The only setting even close, badPasswordTime, is the timestamp the last bad password was entered.
In all the settings, nothing references failed password delay, so it's apparently hard coded into the OS.
Now if you're on Linux, you can add parameters to PAM to allow removal of this delay, if it was set up to accept the parameter, otherwise, you have to recompile the pam module that controls this function with settings of your own choice.
answered Aug 25, 2013 at 18:16
-
1But I bet there's some sort of timeout for when you can't contact the domain controller... Commented Aug 26, 2013 at 17:51
-
1Also, why would iterating the caches cause a delay? And why does contacting the domain controller take so much time? Commented Aug 23, 2014 at 22:28
In my case I found that the lag was caused by contacting the domain controller over wifi. This step is only possible if you're connected to the internet, so it is possible to set up a script that disables network adapters on logoff, workstation lock and workstation idle, and re-enables them when you log back in.
For instance, add a scheduled task that triggers on workstation lock with an action to disable the wifi network adapter
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "Disable-NetAdapter -Name WiFi -Confirm:$false"
You can find the names of your network adapters in powershell
netsh interface show interface
Add a similar script to the group policy logoff. Then do the same with Enable-NetAdapter
