IT - Password Control - Deficiencies 1043
-
If you have good system controls that will lock a user out after x number of attempts to log in, then your primary control is working. A review of the log is a secondary control. The only way for a large company to realistically review this log is to have some type of exception report that picks up patterns of denied log-in attempts (i.e., repeated attempts from the same IP address for different IDs, repeated attempts on the same ID over a longer period of time - especially if your system only locks them out for 15 minutes prior to allowing login attempts again, etc.). This exception report would then help to identify potential hacking issues that could then be addressed.
We successfully argued out of this deficiency proposed by our auditors.
-
Question to the group: The suggested remedy is practically impossible to implement. The persons who forget their passowrd or key in invalid user Id’s are resetted by the helpdesk. But if helpdesk gets 100 such calls every month how do we monitor/log the whole process as the system generates logs on all these isues. Pls. advice how do you go thru the logs of such magnitude to make the process better.
I agree … We’re using Intrusion Detection software and logging processes on failures. Products that can collect information from servers into a central report might also assist in this process. Finally, the HelpDesk tickets might be keyed in a way to facilitate reporting in the future if this is a key need.
-
Given an account should have a lockout period as well as reports on failed multiple log on attempts I would think even 4 character simple password policy would be hard to break into if the policies of the network were:
3 incorrect logins results in a 1/2 hour account lockout
10 or more failed logins for any account within 3 hours results in a system generated warning to admins of a possible attack
-
Hi Mark and welcome to the forums
I agree somewhat with your points from a technical perspective. However, I’d recommend 8 character minimum length passwords (or might compromise at 6 bytes). Here are the reasons:- 6-8 character minimum password length requirements are on most audit checklists, as least with the auditors I’ve worked with.
- Naturally, many users will often choose the shortest length they can get by with. If someone were standing by a ‘one finger typist’
they might more easily see the 4 charcter password than the 8 byte version. As I’ve helped folks (even recently), I’ve been able to pick up passwords that way with 6-8 characters, but I’m also on the ‘good side of the force’
- I’d add that it’s desirable to have both letters and numbers in a user based password, so that the password is not in a ‘hackers password dictionary’. If a dictionary attack were used, an ‘alpha only’ version might be compromised more easily.
- I’ve done extensive password testing in the past as part of Network Vulnerability Assessment testing (aka Penetration Testing). If the bad guys get a copy of the SAM data base, a 4 character password can be compromised much quicker (e.g., LophtCrack, Rainbow, or other tools). I’ve experimented with different lengths and the longer the better, as each character adds in a factorial fashion the time it takes to compromise security.
- While I also like upper/lower case and special characters within the password, I probably wouldn’t mandate this as a standard, as it creates user difficulty and an increase in Help Desk calls.
- The lockout approach Mark descibes would work on many platforms, but users tend to use the same password where they can. So, if they chose it as an Internet based password or weaker security environment without lockout, this might provide a way in. I found this at least to be the case in my own Penetration Testing experiences.
- Finally, passwords are poor security anyway compared to 2-factor solutions like SecureID or CryptoCards.
-
I saw these recommendations by Microsoft on how to create strong passwords. They also also have a testing facility that will rate the strength of passwords entered. The final link discusses some considerations related to this facility.
Microsoft recommendations on how to create a strong password
microsoft.com/athome/security/privacy/password.mspx
Password Testing Facility - enter a password and it rates it
microsoft.com/athome/security/privacy/password_checker.mspx
Internet Storm Center - commentary on this new facility
incidents.org/diary.php?storyid=1285
-
It looks like my Key Rate/second is definitely way off, I stand corrected and will have to do some more testing and research into this. Thank you for the information. I think that one factor is that many cryptography systems use a hash. The advantage of a hash is that the actual password does not have to be anywhere in storage in order to validate it. The disadvantage is that the actual password does not have to be known to get it validated; that is, it is only necessary to try the various hashes. A single hash can correspond to multiple paswords.
This is the limits of my understanding, but I hope this is sufficiently accurate. If it is important enough, we can find relevant security articles.
-
It is felt that the risk is adequately mitigated by having
account lockouts after three failed log in attempts
(that must be reset by system admins).
I am having a discussion with our auditors about this topic. I prefer passwords that are automatically unlocked after a specified time not passwords that must be reset by system admins.
The main reason is that a colleague in another company was the victim of a brute force attack that locked out all the passwords; including the admin passwords. Consequently the passwords could not be unlocked by system admins. It took an unacceptably long time to for him to get his users back in action
The subsidiary point is that the help desk would get an unacceptable number of calls to reset locked accounts
-
If a brute force attack can lock -all- the accounts in a domain, then there’s something seriously wrong with the way the network is setup.
I’d say that company have bigger issues than the password setup.
However, I’m for complete lockout, because if you have enough time, you could probably figure out an unsafe password with time limited lockout
-
Agree with IrguiM
I do not like passwords being automatically reset, it undermines the control and ultimately is just lazy. If you have the effect described from a brute force attack the last thing you want is your accounts automatically reset for another attempt.
-
Hi guys,
thanks for your inputs.
In my opinion it is safe enough to unlock the accounts after a certain time.
Brute force attack are not feasible anymore, as the number of attempts is drasticly limited.
Just to explain: Brute force attack tools can try tens-thousands and even hundred-thousands of passwords per second.
With a specified lock out after 3 or 5 wrong passwords for say 5 minutes, the possible Brute force attack trial and error rate is reduced from millions per 10 minutes to 6-10 per 10 minutes.
This is a dramatic reduction and in fact makes brute force attacks totally inefficient and also low risk for me.
-
We also never allow passwords to be automatically reset , as all professionals with password lockouts must go through the help desk. Realistically, you might be fairly safe with auto-reset process.
Auto-resets might increase the risk slightly if there were a non-brute force probing of security controls. For example, if someone wanted to desparately break in through the outside, the was able to pick up any patterns on the auto-reset process, they could keep slowly guessing over time with commonly used passwords once a pattern is evident? It still might be very difficult for the unauthorized user to break in unless they got lucky.
Having strong passwords is the most criticial need of all and that’s why it’s important to test for any weaknesses periodically. Passwords are often the only thing that might stop the bad guys from getting in. For example, if I were testing controls, I’d using some of the following passwords: ‘password’, ‘welcome’, ‘password same as ID’, ‘factory default for known service accounts, (e.g., Cisco router software)’ and ‘blank’.
If the IT security and audit departments feel okay with auto-resets I could see a company using them as it does offer some convenience to the users. I’d recommend good complementary tools like IDS and event logging on the process. Still, I’d prefer the manual reset approach as it offers a slightly more secure process.
-
There is a Microsoft white paper on this topic called ‘Account Lockout Best Practices White Paper’ which is an interesting read.
Their view is that auto reset provides ‘medium’ level security. Of course, it should be combined with a strong password.
The issues for me with administrator un-lock versus auto-unlock are load on help desk resource and loss of productivity while users wait for their accounts to be unlocked.
Anyway I do not understand why administrator unlock is seen to be inherently safer than auto-unlock? In firms with x thousand emplyees and maybe an out-sourced help desk, what is to stop hackers phoning up and asking for an accout unlock?
-
Their view is that auto reset provides ‘medium’ level security. Of course, it should be combined with a strong password.
Exactly, with a strong password you get medium security with auto-unlock.
Now, tell me how many of those thousands of users of yours don’t have name of family/super stars/cars/etc as a password in plain lowercase?
Realistically, don’t trust users to set a strong password. And giving users randomly created password once every 45 days or something just ends up in people writing it down on notes/yellow stickers and putting it under the keyboard, 'cause that ‘is the only place in the world where no one would look’.
-
The issues for me with administrator un-lock versus auto-unlock are load on help desk resource and loss of productivity while users wait for their accounts to be unlocked.
That’s the key benefit of auto-unlock after a time interval. It’s truly a ‘hassle’ for passwords to be reset by human intervention. A user may be unproductive for 5-15 minutes, although that may the amount of time needed for an auto-unlock.
However, I think we see more of folks forgetting their password altogether rather than miskeying it 3 times … In those cases you are going to need human intervention anyway. There are sometimes cases where the CAP LOCKS is on or someone’s fingers aren’t lined up properly at 8:30 a.m., but still having studied Help Desk ticket reports in the past, users have more issues with ‘amnesia’ than keying
Anyway I do not understand why administrator unlock is seen to be inherently safer than auto-unlock? In firms with x thousand emplyees and maybe an out-sourced help desk, what is to stop hackers phoning up and asking for an accout unlock?
An excellent point … In our company, the help desk crew looks at the phone # plus they ask the employee for a PIN # (e.g., employee ID, last 4 digits of SSN, or a code of their choosing on file) … In some cases they’re even familiar with the voice of the individual due to repeat customers
-
Realistically, don’t trust users to set a strong password. And giving users randomly created password once every 45 days or something just ends up in people writing it down on notes/yellow stickers and putting it under the keyboard, 'cause that ‘is the only place in the world where no one would look’. %0AI agree 100% … some quick ideas that worked for us when I used to be in IT security:%0A1. Test passwords quarterly with a good commercial tool (e.g., STAT, KSA, RealSecure, Bindview, etc). %0A2. Identify users with weak passwords and the IT security area should work with them (e.g., Intranet web pages and email are good tools to share best practices in password contruction). Some quick half hour security awareness sessions can also help. %0A3. The use of Password incrementing can be helpful if it’s done right . You have to build a more complex pattern than just increasing a number field by ‘1’ each time. Examples - but do not use your own name
%0Aa) Milan02z, Milan04y, Milan06x%0Ab) Denis44a, Denis55b, Denis66b%0Ac) Sox11aa, Sox33bb, Sox55cc%0Ad) Cobit03a, Cobit06b, Cobit09c%0AThese types of passwords pass the hackers dictionary tests. They may or may not pass the special routines in the operating system (as our routine would fail for #1 as it ends in a number). Still for me, I never write down passwords and this system works well if you haven’t used a special resource in a while (e.g., you can fall back a password or two before having the Help Desk reset a password).%0A4. Move away from passwords to more secure techniques for sensitive applications (e.g., 2-factor techniques like SecureID, smart cards, biometerics, etc)
-
but still having studied Help Desk ticket reports in the past, users have more issues with ‘amnesia’ than keying
I can confirm this after working with helpdesk for a few years before starting SOX.
-
[quote=‘Tri’]2 questions:
- Our company is contemplating a policy that says you NEVER have to change your network password. Is this a de facto violation of the SarBox IT General Controls standards?
SOX says that passwords of critical infrastructure components should be strong. So three password parameters which contributes to make password strong are password length, complexity and password expiry so ideally considering password as a key SOX IT control password should be changed on periodic basis.
- Our company is contemplating a policy that says you NEVER have to change your network password. Is this a de facto violation of the SarBox IT General Controls standards?
-
Good Morning Nilu
Welcome to the forum.
I would say this is not a SOX violation if merely hacking the network is not sufficient to enter the ICFR relevant applications and change management libraries, provided a strong security awareness program is in place.
It was a violation two years back during SOX infancy.
-
lol - Indeed, as password rotational controls and other best practices are mandatory for SOX
Even if SOX were to permit non-expiring passwords for user accounts, this violates basic security principles that would highlighted anyway.
Still, for important and sensitive financial applications I’d suggest folks migrate to even better controls than passwords (or even much longer passphrases). This includes 2-factor solutions (e.g., RSA Secure ID cards, Crytocards, etc) or even biometric security as this technology matures. Even the best of password controls can be potentially compromised though software or even social engineering approaches (e.g., the infamous hacker Kevin Mitnik used the ‘low tech’ approach by calling help desks for password resets).
-
General Controls, IT Security Practice and Risk Management provide sound reasons for password changes.
That said, may IT Auditors are enthusiastic to adopt password change rates from NIST or other historical standards that have not been updated for more than 10 years.
Pros:
A) Password changes help with gaps in protection that occur with departing employees.
B) Password changes help with undetected password disclosures.
C) Password changes provide a hook for user training in good quality password selection.
D) Password changes are a common issue used to start up user awareness training programs.
Cons:
A) Password changes, in the present technical treat environment, represent no more than about 1.5 minues to 40 day head starts against password cracking methods used against your network.
B) Password complexity needs training on how to do it well to prevent users from puttting new password on post its, under the keyboard and in their PDAs and Daytimer indexes.
C) What passes for password complexity on Microsoft systems is a delusional fantasy compared the performance of rainbow assisted password crackers that are freely available on the internet.
So, where does that leave us.- Restrictions on how often a change can be made help guard aganst user and hacker circumvention of passwords.
- Length for realistic security or at least ‘High securuity’ passwords has got to be longer than 8 places. Think 15 or more places. Use phrases, ‘My fellow Americans.’. These can be easier to remember but long.
- The type of password encryption is important to consider, for example Microsoft Backward compatibility can make LM hashing available. If so, no password less than 15 places is safe.
- Deals with a user base on how complex and long the password is can sometimes make a realistic trade off with how often a password is changed. This trade off can still reduce risk exposure but create political acceptance.
- Good will in password changing is a massively important factor. Without it, users just give out their passwords, or post them on shared drives inside Word and Excell files. ‘Hey guys, the new Admin Password is ‘Help me Obeywan Canobe’’ – Posted in Excell.
So, we have to win the password change requirement, unless your employees roll over very fast and accounts close automatically when they leave. (Thus, password change happens by default.)
Also, get real password quality training. Do not be part of the US population whos password is cracked in less that 90 seconds. Please. Really, I have charts and live data on this point.
Does any of this advice help?
Don Turnblade
CISM, CISSP, MCSE
Arctific_at_cox.net