Two-Factor Authentication – You are Not as Protected as You Think
Request a Demo
0:00:00.6 Damon Tepe: Hello everyone, thank you for joining today’s call. We’re gonna wait another minute or so to just catch those who might be a little late, so we’ll get started here in a little over a minute. Thank you.
0:00:50.8 DT: Alright, well, let’s go ahead and get started. Thank you all for attending today’s webinar titled Two-factor Authentication, You’re Not as Protected as You Think. I’m Damon Tepe, Director of Product Marketing here at SecureAuth and I’ll be joined today by Jeff Hickman, Director of Sales Engineering and Primo Demonstration and Technical guy. We’re going to cover multiple ways attackers can get around popular two-factor authentication method, and how you can protect your organisation from those attackers, while simultaneously providing a clean and least disruptive user experience for your employees, customers and/or partners. Before we begin, let’s get some brief housekeeping items out of the way. So all attendee audio lines are muted. This is for everyone’s listening pleasure. You can submit questions via the Q&A panel at any time throughout the session. It’s located on the right-hand side of the console. I encourage you to do so when questions arise, ensures that you don’t forget when we begin the Q&A session at the end. Those submitted questions will be answered, again, during the Q&A. And if we run out of time, we’ll follow up with you directly. We have roughly 30-40 minutes worth of content, and we’ll follow up with as much time as we need for questions. Slides and a recording of this session will be sent to you later today, so no need to ask this question during Q&A.
0:02:16.3 DT: As a matter of fact, I think under attachments and links, you can get the slides. And there’s an infographic in there too that I’ll talk about later in the presentation. So if you have any questions related to this webinar or any others, you can always contact us at firstname.lastname@example.org. So let’s take a quick look at the agenda to give you a feel for the things I’m planning to talk about. So first, I’ll start off with kind of industry statistics. This is the state of the authentication market in 2019, where I’ll briefly review kind of common problems across industries. I’ll also review numerous ways attackers get around two-factor authentication. I’ll discuss six fairly common ways and cite multiple examples for each, how you can improve identity security beyond two-factor authentication. We’ll both talk about and show how you can analyse multiple pre-authentication characteristics, to determine if you can trust or not trust the identity behind every access request. Greater identity trust equals better user experience, so the more that you trust an identity is who they claim to be, the more authentication steps you can remove for users, like requiring a two-factor authentication disruption. And then lastly, we’ll hold a Q&A session at the end.
0:03:36.5 DT: So let’s just first set the stage and dig into some problems and statistics affecting the access management authentication markets. Gartner estimates the information security spend globally in 2018 to be about $114 billion. That was a 12% increase over 2017. And the projected 2019 spend is roughly $124 billion. This includes network, endpoint, and identity security. Not so much about the actual numbers, but in that same time span, breaches increased 44.7% last year, and 40% the previous year. So basically, the spend is not having the desired effect. 81% of breaches involve stolen or weak credentials, and this points to not all systems being covered with two-factor authentication, many still relying on a password. In a survey we did about a year ago, on average, organisations had 60% 2FA coverage, meaning the other 40% was only password protected, which leads to my next point. Four out of five adults reuse passwords, and we’re all guilty of doing this. The problem is users pick poor passwords. The list of the top five most common passwords of 2018 include 123456, password, and qwerty. And there are billions of stolen passwords available on the dark web. So, that password that a user used for their Yahoo, or Gmail, or LinkedIn account is the same one they use to access your systems. And the attackers can buy that password, regardless of the complexity or links, over the internet on the dark web.
0:05:24.0 DT: In another survey, we discovered that 99% of participants believe two-factor authentication is the answer to their data breach concerns, and believe this will protect them from unauthorised access. But as we’ll cover in a minute, attackers have multiple ways around two-factor authentication, such that relying on it provides a false sense of security. The average US breach now costs 7.9 million. That’s up from about 4 million a year ago, so it’s almost doubled. And that figure includes lots of breaches of small organisations. When we think about some larger breaches like Target and Home Depot, both have spent well over 150 million each on their breach aftermath costs. But despite these rising costs, we’re still not properly protected at the access point. So, many organisations, including many of you in the audience today, are concerned about the user experience during authentication. Authentication disruptions for passwords and two-factor authentication to every system is annoying, and it causes productivity loss. It drives up administration and helpdesk costs. And we’ll explore later in the presentation how looking at multiple risk factors around every access request can provide the confidence to remove those authentication disruptions for users with high trust.
0:06:48.8 DT: In summary, we’re spending more on security yet breaches continue to rise. Passwords and two-factor authentication provide a false sense of security, and breach costs are only rising. User disruptions matter to both users and the organisations that cause them. And we’ll address all of these concerns throughout the rest of the presentation. So let’s now look at some of these popular way cyber attackers can bypass two-factor authentication, but before we dive into the methods they use, I wanna share this quote from CSO columnist Roger Grimes, which was published in May of last year, under the Title 11 ways to hack 2FA. Too many people are overly confident about the security two-factor authentication provides, they think 2FA is un-hackable, undefeatable; when that clearly isn’t true. They think 2FA will stop advanced persistent threats or APT, defeat phishing and social engineering and stop all sorts of threats that it was never designed to do. 2FA suffers from a perception problem that gives it more credit than it deserves, it can be and it is often hacked in a myriad of ways. With that being said, lets dig into these multiple ways attackers are getting around two-factor authentication. For each of these message used by attackers I’ll take the same approach, I’ll describe how it works, and then I’ll give you some real world examples of where it was used.
0:08:13.5 DT: Our first one is real-time phishing, this is typically accomplished by an attacker representing themselves as some authority figure, might be the CEO or CFO of the organisation, could be the helpdesk requesting credentials to verify the user or could be as involved as setting up a fake website that looks exactly like a user’s online bank account or Office 365 account, where an attacker simply takes the input provided by the phished user; credentials, one-time passcodes for two-factor authentication, and then turns around and uses them on the real website or access point, basically assuming the identity of our unsuspecting user victim. Humans will always be a weak point in security. To be human is to make mistakes, it’s kind of what we do, relying on people to always do and know the right things to do in each circumstance, is a recipe for problems. As we’ll discuss later, by taking the authentication process away from humans, we can actually elevate protection. But let’s talk about some real world examples. My first example is to show that this method has been successfully used for many years. Back in 2010, IBM Security Intelligence team discovered that 30% of the attacks against websites using two-factor authentication, used real-time phishing to capture credentials and 2FA codes.
0:09:41.5 DT: And then in December 2018, barely just a couple of months ago, Amnesty International found thousands of phishing emails targeting journalists and activists. They looked like security alerts coming from Google or Yahoo asking for a password reset. Users were then required to provide old new passwords as well as those passcodes from the two-factor authentication. And my last example comes from FireEye, these are the people that come in post breach, assess what happened, helped with clean up and remediation efforts. They also provide Red Team engagement, where they’re hired to attempt to break your defences and exploit weaknesses to prove that you may need more or better security, and FireEye developed a tool in 2018, they call ReelPhish and claim to have successful used it during various Red Team engagement to again, phish those credentials away and one-time passcodes away from users. So we have examples from 2010, all the way up to a month or two ago for this one.
0:10:50.0 DT: The next way that attackers get around two-factor authentication is text and voice call interception. This is where an attacker can intercept an authentication code sent to a phone, the problem like this with the protocol used by phone carriers to communicate between and among them. The protocol is signalling system number seven, it’s probably better known as SS7 and was developed way back in 1975. And it has a glitch that allows attackers to intercept cell tower signals. Which in turns allow attackers to monitor movements, listen to calls, read in forward text messages and voice calls. This method focuses on the phone, so if you don’t use the phone in the authentication process, this one doesn’t really apply, but most organisations are moving to a phone-based authentication model for user convenience.
0:11:45.9 DT: What are some real-world examples here? In 2017 60 Minutes reported the existence of a security hole in modern telecommunication Systems. In 2014, a group of German researchers also revealed this serious security flaw in that SS7 protocol. In 2016, hackers spied on a US congressman exporting this SS7 flaw. They listened in on conversations, tracked geographic movements. They could have easily captured 2FA pass-codes but that wasn’t really their mission. Some of you may remember a year or two ago when NIST, the National Institute of Standards and Technology, almost banned the use of SMS Text in 2FA. It was because of this vulnerability in SS7. Our next approach attackers use is malware or malicious code. And this is also not a new one. We’re talking about malware on the phone, attackers get that malware on the phone, typically by email, it could be via text. Their message looks like it comes from a well-known or frequented business, to that target user. User is ask to click on the link for some important reason, and the malware downloads, installs, changes settings, install certificates and auto-deletes without a trace. The attacker can then have one-time passcodes that are sent to the Phone forwarded to them.
0:13:18.8 DT: My two examples of this are probably on the more popular side, and you may have heard of them, One is the Emmental attacks, the other is the Bankosky Android Trojan, again, both utilise malware on Android devices. In the Emmental attacks targeted unsuspecting victims in Austria, Switzerland, Sweden and Japan, and they were used to access various different users bank accounts. Attackers would have Intercept or get tokens, one-time passcodes, via text or voice call, have them forwarded, and then they’d access, fraudulently, those bank accounts. In the case of the Bankosky Android Trojan, attackers used malware to open a backdoor, sending various info regarding the phone, whether it was location or GPS tracking and ensure any text messages or voice calls could be forwarded to the attacker’s command and control server and then be used to bypass two-factor authentication. It’s worth mentioning, just pausing quickly here and saying that I have links to each one of these examples that I’m talking about. You could probably see the links in the slides. So these slides and the recording will be made available after this call. So you’ll have access to all these articles and research as well.
0:14:38.9 DT: So moving on, this one goes by many different names. So phone number porting fraud, SIM swap, port-out scam, SIM splitting, regardless of what it’s called, it represents a vulnerability to phone-based authentication methods. And so how does it work? Basically, an attacker uses social engineering; collecting data on their intended victim, then calls the victim’s mobile phone carrier and convinces them to move the victim’s SIM card to a phone under the attacker’s control. And from this point forward, any phone-based authentication, text calls, codes, that kind of thing are all compromised. And if you think the carriers would never let this happen, think again. Remember, that carrier wrapped as a human and we all make mistakes. So I have a YouTube video that I’m linking here, shows how this attack works. And so an attacker in less than two minutes convinces a carrier network representative to swap the SIM card to a phone under that attacker’s control. In February of last year, T-Mobile warned all of its customers about this “SIM card scam” and encouraged them to be more judicious in their security. And then, in November of 2018, just three months ago or so, ForexFraud.com titled an article, “Beware of SIM Swap Fraud, the hottest new scam sweeping the planet.” And they detailed multiple examples, one in particular where the Secret Service detained two attackers for allegedly stealing $14 million in cryptocurrency in one, single heist.
0:16:19.6 DT: So, our second to last example is notifications fatigue. And what happens in this example is, an attacker overwhelms a user with multiple authentication request. And this works well for push-to-accept where users simply hit “Accept” or “Approve” if authenticating or “Deny” when not authenticating. And if you look at the phone image I have in the bottom left hand side of the screen, that’s kind of what it looks like. I mean, different vendors might look slightly different. But the problem arises when users want the notification to simply go away, and so they’ll hit “Accept” to make it do so, and the user may be allowing an attacker with stolen credentials to bypass this 2FA security measure when doing so. So for attackers, it’s a number’s game. If you can get one out of five or 10 to act accordingly, they’re in, they can do their damage. I’m always a little amazed when I talk about this one with various organisations. I get the sense they just don’t believe me, and I’m sure there’s some sceptics in the audience right now that are thinking the same thing. Again, I have another YouTube video of a notorious White Hat hacker named David Kennedy talking to DEFCON about how this method worked six out of six times for him at a client site.
0:17:38.8 DT: That’s scary, that not one user did the right thing and hit “Deny.” I also point you to a SecureOps blog post where we detail this problem and even developed a similar 2FA method that require a user to think a bit more and match what they see on the computer screen with that on the phone screen, just to make it a bit harder and not as easy to kinda simply hit “Accept” and then make that notification go away. So the last method that’s fairly easy to get compromised by cyber attackers is knowledge-based authentication. We’ve all been asked these personal questions, “Street you grew up on,” “Name of first pet,” “Grade school teacher’s last name,” but it’s supposed to be information only we or a very few other people actually know the answer to. But with the amount of information posted on the Internet, often through social media, makes finding answers to these questions relatively easy. If you’re active on Facebook, Twitter, LinkedIn, etcetera, you’ve probably posted or been tagged in an old photo showing street name or grade school. You may have uploaded pictures of your pets that have passed away.
0:18:51.0 DT: Attackers have a wealth of personal information available to them about you from a simple Google search, and I encourage you to go to Google and Google yourself, see what pops up. Ice Miller Legal Counsel wrote an article titled, The Password is Dead; is Knowledge-Based Authentication Far Behind? Where they advised against using knowledge-based authentication for all the reasons I just cited. They also say that back in 2016, 78% of Americans had some type of social media profile. Again, that’s three years ago. And in 2017 there were over 1.86 Billion monthly active Facebook users with 293 status updates and 136,000 photo uploads every minute, and that’s just Facebook.
0:19:40.8 DT: So in January of 2018, Forbes published an article titled, Everybody Knows: How Knowledge-Based Authentication Died. The article brings up multiple examples, but they all come back to this tenet. In 2019, people put too much personal information out in publicly-accessible forums like the Internet. So knowledge-based authentication is really not a good idea. Alright, so we’ve spent some time reviewing multiple ways attackers can bypass two-factor authentication, but much more important is explaining how you can protect yourself from these attacks, ensuring the highest level of protection without causing unnecessary authentication disruptions for your users. So I’ll spend some time walking through the next couple of slides explaining how behind the scenes risk checks provide a much more secure access management platform. And then Jeff, who’s been waiting patiently to give you a demo, will finally kinda have his chance.
0:20:36.7 DT: So first, I want to introduce you to SecureAuth adaptive authentication which analyses multiple risk factors around every access request. So SecureAuth looks at device, location, IP Address, user behaviour for clues to attack their presence, each kind of serving as another protective layer. We answer the following questions around those seeking access to protected systems; do we recognise the device? Have we seen this device before associated to this user used once they have successfully passed some authentication process in the past? Is the access request coming from a known location like somewhere you have employees, partners, or customers? No users in Russia, China, or India? Why would someone be trying to access your systems from those locations?
0:21:24.6 DT: We analyse whether an improbable or impossible travel event has taken place. So for example, if John logs in from New York and an hour later attempts to log in from California, we know something isn’t right because it’s impossible to get from New York to California in an hour. We check group membership and attributes for every user; do they have the the correct access rights? We check to see if a particular IP address is on a white or blacklist. A whitelist typically catalogues good IP addresses. It’s often corp IP ranges. And then the blacklist is a collection of known bad IPs, and we check to see if an IP address is coming from an anonymous proxy like a Tor network. Why would a customer, partner, employee be trying to hide their IP address if something wasn’t kinda going on? We can also absorb any risk score from any third-party product and use it in the authentication process. So got an IGA, got a UEBA, SIEM, PAM solution that provides a risk core? SecureAuth can consume it and use it. And if you’re using phone-based authentication, which seems to be very much growing in popularity, we can block access from phone carriers and locations you do not have partners, customers or employee. We can block access from certain phone types.
0:22:44.9 DT: So for example, attackers prefer voice over IP phones for convenience, we can block those phone types from using an authentication process. We can also tell if a phone number has recently been ported or the SIM card has been changed to a different phone and can block access until the new phone and identity can be verified. We can check the IP address against multiple continually updated threat databases of known bad IP addresses that have already been used in malicious acts in the past. And then, lastly, we can check user behaviour against a baseline for every individual.
0:23:21.8 DT: Tom usually logs in between 7:00 AM and 9:00 AM, logs out between 4:00 PM and 6:00 PM every weekday and rarely, if ever, logged in over the weekends. So why then is Tom logging in at 2:00 AM on a Sunday night, accessing systems he rarely ever visits? So we think of each of these risk and context checks as another layer of security. The more layers, the better protected. History shows we have a protection precedence around this security and layers concept. So if we think about a medieval castle, for example, you had moats and drawbridges and high walls and turrets, all act as different protection layers such that if someone could breach one layer, they’re presented with another and another, and yet another.
0:24:05.8 DT: A more modern example would be kind of a building security. You often have a fence, a guard shack, locks on the doors, cameras, key-card access to certain areas, could a would-be attacker get past the fence? Sure. Did they get past guards? Sure, but when we layer them all together, it’s infinitely more difficult to get past them all. So the goal of this slide is really to explain how SecureAuth adaptive authentication stop attackers with stolen credentials and weighs around two-factor authentication. So normally, if you have two-factor authentication in place, all an attacker needs for access is the credentials, username and password of a legitimate user and a way around that two-factor authentication to gain access to the applications on, for example, the right side of the slot.
0:24:55.1 DT: So regardless how an attacker obtains whether it’s OTPs or special codes for 2FA, or whether they’ve gathered knowledge to defeat a knowledge-based attempt, they’re still attempting to access from their own computer, their own location, their own IP address, phone and behaviour, and that’s why we check all of those things. So let’s assume an attacker has legitimate credentials they phished away from some user and used one of the methods we’ve discussed prior to get around two-factor authentication. The attacker machine would still be unknown and would flag SecureAuth as new, never before seen. The attacker’s location could be someplace your organisation has no users, but it could also be from a location where you do, but it’s important to check. The attacker doesn’t know when the legitimate user last logged in and may already be logged in. That’s why we apply that logic to the authentication event.
0:25:47.4 DT: So if a legitimate user logged in from Ohio and an hour later, the attacker attempts to log in using the same credentials but from a location farther than an hour away, it triggers an automatic response. The attacker’s IP address is unlikely to be on a whitelist of approved IPs, nor likely that that IP is on some blacklist of known bad IP, but again, it’s always worth checking. More often than not an attacker is going to try and hide their actual IP address by using an anonymous proxy designed to hide the real IP address. But we check for the use of these anonymizers and can deny access if detected. If an attacker doesn’t use an anonymizer, we can check their IP against, again, that multiple industry threat feeds and know if that was a bad IP address or it was used in previous malicious activity.
0:26:35.9 DT: Assuming are fictitious organisation and its identities use phone-based authentication, the attacker will be using their own phone or a burner phone of some sort during authentication. Hence, why we check the phone carrier. Have no users in Korea, Brazil, or Ukraine? Then no one from those regions should be using a phone to authenticate to your systems. As mentioned before, the phone maybe voice over IP phone and the organisation may have a policy against using that type of phone, and next we check to see if that phone number has recently been ported to another phone. So this action doesn’t mean that the phone has been hacked, legitimate users upgrade their phones all the time, but it’s another piece of the puzzle to consider when looking at all the risk checks together.
0:27:17.7 DT: So lastly, we evaluate behaviour, is this behaviour consistent with the baseline behaviour for that particular user? If an attacker assumes the identity of a legitimate user, it’s highly unlikely that they’re going to act the same as that real user, therefore analysing behaviour for abnormalities can uncover attackers. Could an attacker possibly get past any one of these risk check layers? Yeah, sure, that’s possible, but that’s why we look at all of them. So this is my last slide before we get into the demonstration. This is kind of more a summary of what we’ve talked about and how to protect even if the attacker has credentials and ways around two-factor authentication methods.
0:28:01.1 DT: The bottomline is, know more about the identity that is accessing your systems. The more characteristics analysed, the more clearer that user is known or unknown. Each characteristic evaluated is conceptually another layer of security, and the more layers of security, the harder it is for the attacker to get past them all, more likely that they just move on to an easier target. And if you don’t look, you will not find. If you don’t analyse the device or the location or the IP address or the behaviour, you’re rarely, if ever, gonna find problems, inconsistencies, or anomalies that signal attacker presence. And the more characteristics you evaluate, the more confidently you can be around the access requesting identity is who they claim to be or not.
0:28:45.8 DT: The higher the confidence and trust, the more safely you can remove authentication disruptions for users. So as you can see on the bottom right-hand side of the slide, after SecureAuth goes through all of its risk checks, we can automate the ensuing action. For those with little to no risk, we can remove the 2FA step and give them immediate access. For those with some risks, but not much, we can require a two-factor authentication step. For those with risks high enough, we can force a password reset or redirect to a honeypot, and for those with real high risks, we can just deny the access all together. You as the customer gets to set the sensitivity of what risk level corresponds to what automated action. I’ll leave you with one last stat before turning things over to Jeff here for a demo.
0:29:31.6 DT: Last year SecureAuth processed some 617 million authentications, 90% of the time users were not required to take a two-factor authentication step because the risk checks found no to little risks. So with that, I’m gonna turn it over. Jeff the floor is yours, show ’em some of this cool technology.
0:29:53.3 Jeff Hickman: Awesome. Thank you, Damon. So we’re gonna walk through each individual kind of different attacks that was laid out, and we’re gonna talk about each one and how SecureAuth helps mitigate each of these attacks. Now, I wanna be very clear that security is a layered game, one single solution may not solve all of these problems when it comes to two-factor authentication, that’s why we encourage our customers to look at this holistically and look at all the layers and all the different tools that they have at their disposal to make sure that they’re actually truly secure. With that being said, there are some immediate things that we can do to help make you more secure with these two-factor methodologies. Let’s start with real phish and talk about the actual real-time phishing action here. One of the most important parts about this is that they have used the length or lifetime of a code that is sent to a user to enter the screen or they actually hijacked the session directly. This is why we encourage our customers to use methods that are not phone-based or code-based, such as, push-to-accept or our favourite symbol-to-accept.
0:31:01.6 JH: This is a difficult one to detect purely by technology, because it has some very insidious ways that it mirrors the actual end user when presented to the server for authentication. However, your standard phishing training does apply here using tools like PhishMe or other phishing education platforms really help them benefit out of this type of attack. So as a user here, I’m gonna log into a SecureAuth portal here. I’m gonna log in as my John Doe user, and this is my first time logging in and I’m gonna be presented with multi-factor authentication. I apologise for a little time out there. I’ll be presented with multi-factor authentication. One of the important things to note here is that I have a lot of choices that’s set up on my system. There’s a lot of different multi-factor authentication methods. This is part of the flexibility and part of the ways that you can help mitigate against attacks. By giving users a customised list of multi-factor authentications that work for your environment and for your specific users, you can start to eliminate some of these. So for example, if I’m worried about real-time phishing, I might remove all of the phone-based authentication methods, and when I say phone-based I mean over the SS7 or OTP-based authentication methods. I may just allow them to use maybe their phone app that is a bit more secure because it’s encrypted end-to-end.
0:32:30.6 JH: I may allow them only to use a token-based method because I control where those tokens come from and how they’re provisioned. So you have flexibility to apply these different pieces to it. For the sake of this demonstration, I’m gonna log in using my mobile app here and using our feature called symbol-to-accept. This relates directly to the attacks around notification fatigue of users just hitting accept. What this does is you’ll see this one on the screen here, and the user will actually be getting a notification that has multiple characters on their mobile app. They have to match up that characters of what they see on their phone with what’s being displayed on the screen, and once they’ve done that, it will then take them to the next step of their authentication process, which may be entering the password or maybe they don’t require a password for this specific integration.
0:33:20.6 JH: So with that, I’m gonna go ahead and enter in my password. I hope they can apply portal and I’ll have access to what I’ve been given here. So as part of this, when I logged in, all those things under the hood that Damon talked about are happening behind the scenes. We’re analysing and reporting that information, so some of the important information that came out of this was my geolocation, where I’m logging in from as a user. So if someone was abusing or phishing me during this process, one of the key points of any of the real-time phishing exercises is that real-time bit. They’re highly targeted attacks, meaning that the attacker is actively sourcing and looking for you. We also refer to these as spear phish attacks where it’s an individual and targeted type of behaviour.
0:34:06.1 JH: With that, the attacker has to be doing things in real time, because a lot of the one-time passcodes that are used expire after a certain period as well as the session. So with SecureAuth, you can customise your session duration so that if someone is using a phishing mechanism to try to bypass two-factor, you can limit the session so that the attacker has a very small window to actually get in. So, rather than having 10 minutes to go through the authentication process so the attacker can go back and forth to different screens and walk through that, you can limit it to one minute or maybe even 30 seconds for the user to walk through. Additionally, all the one-time passcodes are one-time use. So, if you get a text message with a one-time passcode, you can only use that once then and there if you navigate away or close the browser or open a new browser and try to access again, that one-time passcode is gone and is no longer valid.
0:35:00.5 JH: One of the biggest things that we see commonly over and over is that geolocation is usually thought of as a boundary system. We’re not gonna allow access from X, Y, and Z countries. Well, it’s equally just important to look at the difference of the delta between access. You guys may have multiple travelling employees who work from location to location, but you still wanna allow them to travel where they need to, but if there’s something really strange out there, like for example, if I was to bring up my Tor browser here, and I’m gonna use Tor in this context to purely come out of a different country or a different geolocation, so we’ll look here in Tor and we see that we’re coming out of Germany here.
0:35:41.8 JH: If I go to log in the exact same place that I was logging in before here with the exact same user, I’ve turned debugging onto the system so that we’re gonna get stopped, and we’re gonna get a message that tells me hey look, your current IP address is this one. Your previous IP address is this one. The current IP, it’s geolocation works out to being this location, and the previous IP looks at this location here. There’s a huge distance in mileage between the two locations, and it would’ve taken me 0.07 seconds to travel between those two locations or 81,000 miles per hour to get between those two locations. That’s physically impossible. Those are our improbable travel events. In fact, in the SS7 attack vector, there was a bank in Germany where this was leveraged against them, and the attackers were able to gain access to these bank accounts of these individual users because the text-based one-time passcodes were compromised through the SS7 vulnerability.
0:36:47.3 JH: If that bank had a geo-velocity feature enabled on their authentication, they would’ve stopped that attack in its tracks. Even though the one-time passcode was scraped or picked up and compromised, they would’ve seen that the geolocation varied drastically between the user’s last log in location and the attackers log in location. In this case, the attackers were coming out of Poland and some other Eastern European countries that they were using proxies to get through, but it wasn’t Germany where the users typically log in from. And in their post-breach analysis they were able to find out that these log in locations were drastically different from anywhere that these users typically logged in from. That’s all behaviour that we can look at again to start mitigating some of this risk.
0:37:35.0 JH: Now, you may be asking, well, what about malicious IP addresses? What about when a bad guy comes through and they are just pure out and out malicious? How is that different from Tor? How is that different from just being purely anonymous? There’s a great difference, a lot of products out there look for things like Tor, look for things like IPVanish or NordVPN, or all these different services that are designed to mask your internet traffic. However, that’s not necessarily malicious. There’s a number of journalistic entities, a number of government-based institutes that have to allow Tor and other browsers for users to leverage because that’s the only way they can get past certain restrictions in the country they’re connecting from. What’s more important is to look for things that are actually known malicious IP addresses. In this case here, I happen to have a known malicious IP address, this is a bit different than Tor, this is actually cyber criminal, true cyber crime that’s happening. This IP address has a reputation that we can see down here that my threat category description has labelled it as cyber crime, and the type description is actually compromised.
0:38:40.9 JH: What this relates to inside of our analytics, inside of our threat tooling is that, hey, this IP address is coming from a user who has been compromised. Usually in a command-and-control structure of some sort where they’ve been leveraged for other attacks in a botnet or something along those lines. But that’s the true value of the threat service is to be able to look for these type of targeted tasks, and we especially aggregate this list and curate it, so it’s based around identity type of attack. So, this specific IP address I’m using may have been used in a previous breach, maybe it has been used recently in a brute force attack against a number of sites. We curate this list to help reduce those attackers and make sure that they have more frustration and get blocked, such as I am being blocked here.
0:39:33.2 JH: The next and kind of last bit that I want to show you guys and walk you through is kind of a multi-part situation here. So, we talk a little bit about behaviour analytics, and that actually probably has the biggest ploy for stopping all of these attacks. This is fairly new to the market, especially for SecureAuth, it has evolved over the years. One of the primary things that we’re doing when we talk about behaviour analytics is, yes, it’s machine learning, yes, you may also know it as a UEBA, the user entity behaviour analytics, but ours is specially targeted based off the SecureAuth interaction and authentication data we have. It’s important to note that we have a ton of information in context and signal that are already built into our application, so that we already have rich data to make decisions off of when it comes to behaviour. So, whether that’s time of day log in or whether that’s log in frequency or maybe cell password frequency, we can analyse all that without having to train too deeply a baseline model. Of course, this will adjust over time with your users so that it becomes more natural to them, to their behaviour. So, if you have someone who works a strange shift, like a night shift, 6:00 PM to 6:00 AM or something along those lines, it will adjust and match their shift over time. So, they may be challenged for a little bit of multi-factor in the beginning, but over time it kind of regulates that and becomes even.
0:41:00.7 JH: So, with that, what I’m gonna do here is, I’m gonna log in once again as my John Doe user here, and I’m gonna purposely and intensely fail the password check multiple times. Sorry, apologize here’s a time out. And I’m just gonna put a couple of passwords in here and they’re gonna say, “Hey, this is wrong,” and then finally, I’m gonna put in my correct password, oh, maybe not. [chuckle] Oh man, going too fast. Alright, so I’ve actually hit the threshold and exceeded my password attempts. Now, this is interesting because this is actually a throttle base, but it’s not purely based on, “Hey, you’ve hit five attempts and you’re actually locked out.” This is actually a throttling system that will allow them to have free attempts after a certain period of time frees up. This allows the user if they’ve just fingered it to not be fully locked out, they could always go back in, they could try again in 30 minutes, they could contact the helpdesk or do other behaviour to allow them to get back into the system. So, now that I have failed these login attempts multiple times throughout the day, what’s my next step? If I go to log in, let’s say for example, I have now gone through helpdesk, I’ve gone through and I’ve reset my password, what’s the next part that I would do?
0:42:30.6 JH: Well, once I can get back and access into the system, and bear with me for one moment here as I do so, I have to go through and reset my password on the backend here so I can walk you through the next step here, but once I do that, SecureAuth now sees from a behaviour aspect that, “Hey, you’ve had multiple failed passwords recently.” So, from a behaviour-wise, we may allow the user to come back into the portal, right? So, as I go through this here, let me just come through on the backend here, I’m gonna reset my password here, give me one moment to do so, make it something that I can remember so that I don’t have a mistake with it again, and let’s do that and… Okay, so as a user I’ll come back in here as John Doe. Again, it’s gonna let me back into the portal because I’ve just gone through and logged in at a different place here. I apologize, I’m still having trouble logging in, one second, guys. And there we go. So, I’ll come back in here as that user, I will put in my password. I apologize, I think I reset it to something that is just a little tricky for me, so give one second to… There we go, I was locked out on the backend, so I had to free myself up.
0:43:57.5 JH: Okay, we’ll see as a user that I’ve been logged in, now you may be wondering, well, why didn’t we put any friction in front of them there? Well, we wanna gain a little bit more information. You know, inherently them messing up their password a few times isn’t necessarily risky. On the backend, my risk score may have gone from a zero to a 13, maybe a 24, it’s a scale of zero to 100. It hasn’t yet hit my configured threshold to say that it’s risky. Now, typically, when I come into this portal, I go to account management first and I look at my profile, I’m gonna do something else though, that’s a little bit riskier for myself. I’m actually gonna click on Salesforce to get some client data, which is not part of my normal behaviour. And again, guys say, bear with me, this is a demonstration, it’s hard to replicate actual real world in it, so it is a little, you know, kind of set up for the sake of the demonstration, but I’ll click on Salesforce here, and we’re gonna see something a little bit different. I wasn’t dropped right into Salesforce. Well, why wasn’t I dropped right into Salesforce? Well, that’s because we’re looking at that context under the hood and we designated Salesforce to be an application that doesn’t exist inside of our SSO context, especially if there’s a risk found in that user.
0:45:04.4 JH: So, as me as a user, when I come to log in now, I’m gonna be challenged absolutely. For some multi-factor authentication because there has been risk found, my behaviour has been flagged, there’s also settings and policy in place that say, when I’m trying to access this application I have to meet this specific criteria. So, I’m brought to an MSA page. Well, this is a little bit different as well. This is our next feature that we wanted to talk about, which was the phone number porting fraud. Here you’ll see this notification that the end user gets that say, “Hey, some methods are currently unavailable.” And if we look at it here, I have two phone numbers listed, but one of them, I can’t select. The reason I can’t select it is that this number has been recently ported. So, what I have to do as an end user is, I have to go through the authentication process using something else, like say, for example, my iPhone app, right? Because the app hasn’t been ported, that’s actually done out of the data channel, it has nothing to do with the SIM, it actually has to do with the device itself, and then I’m able to come in here. And what users can optionally be given is a consent screen for their ported number.
0:46:15.9 JH: So, they’ll actually get a screen as they go through and authenticate that will say, “Hey, that reason why you weren’t able to access using this phone number here,” and they’ll show the phone number, “is because it’s changed carriers recently,” and the user gets a number of actions that they can do. They can approve that carrier change for that number, they can delete that number from the profile, or they can ignore the message from now and they’ll be obviously not able to use that multi-factor method the next time that they come in until they approve that number, that they’ve actually ported it. So, that allows us to look for that ported status change and still give the user a way to handle it, if they actually did port their phone number. The period of time here from porting is fairly generous, we look back quite a ways to see if the number has been ported, but usually most of the attackers of porting action will happen within the next 45 days or so.
0:47:10.1 JH: The problem is, is that once a number is ported that user stops getting all phone calls and text messages to that device. So, it’s something that most users will realize there’s something wrong within a 24-hour period, if not sooner. I know for myself, if I don’t get a text message within an hour or two, that’s a little suspicious. I’m usually getting some sort of notification from something, so that’s a little suspicious for me and I would start looking into it. Most users will realize when someone tries to call them and say, “Hey, I tried to call you and it went to some number and it had no voicemail. Did you get a new number?”, or something along those lines, they’ll start realizing it. So, it’s very much a targeted and pinpointed crime that the bad actor has to go after and have a small window to use the phone number porting from. But SecureAuth layers this in here to allow you to catch that and be able to block that user from using that method until they can verify that they’ve actually done the ported action themselves.
0:48:10.2 JH: Now, I’m not gonna go through anything with knowledge-based, I think most people on this call here probably realize that knowledge-based is fairly weak, but I did wanna talk about it a little bit, to just kind of reiterate some points that Damon made. A lot of our customers do come to us and say, “Hey, you guys support knowledge-based, but do you support pulling knowledge-based questions from different services?”. There’s a number of services out there that have that, you know, did you live at this previous address? So on and so forth. Unfortunately, even those services, that data is out there. For example, there’s a very large one that many of you are probably familiar with that uses credit information to figure out what your previous employer was, what your previous addresses were and things along those lines. That was recently compromised, if we all remember last year, where that information is now out there on the dark web. So, even outside of what Damon hit on, which was just being able to Google and go to social media, a lot of this information about previous addresses, where you live, previous employers is actually available really cheaply on the dark web. I could buy in bulk multiple profiles of users for probably a couple cents for each user, depending on how valid the data is.
0:49:31.0 JH: So, knowledge-based, we steer a lot of customers away from, but if you do have to use it, and there are… Let’s be honest, there are some cases where you have to use it, maybe it’s for your consumers who you don’t feel will they be able to adopt to SMS or something along those lines, it may still be useful in that case, and we can still use it as long as we’re using all the adaptive authentication features with it. So, if I’m a bad actor and I’ve bought your profile and I’m trying to log into your bank account that’s protected with knowledge-based, again, like Damon said earlier, I’m probably coming from an unknown device, a brand-new geolocation, maybe my behaviour is a bit different from how I typically log in. I may not have the same two-factor methods available, I’m maybe trying to use SIM card swap fraud or maybe notification fatigue to get into your account, all these things are layers that we can look at.
0:50:22.5 JH: And the layers don’t stop with SecureAuth. I think it’s also important to point out that we’re not the only story in this, there’s things like MDM or CASB or PAM Solutions that can be layered on to work with SecureAuth to strengthen this as well. Maybe requiring only managed devices can be used and use the SecureAuth app for authentication, or maybe saying that all authentication requests to this specific site has to process and be done through the CASB, the Cloud Access Security Broker. And we would look for any anomalous IPs to help cut down on phishing or maybe integrating with the PAM can tell us that it’s a privileged or sensitive account and that it should be treated with a higher level of security than a standard user account. Again, it’s a layers game. It’s adding all these different pieces into the mix so that we can have a comprehensive story and really make sure that none of these attacks that Damon has laid out could actually affect you and your organization. And with that, Damon, I’ll toss it back over to you.
0:51:23.9 DT: Well, thank you, Jeff. And so, before we open for questions, I just wanna remind everyone that a recording of today’s webinar will be sent later today. In the meantime, if you want the slides or an infographic, go to attachments and links and you can download it right now. And they both… You know, the infographic tells a very similar story to the slide, maybe does it in a more condensed form. So, with that, I mean that kind of concludes today’s webinar presentation. Thank you for staying till the end. We’ll now open the lines for questions. Again, I encourage you, if you have questions, put them in that Q&A panel on the right-hand side and we’ll address those. So, Jeff, I have one here. I have remote users that have reasons to be on VPN sometimes and not on others, but still need to access protected services. How can I get around unintentionally blocking my own users with the geo-velocity feature?
0:52:29.6 JH: Great question. So, we support the ability to whitelist specific IP addresses such as your VPN endpoint. So, if your users are hopping on and off VPNs that you control, you can whitelist whatever the public IP address that they would be coming out of, so that we wouldn’t be looking at that from a geo-velocity standpoint. We would know that that’s an approved location a user can come out of, and so that we wouldn’t take that into account from an access history standpoint.
0:52:58.1 DT: Awesome. Another question, this is primarily focused on 2FA via text versus say, Google Authenticator or other apps on a smartphone device. Are those app-based 2FA MSA models being successfully exploited as well? And I can say, you know Jeff, when I was doing my research for this presentation, I did not run into any examples of that, but I would imagine if you can SIM swap a phone, you can go download Google Authenticator and you probably have the credentials, can probably set it up.
0:53:35.6 JH: Actually, a little bit different on that one. So, fortunately the question, I think the asker of the question knows the differences here between smart phone apps and the SS7 network. The app itself actually works over an APN exchange, it’s actually a completely separate data channel. So fortunately, that data channel is a lot more secure than the SS7 network and hasn’t been compromised at this point in time. And the credentials for that application, such as the auth seeds that get registered in Google Authenticate or other push notification tokens that get registered in our own app, those are only local to the device. Typically they’re stored in the Secure Enclave or TPM or similar types of technology, and they’re not on the SIM card, so even if you swap the SIM card, it won’t move from device to device. That’s why you notice a lot of those apps have those recovery codes, that if you move from a device device you have to put that in. And so with that being there, there has been some talk about malware being able to abuse those applications.
0:54:43.5 JH: Fortunately, we haven’t seen one in a while. But, the one-time passcode generation, the auth safe, which most… Google Authenticator is built on, AuthSeed, SecureAuth, Microsoft, all of us that auth standard, AUTH. That’s a time-based code or an HOTP, sometimes it’s event-driven as well. That code lives anywhere from 30-60 seconds in length. Using a real phish or some sort of reverse-proxy phishing mechanism, that could still be captured and used to get session and control. So it’s not impervious, just because you’re using a app to say that “I’m protected from all these bypass methods”, but I would say you’re a lot more protected than just using SMS with no layers or features therein.
0:55:31.7 DT: Cool, thanks Jeff. We’ve got another question, I think I can probably take this one, the product seems similar to WS OTYS, Okta, App GEE. What’s your claim to fame? And Jeff, you can try and add with anything after I kinda get through it, but I’d say, based on things we’ve talked about today, our claim to fame is doing those adaptive authentication risk checks. And we do more of them than anyone else, so for example, Okta doesn’t do behavior analysis via machine learning, they don’t do any blocking around the phone. I’m trying to remember, I know there’s a couple of other things that they don’t look at either. So they look at device, they look at the IP address, if it’s on a wider blacklist, they don’t have a threat service that they take your IP and brush it up against to see if there’s an issue. And I’d say, I don’t know much about the other two companies outside of Okta. I’d say our claim to fame is that we offer two-factor authentication, adaptive authentication, which we talked about a lot today, but we also offer a single sign-on, we support every major Federation protocol, and we have a lot of user self-service tools, so whether it’s password resets or account unlocking, or it’s registering your phone into the multi-factor authentication platform. The idea here is to remove administrative steps and helpdesk steps as well. Jeff, is there anything else you wanna add to…
0:57:01.1 JH: Yeah, I would just say that if you’re speaking to one of the other vendors, just ask them to show you and walk you through those pieces and to show you exactly how they work. We’d be more than happy to do that with you, to walk you through it and actually show you how each of those pieces work in your environment. The other piece is that, while some of these other vendors do have these pieces and some of these features, a lot of time it’s delivered from a third party. There’s additional licensing and cost you have to incur to get that feature. So for example, with Okta, if you wanted to leverage a threat service for their feature, you have to go and license that threat service while we provide one out of the box. Or if you want to use behavioral analytics, you have to go and license the behavioral analytics profile, while we provide some of that functionality out of the box. So it’s more about being a comprehensive out-of-the-box solution, where you can still add maybe some existing investments that you have, but you’re instantly in a higher category of security than you would be if you just bought something else off the shelf. We can provide a lot more of that functionality from kind of a day-one viability without having to ramp up a bunch of other services.
0:58:12.2 DT: Okay, so we got two more quick questions. Can we whitelist IPs by country?
0:58:18.5 JH: Yes. Yeah.
0:58:20.7 DT: And we integrate with SAP systems?
0:58:25.0 JH: Yes, depending. SAP has a number of different modules, but if it’s a net weaver SAP interface, we can leverage SAML, because that’s default for them out of the box. So that would be a question that we could actually follow up with you on and talk about your specific environment, but we have a number of customers who are leveraging SecureAuth with SAP today.
0:58:48.4 DT: Awesome. Well, I think that’s it for questions. We are literally hitting the last minute. I wanna thank you all for your time. Jeff, thank you for your time, and I hope you have a great rest of your week. Thank you very much.