IT - Password Control - Deficiencies 1043



  • It is the same technology you use to crack word and zip file passwords.
    An 8 char. string does not take 8 years… I tested it on one of my own files once on a p4 2.5 ghz… took less than 5 hours to guess my ‘standard’ 8 char password with random numbers and both big and small chars. (For educational purpose ofcourse)
    Oh, and yes, I have 3 more letters than you in my alphabet, so that makes 6 more chars available for the password.
    very very well said,
    umpteen number of PW craking tools in the net available, there are so many friends in our net environment who wanna take up the PW cracking challenge 😉
    How safe are charecters based PWs :?:



  • I’ve worked many years as an IT security professional, including working with IT auditors, performing network penetration tests (e.g., hacking your own network), etc. My WWW button points to my security ‘blog’ and it’s chockful of the latest attacks some of the bad guys are up to.
    While non-expiring passwords save help desk calls and make it easier for users, I would encourage you not to use permanent passwords except in rare cases, for some of the following reasons:

    1. If you’re network were ever hacked, every user would need to change to a new one immediately. If you don’t use password rotations, many would not understand the process well
    2. Security is only as strong as it’s weakest link. Most users will use the same password. For example, the network password might be fairly well protected, but an Internet password may not.
    3. Every external IT Auditor I’ve worked with has this on the checklist to look for and would make comments to senior management as a weakness. They even nail us when you have fairly decent password rotational and reuse standards 😉 🙂
    4. In the spirit of SOX 404 compliancy, I would say that non-expiring passwords would violate standards for sound IT protection of information assets. I don’t have time to research this in detail, but if users shared their passwords accidently, it might violate separation of duties in a workflow situation, (where a person can be the chief, cook, and bottlewasher in a transactional flow) For example, what if the control person knew the check issuer’s password in a checkwriting application.
    5. In fact, I like getting away from passwords altogether with 2 factor security authentication (e.g., biometrics, smart cards, etc). We’re experimenting with SecureID cards that provide unique passwords on a token device every 60 seconds.


  • Problem: Violations or unauthorized activity monitorning ( bad passowrds, invalid user id’s etc) is not being performed.
    Suggested Remedy:
    Review auditlogs and develop a procedure to monitor intrusion attempts on a montly basis i.e bad passwords and user ID’s. All intrision should be logged reviewed and investigated
    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.



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

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

Log in to reply