SDL Episode85

From Paul's Security Weekly
Jump to: navigation, search

Secure Digital Life #85

Recorded on October 23, 2018 at G-Unit Studios in Rhode Island!

Episode Audio

Coming soon!

Hosts

  • Doug White
    Cybersecurity professor, President of Secure Technology, and Security Weekly network host.
  • Russell Beauchemin
    Cybersecurity & Network Security Program Advisor and Director of Instructional Support & Learning Innovation at Roger Williams University.
  • Announcements

    • If you are interested in quality over quantity and having meaningful conversations instead of just a badge scan, join us April 1-3, at Disney's Contemporary Resort for InfoSec World 2019 where you can connect and network with like-minded individuals in search of actionable information. Use the registration code OS19-SECWEEK for 15% off the Main Conference or World Pass.
    • One of our illustrious co-hosts, Patrick Laverty, will be co-presenting "Pentesting: Tips, Tricks and Stories" with Aaron Herndon at BSides CT 2019! Ticket sales are open until the day of the show (Saturday, November 3rd) for $20. Go to bsidesct.org to register now!
    • Join us for our Webcast with Signal Sciences entitled Which way should you shift testing in the SDLC? This webcast will be held November 8th @3-4pm EST. Go to securityweekly.com/signalsciences to register now!

    Topic: Two Factor Authentication



    What is two factor authentication and why should you be using it?

    Today on SDL, Doug and Russ talk about the mysterious world of 2fa. This is something you hear all the time and more and more sites are requiring/supporting it but should you be using it. Stick around on SDL to find out.

    • So, the traditional way that you identify yourself is with some "id" and some "password" which are two things that are entered into a database of some sort. These things were often designed with fixed length fields (due to programming language restrictions and database restrictions or even just design restrictions). It was not at all uncommon to see a 4 DIGIT requirement even (often called a PIN number). Even today, you still see 4 digit pin requirements.



    • Other restrictions. 8 bytes was pretty common and it wasn't at all unusual for password fields to have only asc chars allowed in them. Sometimes, even upper case wasn't allowed (never figured that one out).



    • Now, in the original systems, passwords were often saved in a big text file and it was just literally, the user name in one column and the password in the next. This created a problem when people stole the files and as such had all the information.



    • In the database model, the same thing was true. Now, an SQL database gets involved and they have a column with passwords. Anyone who could dump the database could get all the information. SQL injection attacks were reasons people wanted to run big queries like select * from * or something and get all the usernames and passwords that way.



    • Even when these models changed and they started storing passwords "encrypted" it was possible to use the "salts" and crack the password if you had the file. See, Shadow and Passwd files in linux for example.



    • One of the big problems is the issue of this happening. If your passwords are stored somewhere, even if that somewhere is really hard to break, what if some other site is not so hard to break. For instance, in Cisco. If you look at a cisco configuration file, the username and passwords are all stored in that file in plain text. There are ways to protect it but all too often we find the password right there in plain text. My experience was that if the cisco set up is dwhite mrfoofoo123. That same password is probably good with dwhite a lot of places.



    • Enter the internet. Now, we suddenly need large numbers of passwords because there are a lot of sites where we have to authenticate ourselves. Each and every one of those really should have a unique password because you can't guarantee that every site you use is going to protect your information. What if the site itself decides to sell your info? Well, you're doomed if your bank account uses the same combo.



    • So, what to do? That leads to the use of what is called 2 factor authentication. This basically, that we take this combo a step further. Now, ideally, we have a three part authentication: Something you have, something you know, and something you are. This would be a 3 way authentication but we aren't there yet. So 2 way it has to be.



    • The way this works is you have something you know (that's your regular password) and something you "have". The current most common instantiation of this is through the use of your mobile device. Your phone is likely protected with some sort of password as well so even if you lose it, well, you know... When you want to use your password, you also have to validate that it's ok by using your phone to reply to a text, submit a texted code (or it can be a call with a message) in order to ensure that both parts of the 2 way authentication are in place. So, now a person who bought your password and username on the internet would have to also get your mobile device in order to succeed in using the stolen password.



    • Another approach to this is a something like a flash drive. Yubikey and other manufacturers make small flash drive devices that have some sort of activation approach that allows you to plug them in and validate the 2FA using the keying system on the device.



    • Yubikeys use a lot of different approaches from generation of a long password to much more sophisticated approaches like FIDO2 standards like "passwordless" (single factor but relies on the hardware device), "two factor" which uses hardware and your password, or "multi factor" which has a password, hardware device, and a biometric of some sort.



    • So, how does this work. 1) The site has to support the device. 2) You create a 2 factor approach with that site. 3) When you want to login to the site, you need to a, enter a password and b, have your hardware device plugged into the system.



    • Is this the end? I don't think so, biometric algorithms like Microsoft Hello, Apple, and other products are using facial recognition and other biometric approaches to validate as well and this seems to be more seamless.



    • What if I lose my device? Well, that's a big problem with hardware devices. When people have small objects to keep up with, they tend to lose them. If you lose your yubikey, it's a big loss but...they would have to have your other credentials and still be able to figure out where you used it and what credentials you used there to make it a problem.



    • Could you break the encryption on the yubikey? Well, of course, you can. Everything can be broken and PGP is no exception but, again, that means you have to have the other credentials too and it may take a long time so unless you are a serious target, it may not be a massive risk.



    • So, our recommendations:
    1. You NEED to be using 2FA.
    2. If you have a mobile device with you all the time, that method works pretty well. You can get a text and use that approach pretty effectively.
    3. If you don't mind carrying around a flash drive on your keyring, I like the yubikey. You can plug it in wherever and use that as a 2FA approach pretty much anywhere.



    Warnings:

    1. Nothing is infallible. If you write your password on a business card and tape your yubikey to the business card and then leave that laying in the airport lounge, well...
    2. You need to use strong passwords and use different ones everywhere (password vaulting like last pass is inevitable).
    3. Make absolutely sure you understand how to roll back from 2FA. If you:
      1. Lose your password
      2. Lose your token
      3. Lose both



    Look, as you add security, you need to have a plan. If you lock yourself out of a lot of these services, the only thing may be to delete your account and start a new one. Make sure, that your 2FA services have some sort of fail safe roll back and that you have a hard copy of that in a vault somewhere.