IT - Password Control - Deficiencies 1043
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.
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.
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?
CISM, CISSP, MCSE
Auto Unlock works if the time is at least 4 seconds long. This delay is short for a human but long for a bruteforce password cracker.%0ASome organizations want the lockout to identify the user for user training or help desk tutoring.%0A74% of Help desk load can be taken up in password resets. So, it is a full employment act. %0AHowever, user self service at an SSL internal webiste works. Just be sure to get a solid public key. If the user sees a key management pop up during their self service session, they still call the helpdesk. It just defeats the point of self service.%0ABest Wishes,%0ADon Turnblade%0ACISM, CISSP, MCSE
EmPannah last edited by
The real question here, I think, is the construction of the PASSWORD. If the PASSWORD is just 8 plain alphabets, it would be easy to crack, but if that 8 character password is a combination of upper case, lower case, numerals, and special characters, then that will take enormous time to crack. I love this nice discussions…
There are three great issues in password strength. %0A 1) Is the password hashing method easily cracked?%0A 2) Does the password complexity present a difficulty for brute force methods?%0A 3) Does the password trainer have the proper knowledge of what a quality password choice truly is? %0AWeak hashing method example:%0ABackward compatible LM hashed on Microsoft networks is an almost completely penetrated hashing method. All Letters, Numbers, standard keyboard symbols and spaces can be cracked from 1 - 14 places in seconds because the Rainbow tables to do so are freely posted on the internet. %0AWeak complexity example:%0A8 place passwords represent such a small complexity space that either direct brute force methods or rainbow table computations are being used to break the security of such passwords. On average an 8 place rainbow table for letters, numbers and standard keyboard symbols has already been computed and are on sale on the Internet for USD50 each. Microsoft, UNIX, and more… %0APassword Trainer Troubles:%0AThe view that an 8 place password provides realistic security is a delusional fantasy of the IT Audit community. A 14 place password can fall in less than 3 seconds if bad hashing and pasword choices combine. An LM hash of CrunchyPretzel will crack as two words in a real world timeing of 3 seconds on a Pentium 4 laptop.%0AIf we promise improved security, we need to deliver.%0AA bank with a requirement to change its passwords every thirty days had about 10% of its user population changing their password to the Month and day of the password change. Their passwords looked as follows.%0ADecember8%0ADecember10%0ADecember11%0A13December%0AWhen I found this population, their password matched the month of October, so I still call this user population ‘The October people’ after that month. %0AAll of these passwords meet Upper and Lower Case Alpha and number training requirements. All my statistics are based on real password files with greater than 3000 active accounts in them.%0ASo, a training program was build where graduates had their password re-cracked to validate the quality of training received. The results were many updates to cover simple miscommunications.%0AFor example, when told not to use a dictionary word, one class thought in meant, ‘Do not use an English dictionary.’ So, the domain administrator account was changed to a Spanish word. So, the password fell quickly after training.%0AIT Audit thinks it knows what a better than average password is. But, according to my measurements, it really does not.%0AIT Audit knows that it must require change and then test. But, it is rare that an IT Auditor applies this to its password advice. The lackluster results that I continue to measure are the result.%0ATo help train users on password complexity, I have built an interactive password grader. Most Systems Administrators train themselves in make better than average password choices in less than an hour. The immediate feedback, color coded bars and estimated cracking times of a password choice is extremely educational. Some obsess about the matter for 3 days and their password choices become extraordinarily strong.%0AA more honest discussion of this, in my view, is actually going on at Wikipedia under Password Strength, %0Aen.wikipedia.org/wiki/Password_strength The Cautionary Tale section outlines how a 14 place password can fall in less than 3 seconds on a Microsoft System. %0APlease, Please, Please update your password advice. Stop increasing the throngs of people whose passwords will fall in 90 seconds. Stop avoiding making QA tests on IT Audit advice.%0ATruly Concerned,%0ADon Turnblade%0AMS, CISSP-ISSMP, CISM, CISA, MCSE
xtremeski2001 last edited by
I’m currently a sys admin and spend a lot of my time resetting passwords because user forget them. I’ve also went to users desks and noticed that they have a folder with all their passwords in them.
I agree that one of the biggest steps is teaching users how to create solid passwords. The problem is, many users can’t even remember the password they created (i.e. ilovemaria) or something simple like this.
When I used to work at a large software company, it taught us to make passwords that could be remembered using phrases.
Let’s say you love investing and sox. You could have a phrase like ‘Xtreme Loves Sarbanes and Sox while in the sun’ … this password would end up being Xl54w1Ts or something similar. The password is strong and somewhat easy to remember if you force the user to repeat it a few times. Hopefully, in the end the user will remember this method and it will also help them remember their password.
I haven’t done this for other users due to my own organizations negligence in their password policy, but in my previous organization this worked very well.
On a tangent, what does everyone use to store their sys admin passwords? Passwords such as root access to *NIX boxes, sys admin level resp. in Oracle, etc?
Right now, my organization uses a VERY insecure method … I’m scared to even say the method. In my previous organization, we used some kind of program that had several authentication levels, but was very costly.
Perhaps someone knows an open source application that can be run in a Windows environment that will achieve the same thing I’m looking for?
Hi Don – I agree the good information shared in your excellent post
Thankfully, our admins at work require strong password settings in every environment where it can be easily implemented. Better yet, we’ve been moving to SecureID for 2 factor authentication for remote workers.
While 2-Factor authentication is more complicated for the users and fairly expensive – it’s far better to put a strong lock on your corporate gates , than one that can be picked eventually by some of the more sophisticated password cracking tools out there (e.g., RainbowCrack, LophtCrack, etc)
In my past experiences as an IT security professional, I’ve performed Network Penetration testing including password testing. In one testing case, even a complex 14 character password became ‘clear text’ after running a cracking tool for over a week (as we even gained access to the NT SAM file to help facilitate this).
Two factor authentication has several advantages. The advantage of reducing complexity of each factor helps users manage the solution. Further, the ability to respond to evidence that one factor may be broken is a solid security advantage. To preserve the advantages of SecureID, keep careful accounting of your tokens.
Internet freeware exists that can synchronize with a borrowed token to predict its sequence. This came about when some of the SecureID server code was reverse engineered sometime after 1992. To my knowledge, one freeware tool has used a point and click GUI to synchronize with tokens for several years now.
In practice, SecureID tokens work rather well. User awareness training to not use post-its to stick on their second key to the SecureID is effective. When users learn of the risk of borrowing a SecureID, they become appropriately protective. The main risk is co-worker impersonation. Keys with SecureID tokens get left on desks unattended for 15 - 45 minute time windows. Attack software can run on portable PDAs. So long as the second key is not captured, security remains effective.
Novell Single Sign On tool:
In standalone mode the tool can use an AES encrypted file to store passwords. As the items are reversibly encrypted, user hints are possible. Further, a master password to enter the utility substantially reduces the passwords that must be remembered.
The main risk with such solutions is control of the user interaction with the tool. In Novell’s case, the tool may have my web banking user ID and password in it. Then, an unwanted user of my desktop may use my web browser to reach my bank. The tool’s helpful ways give up too much access through automated logon to my bank. Then, my money is in real trouble; a bad guy could impersonate me to my bank.
A less technological solution is to have a reversibly encrypted password hint file. Then, capture of this file or even decryption will not give out the passwords themselves. In most cases, a small hint will lead to password remembrance.
The user can then give boring tag names for passwords and match them with password hints. In this way, a user’s day timer will not give up both account names and passwords but only account names and password tag names. Even if the hint file is also captured and decrypted, the attacker then only has a map of account names and password hints.
I admit the solution is not perfect, but management of 200 or more privileged IDs can be a tough game for administrators.
Please let me know if you have better solutions. I am all ears.
More on passwords - copy of blog post below
Security is only as strong as it’s weakest link and this ISC article shares some good awareness on the need for strong passwords. While companies and home users have strengthened security with firewalls, AV protection, and other tools, a weak easy-to-guess password can let the bad guys right into the front door.
ISC Article: Remote Password Guessing - Concerns, Observations, Recommendations
Please paste to browser - no www needed)
Always use a strong password (e.g., includes at least one letter, number, upper case letter, special character) for the best level of protection.
Microsoft - How to Create Strong Passwords
Please paste to browser and add www
Microsoft - Password Strength Checking Facility
Please paste to browser and add www
YRGermain last edited by
I’ve read the threads for password resets but I would like to know what the Sarbox states regarding specific admin accounts (Oracle DBA SYS and SYSTEM accounts) and if their are any wavers (derogations) to this. Is it possible for a company to not activate the logon and logoff audits in Oracle and therefore waver this also? If so, I must assume that a company has justifying evidence regarding this decision where if something does happen, this document would be proof against them as having wavered their right to defend in court (worst case scenario).
Denis last edited by
I would like to know what the Sarbox states regarding specific admin accounts (Oracle DBA SYS and SYSTEM accounts) and if their are any wavers (derogations) to this.
Sarbox states absolutely nothing about this.
One needs to apply judgement within a methodolgy that supports your system of internal control.
Hi - I agree with Denis, as SOX doesn’t cover specifics like password settings at a granuluar level. SOX 404 requires management to ascertain their IT financial systems, security, and related workflows using a risk management approach, that is complemented using controls testing.
However, many external auditors use COBIT 4 standards to gauge SOX 404 compliancy and this document is available as a free download.
Free copy of COBIT 4 by registering
ranmori last edited by
simulation credit auto [/url]
Thanks harrywaldron for the link. It worked well
gmerkl last edited by
The time it takes to crack a password depends on many factors:
- is a human manually typing in the passwords or is a program automatically doing it
- are the passwords typed into the application input window that the password protects or do you have access to the encrypted file that stores the users’ passwords and know the encryption or hash algorythm
- the automatically enforced password rules for minimum length and required diversity of passwords (lower case, upper case, numbers, special characters
- the fact that users tend to use passwords that they can easily remember so that cracking programs can use dictionaries and reduce the number of combinations that are actually used in practice.
- after how many unsuccessful password attempts in a given time period a user account is blocked for further attempts
If a cracking program needs to simulate keystrokes being typed in an application and if the system limits the speed of processing such keystrokes (which can be much slower than the raw processing power of the CPU) then your cracking time will increase.
Point number five is actually the most important one if the cracker does not have access to the enrypted password file. If the number of login attempts until blocking is three and if the investigative process to unblock user accounts involves contacting the user and verifying that it was him that made the unsuccessful attempts, then cracking has almost no chance unless passwords are extremely weak.