| WIKI | FAQ | Tech FAQ | |
 http://csua.com/feed/ | |
| ||||||
| 5/24 |
| 2005/6/29-30 [Computer/SW/Security] UID:38364 Activity:moderate |
6/29 Does anyone have a well-reasoned essay on why it's a bad idea to force
your users to change their passwords regularly? I have a strong
password and changing it frequently means I have to keep it on a
piece of paper or use dictionary words.
\_ I'm sure there's something obvious I'm missing here, but why can't\
computers just have either a rfid reader, a barcode scanner or a
\_ I'm sure there's something obvious I'm missing here, but why can't
computers just have either a rfid reader, a barcode scanner or a
magnetic strip reader, and just let users swipe a card? If carrying
an artifact on your keychain is good enough security for your car
and home, it's good enough for your computer. I think passwords
are fundamentally flawed for normal people (and I have *worse* than
normal ability to remember passwords.)
\_ Because optimally you want two-factor auth (remember, a combo
of what you have, are and know.) If you can only do one-factor
auth, you'd rather limit yourself to the last than the first
which can be more easily, well, swiped. -John
\_ I'm not sure I see the problem. I use a key I carry in my
pocket as the only form of security for my car (sure, people
may have some electronic thing, but they always have it
on their keychain also). So why does some office email
system have to have better than that? If the physical
security of the building is based on a key it seems that
should be fine for the computers in most offices. I'm
a totaly neophyte about computer security, but I've always
found passwords to be impossible to remember and I think I'm
not alone. Isn't a physical key better than a password that's
written on a post-it note right over the terminal?
not alone. Isn't a physical key better than a password
that's written on a post-it note right over the terminal?
\_ Why do you need well-reasoned? Everyone I know who has to change
passwords regularly switches between two passwords.
\_ That's nice, because lots of software remembers the old
passwords and this won't work. Personally, I have a good
memory and changing my password often isn't a problem. For
people who have trouble, simply store your passwords in a PDA
in encrypted format.
\_ At Intel, it remembered the last 8 passwords. Most people I
knew cycled through pass1, pass2, ... pass8, and then set
whatever they wanted. -emarkp
\_ http://www.securityfocus.com/infocus/1554 is a start. If you
drop me a mail (other address in my .plan) I will gladly find you
some very strongly worded essays on the topic--there were a few
good ones written on this area in the last year. Constant
password change policies and restrictive password histories are
a solution for weak-minded security managers. -John
\_ If you have an ACM account, I suggest looking up "Users are not
the enemy" by Adams and Sasse. Excerpt (from Firewalls and Internet
Security) in /csua/tmp/uante. -gm
\_ http://www.useit.com/alertbox/20001126.html --jameslin |
| 5/24 |
|
| www.securityfocus.com/infocus/1554 Mark Burnett last updated March 7, 2002 With all of our advances in security technology, one aspect remains const ant: passwords still play a central role in system security. The difficu lty with passwords is that all too often they are the easiest security m echanism to defeat. Although we can use technology and policy to make pa sswords stronger, we are still fighting the weakest point in any system: the human element. Ultimately the goal is to get users to choose better passwords. However, it is not always clear how to achieve that goal. The problem is that as creative as humans are, we are way too predictable. If I asked you to ma ke a list of totally random words, inevitably some sort of pattern will emerge in your list. System administrators need to be educated and that education needs to be passe d on to end users. This article is meant to bring you closer to understa nding passwords in Windows 2000 and XP by addressing common password myt hs. Myth #1: My Password Hashes Are Safe When Using NTLMv2 Many readers will be familiar with the weaknesses in LanManager (LM) pass word hashes that made L0phtcrack so popular. NTLM made hashes somewhat s tronger by using a longer hash and allowing both upper and lower-case le tters. NTLMv2 made even more advances by computing a 128-bit key space a nd using separate keys for message integrity and confidentiality. It als o uses the HMAC-MD5 algorithm for further message integrity. However, Wi ndows 2000 still often sends LM or NTLM hashes over the network and NTLM v2 is also vulnerable to in-transit (also known as replay) attacks. And since LM and NTLM password hashes are still stored in the registry, you will still be vulnerable to attacks against the SAM. It will still be some time until we are completely free from the grips of LanManager. Until then, do not assume that your password hashes are saf e Myth #2. Dj#wP3M$c is a Great Password A common myth is that totally random passwords spit out by password gener ators are the best passwords. While they may in fact b e strong passwords, they are usually difficult to remember, slow to type , and sometimes vulnerable to attacks against the password generating al gorithm. It is easy to create passwords that are just as strong but much easier to remember by using a few simple techniques. This password utilizes upper a nd lower-case letters, two numbers, and two symbols. The password is 20 characters long and can be memorized with very little effort; Su ch structures also make it easy to include punctuation characters in the password, as in the e-mail address example used above. Other data struc tures that are easy to remember are phone numbers, addresses, names, fil e paths, etc. Consider also that certain elements make things more memor able for us. For example, patterns, repetition, rhymes, humor, and even offensive words all make passwords that we will never forget. This actually made passwords more vulnerable because a brute-force atta ck could be performed on each half of the password at the same time. So passwords that were 9 characters long were broken into one 7-character h ash and one 2-character hash. Obviously, cracking a 2-character hash did not take long, and the 7-character portion could usually be cracked wit hin hours. Often, the smaller portion could actually be used to assist i n the cracking of the longer portion. Because of this, many security pro fessionals determined that optimal password lengths were 7 or 14 charact ers, corresponding to the two 7-character hashes. NTLM improved the situation some by using all 14 characters to store the password hash. While this did make things better, NT dialog boxes still limited passwords to a maximum of 14 characters; thus the determination that passwords of exactly 14 characters are the optimal length for the b est security. But things are different with newer versions of Windows. Windows 2000 and XP passwords can now be up to 127 characters in length and so 14 charac ters is no longer a limit. com is that if a password is fifteen cha racters or longer, Windows does not even store the LanMan hash correctly . This actually protects you from brute-force attacks against the weak a lgorithm used in those hashes. If your password is 15 characters or long er, Windows stores the constant AAD3B435B51404EEAAD3B435B51404EE as your LM hash, which is equivalent to a null password. And since your passwor d is obviously not null, attempts to crack that hash will fail. With this in mind, going longer than 14 characters may be good advice. Bu t if you want to enforce very long passwords using group policy or secur ity templates, don't bother - neither will allow you to set a minimum pa ssword length greater than 14 characters. J0hn99 is a Good Password While it does pass Windows 2000 complexity requirements, "J0hn99" is not as strong a password as it appears. Most password crackers have rules th at can try millions of word variants per second. Replacing the letter "o " with the number "0" and adding a couple numbers is no big deal to a pa ssword cracker. Some password crackers have rulesets that can create pas sword combinations well beyond the average user's creativity or patience . Rather than replacing "o" wi th "0", try replacing "o" with two characters such as "()" as in "j()hn" . And of course, making your password longer will make it even stronger. Eventually Any Password Can Be Cracked Although a password may eventually be discovered through some means (such as through a keylogger or through social engineering), it is possible t o create a password that cannot be cracked in any reasonable time. If a password is long enough, it will take so long or require so much process ing power to crack it that it is essentially the same as being unbreakab le (at least for most hackers). So yes, eventually any password can be c racked, but eventually may not fall in your lifetime. So unless you have the Government hacking away at your passwords, chances are you are pret ty safe. Of course, advances in computing power may some day make this m yth a reality. Passwords Should be Changed Every 30 Days Although this may be good advice for some high-risk passwords, it is not the best policy for the average user. Requiring frequent password change s often causes users to develop predictable patterns in their passwords or use other means that will actually decrease the effectiveness of thei r passwords. It is frustrating to a user to have to constantly think of and remember new passwords every 30 days. Rather than limiting password age, it may be better to focus on stronger passwords and better user awa reness. A more realistic time for the average user may be 90-120 days. I f you give users more time, you may find it easier to convince them to u se better passwords. You Should Never Write Down Your Password Although this is often good advice, sometimes it is necessary to write do wn passwords. Users feel more comfortable creating complex passwords if they are able to write them down somewhere in case they forget. However, it is important to educate users on how to properly write down password s A sticky note on the monitor is not a good policy, but storing passwo rds in a safe or even a locked cabinet may be sufficient. And don't negl ect security when it comes time to throw those passwords away, many pass words have been compromised after hitting the garbage dumpsters. You may want to consider allowing users to save passwords in software-bas ed password storage utilities. These utilities allow a user to store man y account passwords in one central location, locked with a master passwo rd. If you know the master password, you gain access to your entire list of passwords. But before allowing users to save passwords in such tools , consider the risks: first, it is software-based and therefore can itse lf become a target of attack, and, second, since it is all based on a si ngle master password, that password becomes a single point of failure fo r all the user's passwords. The best technique is to combine technology, physical security, and company policy. Its not uncommon to see a com pany in a panic because their a... |
| www.useit.com/alertbox/20001126.html Jakob Nielsen's Alertbox, November 26, 2000: Security & Human Factors Summary: A big lie of computer security is that security improves as password com plexity increases. In reality, users simply write down difficult passwo rds, leaving the system vulnerable. Security is better increased by des igning for how people actually behave. Usability advocates and security people have opposite goals that create a fundamental conflict: * Usability advocates favor making it easy to use a system, ideally req uiring no special access procedures at all, whereas * security people favor making it hard to access a system, at least for unauthorized users. By recognizing that the real goal of sec urity is to minimize the relative amount of unauthorized use. Although a system with extremely poor usability would certainly discourage unautho rized users, it is likely to turn off the target users as well. "Secure" Passwords Facilitate Break-Ins The big lies of computer security? In reality, passwords that comply with the above list of "security-enhanc ing" principles lead to one outcome: Users write down their passwords. T ake a walk around any office in the world and you can collect as many pa sswords as you like by * looking at the yellow stickies pasted onto terminals, * finding the cheat sheet in the user's top drawer, or * searching the user's hard disk for the file that inevitably contains all required passwords in one conveniently machine-readable spot. Higher Security Through Realistic Design The only people who can remember many long strings of random elements are circus performance artists. Better to design for the rest of us (and ou r limited memories). When you require simple passwords that users can remember, you increase t he probability of passwords being kept secret. The same goes for passwor ds that users choose and that they don't have to change too frequently. While it's true that such passwords are easier to crack, the vast majorit y of security breaks come from intruders (or insiders) who expose a huma n weakness, not those who run code-breaking algorithms. In the future, security will improve through biological verification mech anisms, such as fingerprint recognition or retina scanning. However, it will take time for this infrastructure to be built (and fingerprint syst ems won't work for some people). In any case, for now, it is best to avo id imposing awkward log-in procedures and instead simply cookie users on systems with low security needs. With ecommerce in particular, users should not have to create a userid an d password before they can shop. How many sales are lost because shopper s either cannot think up a unique userid or don't understand how to deal with passwords? Web Design for Usable Security Even if you remove registration from the critical path, you might still n eed a way for users to become members of your site. This necessity can c reate a classic usability problem, especially if you require an email ad dress as the userid. In many cases, users assume you are asking for thei r email address and their AOL password, which they then enter, creating a security problem (assuming users get to this stage; many are shut out at the gate because their password is hardwired in their software and th ey can't remember it). Nonetheless, I do recommend letting users enter their email address inste ad of a userid: It's guaranteed to be unique and it is easy to remember. However, you should always recommend that they choose a new and differe nt password. Also, in usability testing, I've found that some users expe ct the system to create the password and then e-mail it to them. You sho uld thus make it explicit that they must create their own while register ing or you risk having users either get stuck or close their browser bef ore completing their account set up. Many websites have harsh requirements for password format. Obviously, a system for tradin g millions of dollars must be more secure than one that lets people read the daily news. If your rules are too strict, many users will not be able to use names an d passwords that make sense to them. This increases the likelihood of us ers forgetting their login information the next time they visit. Forgott en passwords are the cause of countless repeated registrations across th e Web: People often have five to ten "accounts" on the same website. You should place instructions for userids and passwords immediately next to the field label: Password: at least 6 characters Any other placement and many users will not read the instructions. Single Sign-On Every security study I have ever conducted has had a common major finding : Users want a single log-in that follows them as they use the system. Ideally, the system i s the users' total experience and thus they should only have to identify themselves to the computer once. The fact that they are actually browsi ng multiple websites should not be the users' problem. Indeed, in the fu ture, personal computers will probably become truly personal and serve a s users' agents in cyberspace, including taking over responsibility for passwords and identification. For now, at a minimum, "the system" should include everything under a use r's control. This means, for example, that users should have a single lo g-in for viewing their account and trading, and a single log-in for ente ring an extranet and checking on the status of an order. Although the ba ck-end might need to enforce certain privileges for certain users, it sh ould do so transparently without the need for additional log-ins. research study on intranet usability, testing the intranets across a large number of companies, found that the sign-on process had the second-largest impact on employee productivity of the f actors we tested. Logout For sensitive systems, many users feel more comfortable when they see an explicit logout button. For most systems, however, you can assume that u sers will not log out and instead will simply leave. That's the spirit o f the Web and that's what the security system must support. However, do not set time-outs to trigger too soon or you will annoy people who are s imply taking a break from using your site. For most non-sensitive applic ations, a time-out interval of an hour will accommodate lunch breaks and still provide decent security. |