IT - Password Control - Deficiencies 1043



  • You must change this policy.
    A policy is something you share, even with your partners. It is not wise to disclose such a policy, and there are a lot of reasons for that. Security reasons for example. You ask them to hack you with that policy.
    If you have any problem and try to persuade any court, you will also have serious difficulties.



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

    It is not a de facto violation although it is not best practice. I have seen it argued that infrequent changes to strong passwords is better than frequent changes to weak ones though.
    You have to look at user access as a collection of controls and say on balance are they sufficient. Infrequent password changes may be acceptable if other password parameters are strong.
    If password parameters are too strong and users have, say, a monthly forced change then they can resort to writing them down



  • There are few aspects of password history that you have to consider.
    The first aspect to consider is the risk of a brute force attack, if you have a password of 8 characters and is complex requiring upper, lower, numbers it would take a single CPU 8 years to run through all possible combinations. If the user changes thier password once or twice a year then ideally a user could never crack a password in time before its been changed.
    The second risk is human interaction in the office, over time users could over see or obtain a users password. Changing passwords every 90 days helps midigate this risk, changing passwords more frequently increase the risk as users will write it down.
    The third is the nature of the data, for instance if your data is stored on a laptop changing your password will not prevent someone from stealing your laptop and using forensic tools to read your hard drive and your information. Where as if you are accessing a terminal to access data then there enforcing password history would make more sense.



  • There are few aspects of password history that you have to consider.
    The first aspect to consider is the risk of a brute force attack, if you have a password of 8 characters and is complex requiring upper, lower, numbers it would take a single CPU 8 years to run through all possible combinations. If the user changes thier password once or twice a year then ideally a user could never crack a password in time before its been changed.
    This is incorrect these days and also makes the incrrect assumption that you need to cover all possible combinations to brute force a password.
    The second risk is human interaction in the office, over time users could over see or obtain a users password. Changing passwords every 90 days helps midigate this risk, changing passwords more frequently increase the risk as users will write it down.
    Very true. It’s all a balancing act, if password change rules are too stringent then users do resort to writing them down.
    The third is the nature of the data, for instance if your data is stored on a laptop changing your password will not prevent someone from stealing your laptop and using forensic tools to read your hard drive and your information. Where as if you are accessing a terminal to access data then there enforcing password history would make more sense
    Again agreed. Where practical sensitive information should be kept on shared drives in preference to c drives.



  • I guess I explained that improperly, I was not assuming that you need to run through all possible combinations to brute force a password however i as trying to say that with a realitively lengthy and complex password and a frequent password expiry policy the chances of someone actually using brute force to gain acess before the password has changed is signifigantly minimized.



  • I’d also like to see your calculation for the brute force attack.
    ‘One CPU’ can be a Intel 8086, or it can be dual core state of the art Pentium.
    8 years sounds abit much to be honest, unless you’re using your mobile phone or PDA.



  • Length = 8
    Complex = Upper lower, numbers 62 possible combinations
    62^8 = 218340105584896
    Key Rate = 200 000 per second
    62^8 / 200 000 keys per second / 60 Seconds / 60 minutes / 24 Hours / 365 Days / 1 Cpu = 34.61 Years to run through all possible combinations not nessassarly to crack a given password.
    Currently Running LC5 on my 1.5 ghz PC I am getting a 10,000 key rate.
    Any insight to possible key rates verus processing power would be appreciated.



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



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



  • 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


Log in to reply