July 21, 2021


By the time you think of a ‘new’ password, attackers already have a way to crack it. Josh Amishav-Zlatin, Founder & Technical Director at BreachSense, is here to reveal the ugly truth about passwords, the risks they present, and how you can mitigate those risks.

What we talked about:

  • Breach timelines and scales of impact
  • How breaches work and how they’re identified
  • Is 2FA/MFA enough to protect you?
  • Protection vs. the right to privacy

Check out these resources we mentioned during the podcast:

To hear this episode, and many more like it, you can subscribe to The Virtual CISO Podcast here.

If you don’t use Apple Podcasts, you can find all our episodes here.

Time-Stamped Transcript
This transcript was generated primarily by an automated voice recognition tool. Although the accuracy of the tool is 99% effective you may find some small discrepancies between the written content and the native audio file.

Speaker 1 (00:06):

You’re listening to The Virtual CISO podcast, a frank discussion providing the best information security advice and insights for security, IT and business leaders. If you’re looking for no BS answers to your biggest security questions or simply want to stay informed and proactive, welcome to the show.

John Verry (00:24):

Josh, good morning. Well, actually, I guess for you, it’s good evening. For me, it’s good evening. How are you today?

Josh Amishav (00:28):

Oh, good afternoon. But yeah, all good. How are you?

John Verry (00:32):

I am good. I think you win the award for visiting from the farthest away onto the podcast, so congratulations. Stay by your mailbox, you’ll see something really special, I’m sure.

Josh Amishav (00:42):

Thanks for having me on.

John Verry (00:43):

Yeah. So, let’s start super easy. Tell us a little bit about who you are and what is it that you do every day.

Josh Amishav (00:49):

All right. I’m Josh Amishav. I’m the founder of Breachsense. We’re essentially a data breach monitoring platform. So as you probably seen the news all the time, there’s data breaches. What we do is we help security companies gain visibility into their employees, their customers, and third-party providers of data breaches, so that they can reset passwords before criminals exploit them to gain access to the network.

John Verry (01:15):

Gotcha. Before we get down to business, we have a tradition. We like to know what’s your drink of choice?

Josh Amishav (01:21):

My drink of choice, probably not what you’re after, but seltzer. So yeah, I don’t drink very much alcohol.

John Verry (01:28):

Slow down, Josh.

Josh Amishav (01:29):

Yeah. Yeah. No, I am not into alcohol, so-

John Verry (01:35):

Gotcha. Yeah. What about coffee?

Josh Amishav (01:38):

Yeah. No, not into coffee either. So yeah, I like only cold drinks.

John Verry (01:43):

Are you a man of no vices?

Josh Amishav (01:45):

I’m pretty into mountain biking. So that’s where if I have free time, I’ll do that, but not too much into food or drink.

John Verry (01:54):

Now, you’re in Israel, correct?

Josh Amishav (01:56):

Yeah. Yeah. Based out of Israel, so we got great mountain biking around here.

John Verry (02:00):

I was just going to ask, so I used to do a decent amount of mountain biking when I was a little bit younger and we’ve got some amazing places. Right where I am in Jersey is decent. And then out West, you have some beautiful stuff. What’s the train like in Israel? Is it up and down a lot? I mean, do you have traditional trail riding like we do here in the U.S.?

Josh Amishav (02:19):

I guess we have a mix. We have it because it’s just a small country. There’s a trail that goes across the country from the north to the south, so you can see a bit of everything. So, we’ve got mountains. We have plains. We’ve got valleys. I mostly ride in a pretty mountainous area, so it’s a lot of climbs. So we’ll have easily, let’s say, on a two-hour ride, we can get to close to a thousand meters elevation. I’m not sure what that is in feet. But yeah, there’s a lot of climbing in the singles and ups and downs and a lot of fun.

John Verry (02:53):

Yeah, that’s more than a half a mile. It was probably around 3,000 feet or something of that nature, which is pretty significant. That’ll get your endurance up quite a bit.

Josh Amishav (03:03):

Yeah. Yeah. It gets your heart racing.

John Verry (03:05):

Exactly. Now, I just have to ask, I’m assuming if you’re doing that much off trail, you’re fully suspended. What type of bike? Is it a Cannondale or-

Josh Amishav (03:13):

Marin full suspension, so track trail.

John Verry (03:16):

Nice. Nice. Excellent. Well, let’s get down to business. Let’s talk about what you do first, and then let’s talk about in what the value prop is of the data that you provide. And then let’s, after that, talk about how we can prevent someone from ever finding out from you what’s going on. So, let’s talk about exactly how does a service like Breachsense work.

Josh Amishav (03:40):

Okay. If you’re familiar with Have I Been Pwned, which a Troy Hunt runs a great service that essentially people can upload their email address and then they’ll get alerts when they appear on a breach. Have I Been Pwned focus on anytime their email address and certain circumstances, their phone number appear on a breach, they’ll get an alert. I’d say the primary difference, Breachsense is more focused on the enterprise level. So, what we do is we allow security teams… Instead of having you only gaining visibility to your own email address, you can do it domain-wide, and then you can do it as well, for you can look up for your clients or for providers that may have access to your network as well.

Josh Amishav (04:21):

And then the other important bit is that we will crack the passwords. So really depending on the password type, but the goal is to have as many plain text passwords as possible. What that does is it enables the security team then to gauge the actual risk to the organization, because you can take a plain text password, and depending what applications we have, you can hash it back into your NTLM or into… If you’re running, let’s say, Shot 256, you can hash it back and then compare it to what it is. And then you can say, “Okay. This password does exist within our organization. We need to force the password update,” or it doesn’t and then there’s no risk to the organization.

Josh Amishav (04:57):

So if we’re using like other services where you don’t have that option, you’ll know that there’s been a breach, but you don’t know if the user will use the same password. In which case, if you’ve got a large enough organization, it’s not always feasible to force password updates for hundreds or thousands of users. So we prevent that and we enable the team to say, “Okay. This is the actual risk,” and then we make a decision based on that.

John Verry (05:21):

Gotcha. And then Have I Been Pwned, Troy does a great job and especially because he does it as a free service, which is amazing, but one of the things which is challenging about using that is that it often just tells you about a breach and it’ll tell you about the ones that have just your information, as well as the ones that have your information and a password. So that’s one thing is that, do you also provide information about just contextual information being released?

Josh Amishav (05:46):

So yeah, we’re laser-focused just on passwords. So if you have credit card information or your address, that’s less… From our standpoint, a lot of that information is probably publicly available. So the fact that your email address was breached, it’s not really a big deal when we don’t want to… We want to have a very high signal-to-noise ratio so we want to make sure that… Or is it a low signal-to-noise ratio? We want to make sure-

John Verry (06:12):

No, it’s high signal-to-noise.

Josh Amishav (06:13):

High? Okay. Yeah. Anyway, we want to have… Anytime you get an alert, that there’s something actionable that you can do and there’s actual risk associated with that. So, that’s where we’re focused on. In order to be imported into Breachsense, there needs to be a password within the breach.

John Verry (06:31):

Gotcha. Actually, I think that makes a lot of sense, especially in a corporate setting, because at that point, really what you want is information that is actionable and/or requires action, and what you’ve done is, like you said, increase signal, reduced noise. The other thing with Have I Been Pwned is that every time you go there you get all of the old information. I’m assuming one of the benefits of working with something like Breachsense is you can actually probably say what’s happened recently, so that way, you can filter that data and if you’ve already acted on the… Because I keep hearing about the 2012 LinkedIn breach, that password has been changed seven years ago or 10 years ago, whatever the number is, right?

Josh Amishav (07:06):

Yeah, we definitely hope so. Yeah. So Breachsense, we have a number of different filters you can have. So essentially, we’re just an API. And then you can set up alerts, so you can set up various filters to get information. One of those filters is a date filter. You can say, “Just show me breaches associated with a given domain name or an email address that were imported into database from or after a certain date.” You can run it, let’s say, through some sort of plan job and just see alerts if you’re importing the data, let’s say, within a SIM or some other product. You can just see alerts that are basically new. That way, if you’re using the data to alert either your clients if you’re an MSP or just your organization that you know that this is new data. Just within breaches of those, the timeline is sometimes interesting. A breach will happen, right? And then it will be traded on various dark web forms for a period of time and then it will become publicly available, right?

Josh Amishav (08:03):

One of the questions that we often get is when we put a date on a breach, is that date the date that the breach happened? Is it when it was imported? Or where exactly is that? And then what we try to do is we’ll say, “When we know when the breach happened, you don’t always know.” So, we usually tied down to a month because it’s very hard, especially for more historic breaches site down to a specific day. Sometimes you can’t even get that. But normally, you can get a month and then we’ll say, and the date that it was imported. So there are instances where we’ll have data. Right now, we’re in the middle of reporting a breach today that the breach actually happened in 2019. It just became publicly available today. So I guess be aware when you’re alerting users, you could be alerting on new data that was just become public available, but the password was used two years ago, which may or may not be used, in which case that’s why it’s really important to have the plain text password as well.

John Verry (08:57):

Gotcha. One thing we should be aware of is we definitely have a bad connection. It’s a good thing we’re recording separately today because there’s definitely a delay, so I apologize. I’ll try and make a effort to wait until you complete speaking and then talk, because I think we’re stepping on each other a little bit. Sorry about that.

Josh Amishav (09:15):

Oh, no worries. All right. Now, I think I interrupted you actually, I think. But all right, go ahead. Hopefully, we can edit this part up.

John Verry (09:20):

Yeah. No, we don’t edit anything out if we don’t have to. See, it sounds real natural.

Josh Amishav (09:24):

Oh, you don’t edit anything? All right.

John Verry (09:28):

For the record, Josh has his own podcast, which is quite good. I’m drawing a blank on the name. I know it’s on my phone. What’s the name of your podcast again, Josh?

Josh Amishav (09:35):

Yeah, The InfoSec & OSINT Show.

John Verry (09:37):

Yeah.

Josh Amishav (09:38):

Yeah. The InfoSec & OSINT Show, we try to bring on people within bug bounties, pen testing, anything related to the InfoSec or AppSec world, and then try to gain actionable or learn some actionable tips based on their expertise.

John Verry (09:55):

Right. So, he’s a professional, I’m not, so that’s why he wants me to clean this stuff up, but it’s my podcast, Josh.

Josh Amishav (10:03):

All good.

John Verry (10:05):

So, a user of your solution tends to… It sounds like they’re using their domain name, right? So in my case, mine is [email protected]. So I would run a search on that and I would find out if that password has been disclosed. That’s typically going to be, if I’m using that password at a cloud service, it’s probably software-as-a-service provider in most cases, correct?

Josh Amishav (10:26):

There’s a Google study a couple of years ago. I’m trying to remember when it was. But anyway, they came out with… It was 65% of users use the same password across most, if not all of their other applications. So, the idea is that for any organization, you’ll have a percentage of users that are using the same password within their personal cloud solution web apps that they’re using, as well as their business applications, right? So you’ve got password, where you use across multiple applications. If one of those third-party applications became breached and a password became public, then attackers will grab those and what happened is they do what’s called a credential stuffing attack. So, they’ll just have long lists of email names and passwords. Normally, it start with a Gmail or Twitter, LinkedIn, whatever, to see where those passwords are enabled and then start pivoting from there.

Josh Amishav (11:18):

I’d say one of the reasons why Gmail would be one of the primary target is a lot of other password recovery emails get sent to there. So if you can take over the primary email account, you’ll have access to all these other accounts. Even if they use a different password, they can just reset the password, gain access, and then start moving laterally from there.

John Verry (11:37):

Yeah. So, that would be an interesting argument to whether or not there’d be value to a corporate. I don’t know that they can do this because it might be an invasion of privacy, if you will, but there’d be value, I would think, if you could monitor my personal email accounts, my personal email with all of the accounts that I use that with, because like you said, people have a tendency to reuse passwords. So on my personal account, I might be using a Pedro@12345, right? And I might be using that same password at work. Is that a thought process? Do organizations look for that yet, or do you think that’s something that’s probably not feasible or practical to do because it’s sort of an invasion of privacy?

Josh Amishav (12:20):

For larger organization size, it’s probably not practical to do. I think you could do it on a limited scale. We have some clients do that on a limited scale for their C-level executives, but I think there’d be definite privacy issues doing it that way. What you could do on the flip side is you could do a password lookup if you’re able to detect password. Again, you’d have to make sure it’s in plain text and then do a reverse look and say, “Show me all the accounts, with their superiors,” to see if that’d be relevant.

John Verry (12:47):

That’s an interesting idea. I mean, I guess the question would be is the problem with that is that if you look at those 25 most common passwords every year… I mean, how many people are using dragon and let me in and abracadabra and the ones you typically see on the list. So I guess if somebody had a unique password, then it would be more likely that if you ran that against the large list and you might see the compromise of a personal account associated with the same password.

Josh Amishav (13:11):

Exactly. Yeah. It’s going to be limited. That was why I suggested you may want to limit the scope both in terms of who you’re monitoring and also the lookups. Looking up something a password123 obviously is not going to be scalable, but if it is a unique password, then you may have more luck in that.

John Verry (13:29):

I guess the other use case that I would think of that I think would be a good idea would be administrative level privilege. Anyone that’s got admin level privileges in addition to your C-suite might be something that someone would consider. I think even the admin level people, anyone that’s in IT and IS, I don’t think would be offended by that. I think they get it.

Josh Amishav (13:48):

Yeah. I imagine a number of them are probably using other services to monitor their domains as well, or their email address as well. There’s a lot of overlap. And then I see their each data breach database service has unique databases that they have access to that others don’t. So very often, companies will use multiple services to get even a wider scope just because not everybody has every breach. One of the things a lot of breaches will pop up will be available for a certain amount of time and then disappear. So if you don’t grab it at the right time, then you may not ever have access again. So it was why each service has… I mean, there’s, I’d say, probably 80%, 90% overlap, and then there’s ones where they’re just unique to that service.

John Verry (14:35):

Gotcha. And then just to make sure that folks were clear on the… Let’s do it this way, I’ll let you do it. Give me a scenario where somebody’s password that’s associated with their business email address is compromised, and give me a worst case scenario of what the malicious individual would do with that password and what that might result in.

Josh Amishav (14:58):

I think probably the best example, most recent example would be the Colonial Pipeline attack that recently happened. The Colonial, basically they had to stop billing for the gas that was going through the pipeline. There were ransomwared, but that entire attack started because of a single breach password. So, there was a employee that used the same password on another site that was compromised. Attackers grabbed that, ran a credential stuffing attack that we discussed before, got access, I think, via VPN. And then once they had access, that user had privileges. They were able to ransomware that account and then moved around within the organization around to infect other machines. That’s probably a good enough example for the worst case scenarios as any.

John Verry (15:47):

Okay. So in that particular case, perhaps MFA would have protected them?

Josh Amishav (15:52):

It really depends if the MFA is implemented. This is an example that was relevant a couple of years ago, but there are applications that support harbor token MFA, which is generally thought to be significantly more secure than software-based MFA, but the application allows you to log in through a iPad as well. iPads don’t have USB ports, and they obviously can support a security token. In which case, if you logged into the application via an iPad, you were able to bypass the MFA requirement, and then you were able to gain access, and you’d be able to… If you had breached credentials, they’ll be able to get access. So that’s one example which is something you have to be aware.

John Verry (16:38):

Yeah. I mean, why go to all that effort and then leave an iPad or a door open like that? It’s like, “Look, let’s put giant locks on all the doors, but the basement door, the cat might need to go in and out, let’s leave that one unlocked.” I mean, that makes almost no sense that they left an iPad back door.

Josh Amishav (16:56):

Yeah. Yeah. I mean, it happens. So, like I say, MFA is a great solution and it should be enabled wherever you can, but I’ve bypass personally, as a pen tester, MFA on numerous occasion using phishing attacks. So, we’d set up like a fake login, send the phishing email to the employees in the organization. And then as long as you did it in real time, we’d have 30 seconds or 60 seconds, however long the MFA token timed out, that the user would put that in. We just grab it and put it in our end, and then we’d be able to bypass it that way. So MFA is great, but it doesn’t give you complete protection. So, you just got to be aware of its limitations.

John Verry (17:36):

Gotcha. The attack that you were just referring to, the MFA, the second token was being sent by an email?

Josh Amishav (17:43):

No, no. The MFA was via HTTP, but there were submitting it via our fake websites. We had access to all the… That we had access to the HTTP request, and then we were able to then grab it and put it in. It wasn’t like a frame that bypassed us. We had access to it.

John Verry (18:03):

I got you. Essentially, you man in the middle of the communication. Very interesting. Okay. So fundamentally, the idea behind your service is that you’re limiting the exposure. If a password is disclosed that’s associated with a corporate email account, you’re going to limit that organization’s exposure by giving them near-immediate notification of that happening, which gives their team time to not only protect the infrastructure it protects, where it’s a directory structure, let’s say active directory, right? They can look to see if the password is currently being used, or they could just force a password reset at that point, if they wanted to. And then they can also work with the individual to make sure if they’re using that same password on other cloud assets, other cloud-related sites, to make sure that they changed them there as well, correct?

Josh Amishav (18:51):

Exactly. Yeah. So the way this all started was… Like I mentioned, I was a pen tester for many years. What I found was that I would run an engagement against a target, and many of these targets were large financial institution banks, insurance companies, and government applications. The first time around you’d find SQL injection crosses. You just find some interesting findings. And then the second or third year, they fixed all the high risk issues up and then we would still need a way to create an interesting report. The way that we’re able to do that was by still gaining access just by using weak credentials. One of the things we found is most organizations don’t have any visibility into this. It’s one of those things where if you don’t stay on top of it consistently, you’ll going to lose visibility into some point breaches that affect your organization.

Josh Amishav (19:40):

So after I left that world, I said, “Okay. Let me create essentially a database that enables other security teams to be able to maintain visibility into the ongoing breaches and their daily, weekly… It happens just all the time and that way… And set us up as API, so that way, you can automate both the lookups.” If you’re doing offensive security, you can just grab the data. If you’re doing as passive, you can just create alerts and import those alerts within whatever some solution you have to be able to manage the alerts that way.

John Verry (20:16):

Gotcha. Yeah. I mean, the idea that somebody is using the same password with Box or Dropbox that they are with their corporate email is highly likely, right? I mean, the amount of exposure that you might have could be significant, especially because you may be having different password refresh rates on different assets. So as an example, active directory, you might look at your active directory and say “Oh, no, that password’s done,” but that password might still be in use on Box or Dropbox or Salesforce or some other tool, which maybe you’re not forcing password changes quite as often.

Josh Amishav (20:53):

Okay. So yes, that’s a great point you bring up. So first of all, this no longer recommends rotating passwords. The reason why they don’t-

John Verry (21:02):

Yeah, I know. 863(b), baby.

Josh Amishav (21:07):

All right. Yeah, so the reason-

John Verry (21:08):

I told you we’re stepping on each other.

Josh Amishav (21:10):

All right. No, this is great. So, you’re obviously aware of the reason why that’s no longer effective. Just using the scenario that you brought up, you have a active directory password that’s probably something along the lines of password one because they had an updated six months ago and they added a one to the end and they have an uppercase letter in the first letter, and in the Dropbox, they didn’t have that so it’s still just password. But even if it’s significantly more complicated than that, normally it doesn’t really matter. The reason I say that is that when we grab a password, we run it through hashcat rules that will take a base word or base phrase and then will run various rules onto that, like capitalizing the first letter, capitalizing the last letter, adding a number, incrementing a number, adding special characters in the first, last positions, or various positions depending on the rules, but we’ve automated the brute forcing so much the fact that most rules, where they’re complexity rules, so we have to have an uppercase or lowercase, special character and a number don’t add sufficient complexity to the password.

Josh Amishav (22:19):

So if you still have an eight-character password, with those special characters and the upper case, lower case, we’re still going to be able to crack that password, especially when we have the hash. But once we have it at one place, then we can apply the rules to say, “Okay. Well, we know the same password in Dropbox doesn’t work within your network, but we can start generating these rules to create a variations of that password and try that.” We’ll probably get it, because when you force password updates, people just increment the last number or increment a number in the beginning, but there’s the amount of variations that people have to the passwords when you force password updates are very small, and we can only predict those.

John Verry (22:59):

Yeah. I saw some analysis recently that said if your password policy requires a capital letter and if it requires a number and if it requires a special character, that in 78% of the times, its uppercase is the first letter. It’s a word. The number comes after the word, or they use elite substitution style pattern. And then the special character is almost always the last character. So like you said, I mean, you could mix it up a little bit, right? I use that example before Pedro@1234, and maybe that was because somebody required a 10-character password. If somebody required me with that same password, if I capitalize the P and I put an exclamation point or question mark, it’s not going to take a password… It’s going to take a password cracker milliseconds to try a thousand permutations, right?

John Verry (23:54):

I mean, you and I have talked about this prior. We have a password cracking rig in the office. I think it’s got five FPGA. I forget the name of the cards that we use radio on someone and others. The numbers are staggering, right? On our rig and you probably have a better one, we can guess every eight-character password. We can brute force every combination of eight characters in 12 hours.

Josh Amishav (24:14):

That’s long, but yes. Yeah. So basically-

John Verry (24:18):

Yeah. You do it for a living. Yeah.

Josh Amishav (24:22):

Yeah, that was because you have a lot of patience.

John Verry (24:23):

How long does it take you to go through eight characters?

Josh Amishav (24:25):

Yeah. It’s basically, I mean, password policies should be updated to reflect reality. They’re very often not in which case from the offensive point of view, we can normally take advantage of that, especially we’ve got visibility into the target’s passwords and other platforms. We can then just take that as the base and then play with it till we get one that works.

John Verry (24:52):

So, I think you could say that you were a NIST-recommended product, right? Because if you think about what NIST said in 863(b) is forget complexity, right? If you want to make them complex, go ahead, but you’ll be better off… Make sure they’re long and strong, right? So the longer you are, the better off you are, right? So let’s say, I would say right now, if I were counseling someone, ideally 12 characters or greater right would be what I would say that you’d want to get to. You should not force password changes every 90 days or 180 days. You should force password changes at a much slower cycle, if at all. And then it should be based on using a monitoring service like yours, that if a password was compromised, then you would move to changing it, correct?

Josh Amishav (25:32):

Yeah, exactly. You should. Yeah. Also, obviously, enable MFA where possible. Yeah. Rotating passwords doesn’t really help complexity. Exactly like you said, complexity doesn’t help. When a user creates a password, you should look up that password within the service to make sure that that password has not been compromised. But even with that, you’re going to have limited… I mean, if you have an exact match, it’s obviously a problem. The flip side of that is if you’ve got the base word within that, then your hashcat rules can in any case get to that, even though we don’t have visibility into that exact match at the moment. I don’t know if that makes sense. But basically, looking up as NIST recommends it, and that will tell you if there’s an exact match. My point is even if there’s not an exact match, that password still may hit. Depending on who’s trying to crack it and the type of rules they’re running on it, there may still be limitations to that. So MFA should always be enabled in order to give you the extra protection where possible.

Josh Amishav (26:38):

The other thing just with length, one of the things that we mentioned before is length is important, I guess, when you’re creating the password. Once the breach happens, cracking the password, that hash type that you’re using is going to be very important. So even if you’ve got a 15-character long string, but you used MD5 of the hashing algorithm, that will still be able to crack pretty easily because you use MD5. So you want to be using things like Argon2id or bcrypt. That will make it significantly harder to crack the passwords if the hashes became public.

John Verry (27:11):

That was something that you surprised me with when you said it the last time we chatted, is that I hadn’t thought that through, which makes me feel stupid because I’m thinking to myself, “Hey, I use 16-character passwords everywhere. I’m safe, but maybe not.” Maybe that’s something people should be adding to when they’re evaluating a SaaS service and you’re looking at your requirements. One of the things and one of the questions would be is what type of a hashing algorithm are you using? It’s not a question I think most people would ask, but as you just alluded to, it’s a very important question to ask.

Josh Amishav (27:37):

Definitely. Depending on the type of service, you may or may not be able to get that information, but from what we see the hashing type defines how easily we are able to crack the password, if it’s going to take months or years or if it’s going to take minutes.

John Verry (27:51):

Question for you, you mentioned that a NIST recommendation is to look up a password to see if it’s been compromised before you allow it to be used. I’m assuming that’s a service that you provide via API.

Josh Amishav (28:02):

Yeah, exactly. You can do that by API. You can hook into your creation functionality, just create the API, see if it’s there. If it is, great. If not, then you can let the user create the account.

John Verry (28:15):

Gotcha. You mentioned that there may be a pattern that they’re using that would make that easier to crack. Is that something that you can pick up in that API call as well or not yet?

Josh Amishav (28:26):

Not yet, and the reason is there’s… It’s one of those things where you can have an unlimited number of variations. So the question is you have to call it at some point and say, “Okay. We’re going to include the database X number of variations on this password. If it matches that, then we’re going to include it.” On the other hand, you can have… Say, if we did it based on it, one of the things that we normally do when we crack is we try to monitor the rules, the hashcat rules that show up most often, right? So what we can do is we can take the top 10 rules and create password variations on that, and then it gives you more insight as opposed to we weren’t doing anything. On the other hand, what happens if the password that the user is submitting we would find on the 12th rule that we would run if we were cracking a password, but we don’t include that in the database.

John Verry (29:17):

Right. You know how on a website you got those little yellow, red, green light to give a sense of password strength? Maybe just some indicator where it’s a scale of zero or a hundred and then a company could, based on their information security requirements, specify. So you just give a number when it comes back, right? Hey, zero is, “We found it.” A hundred is, “Wow, that’s probably incredibly hard to break.” They can set a level of about 50, right? If somebody’s password is in 50, they can come back and say, “Please try another password.” I mean, I understand the complexity of going go no-go, but there is a range, right? I think we could probably ascribe a number to a range.

Josh Amishav (30:02):

Yeah. Yeah. No, definitely, that could work. One of the things that when you mentioned that, I was thinking a lot of password… On the websites, when they do the password complexity and you put in a password like Password1! with the capital P, right? You get, “This is very secured,” but it’s obviously not. I found implementing the logic for those rules could be problematic. If you use the range, like you suggested, that could help take care of that. Meaning, you’re not going to say something silly, like Password1! is really secure when it’s not. If you use the range, maybe you can fudge that. Well, we know that the base word in this password or the base string has been found, and then it would require X amount of complexity to be able to crack that afterwards. So yeah, that could work.

John Verry (30:47):

Right. Yeah. So dragon, very likely fire or breath or some other combination would be with that, that would be one that would be lower on the scale. That’d be a 10 or something of that nature. But if it was dragon with six random characters that have no correlation with each other, that might be a 35 on the scale or whatever it is. So, cool stuff. All right. So I think we now understand why there’s value, significant value to the service that you offer. How does somebody prevent… I think we’ve started already talking about that, but what would be your guidance if I said, “Hey, how do I ensure that I don’t end up on one of your reports”?

Josh Amishav (31:25):

It’s probably impossible today not to be in a data breach. I mean, it’s completely out of your control, because you’re signing up for services. You’re on the internet. Just like I mentioned before, you can control your own network. You can put in the greatest web application firewalls and IDSS. You can have all that, but you don’t control other people’s networks and breaches happen all the time. So obviously, don’t use passwords, enable MFA. There’s not much more you can do, and then just stay… You want to have some sort of visibility into the data breaches so that you know when either you or one of your employees or somebody else who’s going to open up your organization to risk, where it appears in one of these breaches that you can then change the password before it affects you. There’s no hermetic way to… I mean, maybe if you don’t use the internet. So, I think my grandparents probably aren’t on any breaches, but anybody… Yeah. Otherwise, you’re limited to what you can do. Just visibility, I think is the name of the game.

John Verry (32:27):

Gotcha. So, how long are your personal passwords? You don’t have to give me an exact number, but-

Josh Amishav (32:32):

So, are you familiar with the OWASP ASVS, the Application Security Verification Standard?

John Verry (32:37):

Oh, yeah. Yeah. We use it every day. All of our testing that was aligned with ASVS, we think it’s brilliant.

Josh Amishav (32:41):

Yeah, that’s great. So they recommended at a minimum of 12 characters. So. I try to do 12 characters in MFA wherever I’m able to. I find passphrases tend to be better than just strings, but for some websites actually have a script that use open SSL to generate random strings and then use that. Otherwise, a lot of people use password managers depending on the password manager type. One of the things actually, I think we discussed this briefly beforehand, there may or may not be possible security implications with the password manager, right? So, what happens, the password managers use JavaScript to inject… They inject JavaScript into websites so that they enable you to be able to post the credentials within the website. So depending on how those are used, that sometimes can also open up the user to risk as well.

Josh Amishav (33:38):

So in general, there are number of ways you can manage your passwords. I’m a fan of KeePass XC, which the way they’re implementing the JavaScript calls could seize on the safer side the number of other services, and some of those services also generate passwords for you, answer your question, but there are other ways you can do it, like I mentioned, the other open SSL, just to create a random string or just generate random forwards and use that and just have a way to track that.

John Verry (34:08):

Right. But I think you’d agree, despite the fact that some of the password manager… If you pick a good password manager, yes, there is a small chance that somebody could use that against you, but I think the risk associated with not using a password manager these days… Because I don’t know about you, but I think an average user has 100-plus passwords. I have couple hundred passwords for the different systems that I’m involved in. I just don’t see any other way that you would be able to keep track of that without using easily rememberable passwords, right?

Josh Amishav (34:34):

For sure.

John Verry (34:35):

I mean, using a local Excel file is not a great idea. Yeah. Okay. I just want to make sure that people didn’t get the idea that you were saying don’t use a password manager.

Josh Amishav (34:42):

No, no, no, no. Okay. Let me rephrase that. Definitely use a password manager. If you are super nerdy, then you may want to use the VIM file, use open SSL, keep it local on your machine, not in the cloud. But for the 99.9% of the listeners who are not into that, then definitely use a password manager.

John Verry (35:02):

Yeah. Because at one point I did use a model like that, even then the problem I went away to a password manager was I work right now from five or six different computers on a regular basis, and the problem is is that how do you get that VIM file synchronized and to every location and you’re on your phone and you need to gain access to something? So, I think that the value of a password manager is that you have that visibility to it every place that you need it. I do think it’s a little bit of a compromise of security, but I think it’s the least flawed solution, I would say. I mean, they’re all flawed, right?

Josh Amishav (35:39):

Yes. No, completely agree. Completely agree. Yeah, completely agree. Everyone, I apologize if there was some misunderstanding. Definitely use a good password manager.

John Verry (35:48):

Any last thoughts? Anything we missed?

Josh Amishav (35:53):

No, I think we covered everything. That’s all I got on my end.

John Verry (35:57):

I don’t know if anyone listening could tell, but we actually are a customer of Breachsense. Our pen testing group actually uses Breachsense. I didn’t realize that the first time I talked to Josh. I was embarrassed by that. I went and I told that our guy who runs the practice, I’m like, “Hey, I’m talking to this guy from a company called Breachsense. You might want to listen.” “Oh yeah, we use them.” I’m like, “How come I don’t know that?” So yeah, we’re a happy customer. I can actually not only speak to the validity and value of this idea, but I can also speak to the quality of the work that they do because we’ve had a lot of success with it. So, thank you and our customers thank you as well.

Josh Amishav (36:34):

Oh, thanks for the endorsement. Thanks for having me on.

John Verry (36:37):

Oh, no worries at all. So if folks wanted to get in touch with you, Josh, what’s the easiest way to do that?

Josh Amishav (36:42):

All right. So, Twitter. I’m @Jamuse, J-A-M-U-S-E. I’m on LinkedIn, or you can hit me up on email in [email protected].

John Verry (36:51):

Gotcha. Heartedly, if you’re a technical listener, not a business guy that listens to this podcast just to keep on top of stuff, but if you’re a techie, if you like deep dives, Josh’s podcast is really good. I’ve listened to probably 10 of them and I learned something every time I listened to it. So, a great podcast if you’re into the tech of information security.

Josh Amishav (37:16):

Thank you.

John Verry (37:17):

Cool beans, man. Well, listen, I really appreciate you coming on. I enjoyed it. I apologize for being a little bit late on you.

Josh Amishav (37:22):

All good.

John Verry (37:23):

I will never try to stop at Starbucks again on my way to a podcast.

Josh Amishav (37:29):

When you first mentioned that, I was like, “Oh, I hope you weren’t in an accident.” So, glad you’re all right.

Speaker 1 (37:33):

You’ve been listening to The Virtual CISO podcast. As you’ve probably figured out, we really enjoy information security. So if there’s a question we haven’t yet answered or you need some help, you can reach us at [email protected]. To ensure you never miss an episode, subscribe to the show in your favorite podcast player. Until next time, let’s be careful out there.