Passwords

1. Passwords Joe St Sauver, Ph.D.Security Programs Manager, Internet2(joe@uoregon.edu or joe@internet2.edu) NWACC Security Conference, Portland, Oregon Wednesday, November 18th, 2009, 1:00-2:15PM http://www.uoregon.edu/~joe/passwords/ Disclaimer: All opinions expressed in this presentation are solely those of the author and do not necessarily represent the official opinion of the University of Oregon, Internet2, or any other entity.

2. The Format of This Talk; Acknowledgments and Disclaimer • Yes, this is another one of those oddly formatted "Joe talks." For those who haven't seen one of my talks before, I make them verbose so they’ll be readable after the fact for those who couldn't be here today, as well as for search engines, readers for whom english is a second language, the hearing impaired, etc. Please don't let my odd format shake you up. :-) I promise I won’t read my slides to you, nor do you need to read them as I talk. • With that out of the way, I’d like to thank Adrian Irish of the University of Montana and NWACC for the chance to talk today, although I should remind folks that all opinions expressed represent solely my own perspective, and do NOT necessarily represent the opinion of Adrian, UMT, NWACC, Internet2 nor the University of Oregon.

3. The Original Invitation • Speaking of Adrian, when he’d originally asked me to come and present, we talked a little about potential topics for this meeting. Since I’d recently been at the annual Anti-Phishing Working Group (APWG) meeting and eCrime Researchers Summit in Tacoma, he suggested that I consider talking about phishing, or maybe malware. • I mulled that over, then counter-proposed “passwords.” Adrian assented, although he cautioned me that “this is a fairly technical, details oriented, hands on group.” • Those of you who know me, and the way I tend to approach things, know that he probably didn’t need to worry too much about that particular point. • Oh, and by the time we’re done, you may believe I decided to cover Adrian’s original suggestion, anyhow. :-)

4. Some Specifics of Our Coverage • Oh yes, while you may know (or quickly notice), while I’m generally a Unix-oriented person, I’ll try to remember to include at least a little Windows-related stuff in this talk, too. :-) • I’ll also tell you right up front that while I may mention specific products, those product references are meant by way of example, and should not be taken as denigrating equally capable alternative products (I just don’t have room to mention every product in a talk of this length). • Finally, I'm assuming you're only working domestically, so we won't go into export control issues that may come up when we talk about crypto-related stuff, although I will note that a growing number of American colleges and universities have overseas branch campuses, etc.

5. So How Does This Talk Fit Into Internet2’s Overall Security Agenda? • Because I serve as Internet2’s Security Program Manager under contract through the University of Oregon, I try to make sure that the topics I cover when speaking to the community fit into Internet2’s overall strategic plan, and into the security topics that we’ve identified for attention (see: www.uoregon.edu/~joe/security-tasks.pdf )If you check out that list of security-related tasks, you’ll see that item six is “Replacing traditional passwords” and item three is “Phishing.” • I’m always happy when I color within the lines. :-) • Before we dive into today’s topic in depth, however, let me just give you today’s one slide sound-bite-length takeaway message…

6. Today’s Talk’s Sound-Byte-Length Message • Traditional passwords are insufficiently secure. The time has come for you to replace traditional passwords with hardware crypto tokens (or some other more-secure-than-traditional-passwords authentication mechanism). • So we’ve got an hour or so to talk a little about why I feel that way, and why I think you should, too. I also want to make sure I leave some time for questions and discussion at the end…

7. Some Authentication Options • When it comes to authentication options, conventional options include:-- something you know (such as a password)-- something you have (such as a hardware crypto token)-- something you are (biometrics, such as retinal scans) • We might also consider “authentication architectures” where “what you can access” is controlled by “where you are,” whether that’s via an nnrp.access file in INN (limiting access by IP address range), or a closed point-to-point circuit-based network architecture. • In reality, however, at least today, authentication is normally all about passwords.

8. Passwords Are Ubiquitous • It is hard to think of an online service that doesn’t use traditional passwords of one sort or another…-- workstation, server, network device and mobile device logins including wireless auth, VPNs, etc. -- networked applications such as your email (and instant messaging, and calendaring, and…)-- many web sites (such as Amazon, eBay, Facebook, etc.)-- campus course management systems (e.g., Blackboard)-- campus administrative systems (with FERPA data)-- online financial accounts (with GLB data)-- medical and insurance-related sites (with HIPAA data)-- etc., etc., etc. • We truly use passwords everywhere.

9. So That Means All of Us MustTrust Passwords, Right? • Quick informal poll: How many of you do trust passwords?Put another way, knowing the sensitive assets that passwords protect, do you feel secure that passwords provide adequate protection for those resources and information assets? -- Yes? -- No?-- Gee, Joe, I wish you hadn’t asked that question! • If some of us don’t completely trust passwords, that may point to a problem, because…

10. Passwords Are Truly Critical to IT Security • If one or more of your passwords are compromised:-- confidential materials may be accessed or disclosed (resulting in you being sued/fired/arrested)-- critical files may be surreptitiously modified or deleted, (including potentially irreplaceable data)-- you may be denied access to your own resources (e.g., if the bad guys decide to “lock you out”)-- your personal or institutional reputation may be damaged (for example if spam is sent from your account, your college may end up being blocklisted)-- miscreants may take your money or even co-opt your identity • I think passwords play a critical security role, so if we’re going to rely on them, then they’d BETTER be trustworthy

11. Thought Experiment: Would You Trust (Just) Traditional Passwords To Secure Access To… • Industrial control systems (“SCADA”), including life safety-critical things? Apparently many people do, at least for things like transportation facilities, power plants and energy transmission facilities, chemical factories, etc. • How about sensitive national security information, such as confidential diplomatic, defense, law enforcement, or intelligence-related information? • In fact, since I mentioned defense systems, let’s play “war games” for a minute: would you trust a password to adequately secure a thermonuclear weapon and its delivery system? • I sure wouldn’t, and apparently the Air Force didn’t, either, although not for the reasons you might think.

12. Nuclear Weapons and “Passwords” • Keeping Presidents in the Nuclear Dark(Episode #1: The Case of the Missing “Permissive Action Links”)Bruce G. Blair, Ph.D, CDI President, bblair@cdi.orgFeb. 11, 2004 Last month I asked Robert McNamara, the secretary of defense during the Kennedy and Johnson administrations, what he believed back in the 1960s was the status of technical locks on the Minuteman intercontinental missiles. […] McNamara replied, in his trade-mark, assertively confident manner that he personally saw to it that these special locks (known to wonks as “Permissive Action Links”) were installed on the Minuteman force, and that he regarded them as essential to strict central control and preventing unauthorized launch. When the history of the nuclear cold war is finally comprehensively written, this McNamara vignette will be one of a long litany of items pointing to the ignorance of presidents and defense secretaries and other nuclear security officials about the true state of nuclear affairs during their time in the saddle. What I then told McNamara about his vitally important locks elicited this response: “I am shocked, absolutely shocked and outraged. Who the hell authorized that?” What he had just learned from me was that the locks had been installed, but everyone knew the combination.The Strategic Air Command (SAC) in Omaha quietly decided to set the “locks” to all zeros in order to circumvent this safeguard. During the early to mid-1970s, during my stint as a Minuteman launch officer, they still had not been changed. Our launch checklist in fact instructed us, the firing crew, to double-check the locking panel in our underground launch bunker to ensure that no digits other than zero had been inadvertently dialed into the panel. SAC remained far less concerned about unauthorized launches than about the potential of these safeguards to interfere with the implementation of wartime launch orders. And so the “secret unlock code” during the height of the nuclear crises of the Cold War remained constant at OOOOOOOO. [source: http://www.cdi.org/blair/permissive-action-links.cfm ] • [And if you want something “better” than PALs, how about this one: “British Nukes Were Protected With Bike Locks,” http://news.bbc.co.uk/2/hi/programmes/newsnight/7097101.stm ]

13. Managing Risk • This is the point where someone probably will speak up and say something like: “But Joe!!! Security is really all about managing risk! Sure, passwords aren’t perfect, but in our case we’re not trying to secure nuclear weapons, we’re just trying to keep email accounts from sending spam or kids from logging in and changing their grades! Passwords are secure enough for that sort of thing!” • Maybe, maybe not -- that’s what we’ll spend some time talking about today. Maybe by the time we’re done, I will have been able to change your mind.

14. Cost/Benefit Analysis • This is also the point where other people may chime in: “BUT JOE! I’d *love* to replace traditional passwords with something stronger/cooler, but we just can’t AFFORD it! When we do a cost/benefit analysis, the numbers just DON’T work!” • We’ll also talk a little about *that* argument a little later in this talk.

15. The Insecurity of Passwords: Let Me Count The Ways I Love Thee

16. 1. People Will Pick Weak Passwords • We know from personal experience that if users are given the chance to do so, they’ll routinely pick “weak” passwords, including:-- password == username-- trivially short (6 character or less) passwords-- passwords that use only lower case letters-- passwords that are words in the dictionary-- passwords that are a pattern on the keyboard (12345678, qwerty, etc.) • Why are weak passwords a problem? Well, weak passwords can be successfully attacked with either brute force attacks (password = a, b, c, d, … z, aa, ab, ac, ad, … az, ba, … zzzzz), or via dictionary attacks (try all words found in the dictionary as potential passwords)

17. You Can (Try To) Force Users to Pick Strong Passwords • For example, you can use modules such as pam_passwdqc to do password length and quality enforcement, see http://www.openwall.com/passwdqc/ • Users WILL complain if you impose sufficiently fascist password quality requirements, and visits to the helpdesk will go up if users find it "impossible" to pick a password that will “pass muster.” [maybe try password generators?] • Users may also employ “alternative channels” (such as manual password changes by privileged administrators) to overcome password policies which they don’t “buy into." • Recommendation: system admins and/or security admins (with prior mgmt approval!) should audit user passwords using commonly available password cracking tools…

18. Password Cracking Tools • There are many password cracking tools in circulation, both “open source” and commercial. • I never like to help the script kiddies by providing pointers, but note that these tools aren’t exactly “obscure.” See, for example, the results of Googling forpassword cracking toolsincludinghttp://sectools.org/crackers.html

19. A Sample Tool From the Sectools.org Listing

20. One Password Cracking Approach Particularly Worth Highlighting: Rainbow Table Methods • Most computational algorithms, including password cracking algorithms, involve tradeoffs between time and space, e.g., I can use more CPU, or more RAM or disk storage, depending on how (algorithmically) I decide to attack a problem. Rainbow tables use precomputed stored hash chains (e.g., more storage) to dramatically reduce the CPU/clock time required to crack password hashes. • For more information on Rainbow Tables, see:http://project-rainbowcrack.com/ and http://project-rainbowcrack.com/tutorial.htm andhttp://www.ethicalhacker.net/content/view/94/24/

21. A Sample Open Source In-Situ Brute Force Network “Auditing” Tool

22. Can "Brute Forcers" Accidentally (or Intentionally) DDoS Your Users?

23. More In-Situ Brute Forcing Points To Consider • Are you limiting the number of password attempts you allow? For example, after three failed logins do you stop listening to additional login attempts from a source IP, but only for a period of time? [see preceding slide!] • Do you log (and analyze!) all authentication failures? • If you use the same authentication service for multiple network applications, do you track/limit/log login failures from ALL of them? Or are you only protecting one service (such as sshd) while allowing someone to flood "more obscure" services (such as POP3 or IMAP) with query traffic w/o those attacks being detected and handled? • Moving services off their default ports, and/or using port knocking can help cut down on the network noise; if you'd like to read more about port knocking, see…

24. portknocking.org

25. A Comercial Parallel GPU-Enabled Password Recovery Product From A Russian Company

26. Shadow Password Files • Of course, offline password cracking tools require password hashes as input, and these days most operating systems store password hashes as shadow files, accessible only by privileged users. • Shadow files are still of great interest to crackers, being among the top 10 targets seen by the Honeynet Project (see www.honeynet.org/book/export/html/14 ) • Hmm… what might a cracker do? Well, let’s assume he/she manages to obtain access to your backup server, or to your unencrypted backup media, including a copy of /etc/shadow … Suddenly, (s)he’s got plenty of fodder to feed to his/her favorite password cracking tool(s). • Now you know one reason why I tend to harp on the importance of encrypting and/or controlling access to your backups!

27. Passwords Encryption Algorithms • You should insure that you're using a strong password encryption algorithm (assuming your operating system gives you that choice). • Some systems may still be storing passwords encrypted with the traditional “crypt” based on 56-bit DES encryption. That’s pretty bad. You shouldn’t use it. • There are alternative password encryption algorithms available on at least some systems, such as Redhat Linux, including MD5 (identified by the leading $1$ in the printable form of the password file), and Blowfish (tagged with $2$ or $2a$), however I’d recommend SHA256 ($5$) or SHA512 ($6$), which may be the default on (some) distros. See people.redhat.com/drepper/SHA-crypt.txt and kbase.redhat.com/faq/docs/DOC-15806 and httpd.apache.org/docs/2.2/misc/password_encryptions.html

28. LAN Manager Password Hashes on Windows • On many versions of Windows, password hashes are stored in multiple formats: LM hash (for "compatibility"), plus other formats. LM hash format hashes are vulnerable to fast brute force attacks. For example, LMCrack says, “The design goal of LMCrack was to walk a large key space based on a dictionary style attack rather than on a comprehensive brute force attack and to complete the task in under 5 minutes. The result is a program that utilises a database of pre-computed hashes, which can search an effective key space of 3 trillion passwords in less than 60 seconds with an average success rate of 50+%.” (ouch) • See “How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases,” support.microsoft.com/default.aspx?scid=KB;EN-US;q299656& (or tinyurl.com/no-lan-man-hashes )

29. Windows Syskey • “How to use the SysKey utility to secure the Windows Security Accounts Manager database”http://support.microsoft.com/kb/310105/ “The Microsoft Windows 2000, Microsoft Windows XP, and Microsoft Windows 2003 Security Accounts Management Database (SAM) stores hashed copies of user passwords. This database is encrypted with a locally stored system key. To keep the SAM database secure, Windows requires that the password hashes are encrypted. Windows prevents the use of stored, unencrypted password hashes. “You can use the SysKey utility to additionally secure the SAM database by moving the SAM database encryption key off the Windows-based computer. The SysKey utility can also be used to configure a start-up password that must be entered to decrypt the system key so that Windows can access the SAM database. This article describes how to use the SysKey utility to secure the Windows SAM database.”

30. Sometimes People Don’t Even Bother Changing Default Device Passwords • Not changing default/well known passwords is an extreme example of “picking bad passwords”, but it is still all too common. • You may or may not be aware that lists of default/well known passwords for particular devices are in widespread circulation -- if you didn’t know this, you do now. • It is absolutely critical that any or all default accounts/passwords get changed (or disabled) whendevices are put on the wire.

31. One Example of A Default Password List

32. Some Malware Includes Password Attack Code Targeting Poor Password Choices

33. 2. People Will Disclose Their Passwords • Users will disclose their passwords in many different ways. • For example, phishing exists because people can be “socially engineered,” into revealing their passwords. • If you have users whom you’ve trained to be cynical, skeptical and defiant, they may (properly) refuse to reveral their passwords when receiving phishing attacks. Unfortunately, some regions of the country (e.g., the Midwest), and some groups (including higher education, unfortunately) have cultures which reward trust and unquestioning compliance when confronted with authoritatively presented demands:Phisher: “Tell me your password immediately!”User: “Okay, okay! It’s LetMeIn123, don’t 'disable' me!” • Small bribes can also work wonders…

34. Source: http://news.bbc.co.uk/2/hi/technology/3639679.stm

35. Sharing Passwords • Sometimes users will “voluntarily” share their password with others (even without chocolate!)… For example:-- An executive delegates triage of her email to her administrative assistant; sometimes the administrative assistant is out sick or on vacation, so the executive’s password is also shared with the backup admin assistant, and of course the password’s never changed…-- Supervisors may demand to know the password of subordinates accounts so that they can “access critical files” the subordinate may be working on when the subordinate is sick or out on vacation.-- Spouses often will routinely trust each other with their passwords, even though they shouldn’t (sorry, honey, we’ve been married 25 yrs but you simply don’t need to know!)

36. Writing Passwords Down • If password requirements are sufficiently complex, users have little choice but to record them if they’re to have a hope of remembering all them. • The yellow sticky note on the side of the monitor is the stereotypical password repository site (although others may favor the top drawer of their desk). • This presents obvious risks if you have visitors (and even if you don’t think you have visitors, you probably at least have custodial staff occasionally servicing your office) • Carrying ones passwords in one’s wallet is probably at least marginally more secure, although it isn’t ideal. (You can read one person’s take on the wallet as an option athttp://askthegeek.kennyhart.com/index.php/2009/02/04/why-your-wallet-is-the-best-password-manager/ )

37. Sharing Passwords With Any/All Users of Their Computer • We all know people who routinely save their passwords in applications such as email clients, so that anyone who physically is at their computer can automatically “login” as them just by sitting down at their computer and starting the application with the saved password. • Requiring a username and password to login to the computer, and/or consistently employing a locking screen saver, and or/or using RF proximity cards (such as the "walk away security" cards from Xyloc) , may help control that exposure, but saving passwords in apps is still an evil practice, and one that causes a lot of forgotten password issues (“I can’t remember what I set my password to, I just saved whatever it was in my client”).

38. Another Form of Password Sharing: Password Reuse on Multiple Sites • Other users will share passwords across multiple systems, using the same password for critical, highly sensitive administrative systems, and for their online bridge club account (and for <fill in the blank>). If I can crack their password on any of those systems, I’ll be able to get into ALL of their accounts, including the highly sensitive ones. • Sometimes users will even give login information, including passwords, to other sites to save and routinely re-use. Classic example of this is email POP consolidation, where a free web email account may offer to use your credentials to periodically fetch other email by logging in to a remote system as you (I kid you not). Obviously, unless it is going to prompt you for your password each time it does this, it needs to know/save your unhashed (raw) password.

39. Example of POP Email Consolidation: Gmail

40. Example of POP Email Consolidation: Yahoo

41. “Rubber Hose Cryptography” • We must also recognize that if someone wants your password badly enough, they may be willing to use extreme physical measures, such as torture, to get it. This is sometimes sardonically referred to as “rubber hose cryptography.” • A (somewhat) more civilized version of “rubber hose cryptography” would be judicially mandated password production (presumably under threat of contempt of court). See, for example, the case of Sebastien Boucher…

42. See http://arstechnica.com/tech-policy/news/2009/03/court-self-incrimination-privilege-stops-with-passwords.ars

43. Password “Safes” • Some users, overwhelmed by password proliferation, don’t even attempt to memorize all the passwords they need to juggle, they simply store them in an online encrypted password “safe” or password “wallet.” One example of such a product is KeePass (see http://keepass.info/ ). • While this is convenient, obviously this is a case of putting all one’s eggs in one’s basket. Should the password safe or password wallet be compromised, you’re likely to experience severe problems. • I would be particularly wary of password safes which tightly integrate with browsers or other applications; if you use a password safe, I’d suggest using one that merely displays your username and password, at which point you can manually enter those values into applications as you deem appropriate.

44. 3. Passwords Will Be Sniffed • In addition to people picking weak passwords, and sharing those passwords in various ways, passwords will also be captured, or “sniffed.” • “But Joe, everyone knows that passwords should only be sent over encrypted channels! You’d have to be an idiotto send your password in clear text over the wire!”

45. Passwords From SC2009, In PDX This Week

46. And If The Smart Guys From SC Screw Up… • SO WILL YOUR (EVEN SMARTER) USERS. I promise, your users WILL send their passwords over unencrypted links. • I’m also willing to bet that at least some of you enable or facilitate those mistakes by permitting plain text password-using daemons (such as telnet, ftp, etc.) to continue to run on your local systems, or by allowing unencrypted web login pages. • You need to go on a personal crusade to stomp out any and all remaining plain text-using protocols running on your campus network. • FTP (as used by many web page development and publishing tools) is a particularly probable source of exposure.

47. “BUT JOE! We’re 100% switched! We’re Safe!” • From time-to-time I run into people who believe that they don’t have any sniffing exposure because their network architecture is 100% switched, and in such an architecture network traffic shouldn’t be visible to eavesdroppers (the way it would be on a shared network link). • I would suggest that between arp spoofing, mac flooding, and mac duplication (among other methods), there’s a good chance that a bad guy or bad gal can still arrange to see network traffic even in a fully switched environment. • For those who insist on details, see for examplehttp://monkey.org/~dugsong/dsniff/ or http://www.oxid.it/cain.html • Switched networks do NOT provide sufficient protection against network traffic sniffing

48. “BUT JOE! We have a VPN!” • Another technology that’s often trotted out as a solution to the problem of sniffing is the use of VPNs. • Virtual private networks provide an encrypted tunnel between the end user’s workstation and the VPN concentrator. As far as they go, they’re fine, they just don’t far enough: VPN’s are NOT “end-to-end secure,” they’re only “one-end-to-VPN-concentrator secure”, and a bad guy can still attempt to sniff the VPN’d traffic after it exits the VPN in clear text. • Don’t get me wrong, VPNs can help reduce the traffic exposure problem, and if you’ve got one, I’d certainly encourage you to still use it, you just need to recognize that you still have traffic that’s exposed. • VPNs are not (complete) protection against sniffing.

49. VPN vs. End-to-End Encryption

50. “BUT JOE! We *DO* Encrypt End-To-End!” • Excellent! I’m delighted to hear that you’re using ssh and SSL/TLS to minimize your exposure to sniffing on the wire! It is an important step! • Unfortunately, you’re still not safe from eavesdroppers snarfing your passwords… • Let me give you just a few examples…