Wednesday, October 15, 2014 - 16:15

Last week we talked about using multi-factor authentication to protect access to your accounts. Even with multi-factor enabled for your Duke and other accounts, it's also important to consider how you are securing your passwords for those sites. Take a look at the top 25 worst passwords for 2013. Is your password "password" or "letmein" or "princess?" If so, now's a good time to change it.


But how do you keep track of different, strong passwords for each account you own? One method would be to write them down, but that's not always a good idea, because what happens if the piece of paper or sticky note is stolen? Another might be to store them in a Word document or Excel spreadsheet. But what happens if an attacker (or your kids) gets access to your computer?  


From a security perspective, LastPass is a great alternative to the challenge of managing and storing unique, random passwords for each site you visit. Duke offers a premium upgrade for LastPass free to all faculty, staff and students. With LastPass premium, you can create an encrypted password “vault” that stores all your passwords; change passwords for existing accounts to long, strong passwords; automatically fill in the user account and password when logging into sites; and audit your passwords with LastPass's “security check” to identify areas where you can improve your online security.


You can download LastPass free from Duke OIT’s software site:

Tuesday, October 14, 2014 - 11:00

In the past year much noise has been made about TLS (Transport Layer Security) due to the Heartbleed vulnerability and the subsequent (ongoing) audit of the OpenSSL project. While most hosts are now patched for Heartbleed (you have checked all of your devices, right?), the proper configuration of TLS/SSL and the associated cipher suites on web servers is an ongoing issue that most people haven't thought about. As it turns out, a proper TLS implentation with Perfect Forward Secrecy enabled could have negated some of the effects of Heartbleed to begin with. There are many other reasons for configuring TLS properly, so let's dive in.


Hold on. What happened to SSL?


TLS is the successor to SSL though the term SSL still hangs around, especially as it pertains to digital certificates. So, when we're talking about TLS, you can assume it pertains to everything we've previously called SSL. TLS is actually on its third iteration now (version 1.2), so SSL should absolutely be considered a legacy protocol at this point.


The TLS Configuration


How you configuration TLS will depend on the web server you're using. For example, an Apache webserver's TLS configuration can usually be found in the httpd.conf or ssl.conf file. For an IIS web server, typically registry keys have to be modified in order to configure TLS. How to configure your brand of web server is beyond the scope of this document, but we will get in to some specifics below. We'll also provide some links for Apache and IIS at the end. Regardless of the type of server you are using, there are three things you need to know:


1. SSL is Dead


Unless you have a very good reason for enabling it you should disable all versions of SSL. SSLv3 may rarely be needed to ensure backwards compatibility with older browsers, but any modern browser will no longer need it. SSLv2 should never be enabled as the protocol is broken and insecure. Edit: As of the evening on the date this entry was originally published, SSLv3 is now also considered broken. Google published a vulnerability in the protocol, which preculdes it from further use. TLS should be considered your only option at this point.


2. Higher versions of TLS are More Secure


TLS 1.0 is less secure than TLS 1.1, and TLS 1.1 is less secure than 1.2. The more modern the browsers that will be connecting to your site, the more restrictive you should be about supporting higher versions of TLS. If you have analytics that tell you 99% of users are using the most recent versions of the major four browsers, you should consider a strict TLS 1.2 implementation. For more information about which versions of TLS are supported by which browsers, please see this table:


3. Cipher Suite Order Matters


This is where most TLS implementations go wrong. Even if you've done everything else correctly, if you don't set the cipher suite order correctly your implementation will be broken. For those who may not know, ciphers decide exactly which types of security will be used for the TLS connection. The order of the accepted cipher suites in your TLS configuration tells browsers what the server's preference is for the cipher suite to be used. If a weaker cipher suite is listed first, that's the one that will be used. The IT Security Office recommends following the Mozilla Foundation's guide to cipher suites. (Link: Their guide details both a preferred cipher suite list for backwards compatibility, as well as a more progressive suite where backwards compability is less of a concern.


One more thing: Perfect Forward Secrecy


Perfect Forward Secrecy (PFS) is an extra layer of security for TLS that protects past TLS communications that may have been intercepted in the event that the server's private key is compromised. For a full explaination, see the Mozilla Foundations guide to Forward Secrecy (Link: Cipher suites supporting PFS should always be at the top of a configured cipher suite list. Some older versions of OpenSSL may not support PFS, but better support for PFS and later versions of TLS would be strong reasons to consider upgrading.


Is My Web Server Okay?


Probably not. In fact, most web servers using SSL/TLS are not optimally configured. That has slowly been improving in the wake of Heartbleed, but there's still much work to be done. If you'd like to check your SSL/TLS site, the ITSO highly recommends the use of Qualys' SSL Labs site (Link: This site will detail any configuration issues and grade your site overall.


As always, if you have any questions or require assistance in securing your site, please contact the ITSO at We're always happy to help. And remember, encrypt everything!


For more on Apache TLS configuration:


For more on IIS/Windows Server TLS configuration:



Wednesday, October 8, 2014 - 16:02

Passwords are one of the most important and least secure security protections we all use. Take a minute to think about how many sites you access with a password: Duke, Facebook, Twitter, Instagram, Gmail, Evernote, Apple, Amazon, Netflix, Twitch, your bank, and maybe a few others.  How many of those passwords are the same?  


In recent weeks, 5 million Google passwords were exposed and celebrity photos leaked online after a suspected iCloud breach. What would you do if your account password was stolen? What could an attacker do or see?


A 6-character password can be cracked in less than four minutes, and an 8-character password in a little more than a month.


While passwords are a challenge, they don't appear to be going away anytime soon.  So, how do you protect access to your accounts? This is where the concept of two-step or multi-factor authentication comes in. Multi-factor authentication is based on something you know (your password) and something you have (such as your phone or a hardware token like a Yubikey). If an attacker gets your password, they would still have to get access to that second “factor” to access your account.


Duke offers multi-factor authentication ( that can be used to secure your NetID and access to various web applications at Duke. More than 6,100 individuals have registered so far, and we would like to see everyone at Duke try the service out.


You can also use multi-factor authentication for accounts at institutions like Facebook, Twitter, iCloud, Evernote and Bank of America. Check out this guide for more information on services that use it:


So what do you need to do about all those passwords you have? Next week we'll talk about how you can use LastPass to store and create different passwords for all your accounts.