Book now with code EOY2025
rwmidl wrote: » I'm not against no lockouts, but (my opinion) it should be a high number - like 100 - not 3/4 failed attempts.
rwmidl wrote: » If someone is trying to brute force an account it will quickly hit that 100 attempt threshold (or it could be indicative of a service account with an expired password?) I've fat fingered my account multiple times where I've locked myself out after 3 attempts.
tiersten wrote: » I might know the person so would have a much better idea of what sort of password they'll use.
dynamik wrote: » Right. I forget the name of the tool we were playing with, but you basically entered all the information you knew about a person, such as relatives' names, hobbies, birthdays, phone numbers, etc., and it generates thousands of different combinations and variations with all the information you entered. Also, if you have a shorter lockout instead of 24 hours, or requiring an account to be manually unlocked, just wait it out if you fat-finger it. You can set the threshold higher, but I agree, if someone can't get their password in 3-5 attempts, they've probably forgotten in. The sentences you're referring to are known as "pass phrases," and I'm a proponent of those as well. Edit: here's an interesting site with some password statistics: Passwords - Skull Security He did an analysis of the compromised Rock You passwords (see the coverage section), and only 13 passwords got into 5% of the accounts. *SCARY*
rwmidl wrote: » If the user has fat fingered/forgotten their password they will call for a reset. What is the added purpose of locking the account if the user has honestly forgotten what their password is? In the end they (the sys admin/help desk) is still going to have to reset the password.
DevilWAH wrote: » Why would you possible want 100 attempts before a lock out. some one running a brute force attack may on average need 100,000 of attempts before getting it right. But then again they may get it right on the 10th attempt.. And if you say your curiosity would be engaged if you say say 30 attempts then if you are saying this would get you attention. then surely that is the point you want to lock the account down. Why let it carry on if you are saying at x number of attempts you would look in to it. One thing I would say is allowing help desk engineers to unlock the accounts! many times with out any more security checks than. "can you tell me your user name?". I think password prompts if set-up correctly can put an extra block against social engineering and allow users to sort them selves out with out bothering the IT unit. You lock you account out after 5 attempts, you are directed to a reset password page with 2 or 3 prompt questions. we use strong passwords, (upper lower numeric and special has to contain one of each) 8 in length and can't contain user name or repeat from last password. It does anoy a lot of people, but we suggest the first letter of each word in a phrase, with a date in between + a special caricature some where. so like "I like to visit techexams 21 of august " may become 21Iltvt8*! easy to remember but very hard to brute force.
rwmidl wrote: » Using your same argument, someone trying brute force could in theory crack the password in 1-2 tries with a lockout policy of three failed attempts. Obviously the longer/more complex the password is the more difficult it is to break. I'm not saying that 100 failed attempts should be the standard. I'm just trying to throw in a different thought process since the "standard" seems to be 3 failed attempts (at least at the places I've worked).
veritas_libertas wrote: » I was afraid this conversation would turn boring. I'm glad it got deeper than, "Use 8 characters, Upper Case/Lower Case, numerals, and symbols." @PaulBoz: Thank for introducing me to Microsoft Research!
Paul Boz wrote: » There's always more to the story than basic details.
Paul Boz wrote: » I recently read a whitepaper called “Popularity is everything – a new approach to protecting passwords from statistical-guessing attacks.” URL: Popularity is Everything: A new approach to protecting passwords from statistical-guessing attacks - Microsoft Research Basically the gist of the paper is that using a matrix of password hashes (assuming no salting is going on), larger password repositories (like those maintained by ISPs and large e-commerce sites) can block statistically common passwords. Many web services such as Yahoo already tell you if a password is too common for use. There are several drawbacks to this sampling method. First, it assumes that no salting of the password hashes is occurring. If salting was occurring it would be impossible to determine the frequency of a password based on the hash alone. Second, it only hampers statistical-based password attacks. It does nothing for brute-forcing or dictionary attacks. Password policies are one of the hardest things for companies to adequately implement. Either the requirements are not harsh enough or they’re too harsh. Either the lockout is too harsh or it does nothing. CIS provides system benchmarks for SSLF (secured configuration) and Enterprise (standard configuration). According to the CIS Windows 7 benchmark, a timeout period of 15 minutes for secure and non-secure devices should be enforced. However, the account lockout threshold is as follows: For secure configured devices the recommended value is 10 attempts. For standard devices the threshold is 50 attempts. If you do the math that is only 40-200 attempts per hour (assuming no one detects the brute force attempts). In my experience grinding on passwords that is far too few attempts to be useful. Perhaps if the users were using standard dictionary words with no complexity requirements it would be sufficient to brute the passwords, but it would still take forever. The design of those thresholds is two-fold. One, it gives a user a sufficient number of attempts to remember the password without locking out and having to receive support. Two, if someone actually locks their account after 100 password guesses you either have an attack on your hands or a reaaaaaaaaaaally stupid user. Either scenario serves to tune out junk alerts (events triggered because of dumb users) and provide only the situations which should be looked in to.
Paul Boz wrote: » First, it assumes that no salting of the password hashes is occurring. If salting was occurring it would be impossible to determine the frequency of a password based on the hash alone.
rwmidl wrote: » Paul - thanks for your insight. I guess I should have clarified my stance on the 100 attempts as I was meaning that towards a desktop (ie standard device). Servers or other secured devices should have a lower threshold.
dynamik wrote: » I disagree with the no lockouts because of concerns over denial-of-service. People bring that up all the time, but I never see it or even hear of it happening.
dynamik wrote: » A desktop is just a stepping stone to a server...
undomiel wrote: » I've seen it happen twice. One client we picked up was completely locked out of his server for 48 hours due to all administrative accounts being locked out by a brute force attempt. I've also seen a case where someone was running services under the administrator account and changed the admin password. The services were set to automatically restart immediately so the account was locked out until we found the improperly configured services.
rwmidl wrote: » true, that is why you would have the threshold for servers be a lot lower and more strict than you would say a desktop.
chuckles wrote: » For example, "Techexams Rules" could become "T3chexams Ru7es!" Try to guess that one!
techex4ms Techex4ms t3ch3xams T3ch3xams techexam$ Techexam$ t3ch3x4ms T3ch3x4ms techex4m$ Techex4m$ t3ch3xam$ T3ch3xam$ t3ch3x4m$ T3ch3x4m$ --snip--
Use code EOY2025 to receive $250 off your 2025 certification boot camp!