• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

DevelopSec

  • Home
  • Podcast
  • Blog
  • Resources
  • About
  • Schedule a Call

developer training

August 23, 2017 by James Jardine Leave a Comment

Understanding Your Application Platform

Building applications today includes the use of some pretty impressive platforms. These platforms have so much built in capability, many of the most common tasks are easily accomplished through simple method calls. As developers, we rely on these frameworks to provide a certain level of functionality. Much of which we may never even use.

When it comes to security, the platform can be a love/hate relationship. On the one hand, developers may have little control over how the platform handles certain tasks. On the other, the platform may provide excellent security controls. As we mature these platforms, we see a lot of new, cool security features enabled by default. Many view engines have cross-site scripting protections built in by default. Many of the systems use ORM to help reduce SQL Injection vulnerabilities. The problem we often run into is we don’t really know what our platform does and does not provide.

A question was posed about what was the most secure application platform, or which would you recommend. The problem to that question is that the answer really is “It depends.” The frameworks are not all created equally. Some have better XSS preventions. Others may have default CSRF prevention. What a framework does or doesn’t have can also change next month. They are always being updated. Rather than pick the most secure platform, I recommend to people to take the time to understand your platform of choice.

Does it matter if you use PHP, Java, .Net, Python, or Ruby? They all have some built in features, they all have their downfalls. So rather than trying to swap platforms every time a new one gets better features, spend some time to understand the platform you have in front of you. When you understand the risks that you face, you can then determine how those line up with your platform. Do you output user input to a web browser? If so, cross site scripting is a concern. Determine how your platform handles that. It may be that the platform auto encodes that data for you. The encoding may only happen in certain contexts. it may be the platform doesn’t provide any encoding, but rather leaves that up to you.

While the secure by default is more secure, as it reduces the risk of human oversight, applications can still be very secure without it. This is where that understanding comes into play. If I understand my platform and know that it doesn’t encode for me then I must make the effort to protect that. This may even include creating your own function or library that is used enterprise wide to help solve the problem. Unfortunately, when you don’t understand your platform, you never realize that this is a step you must take. Then it is overlooked and you are vulnerable.

I am also seeing more platforms starting to provide security guidelines or checklists to help developers with secure implementation. They may know of areas the platform doesn’t create a protection, so they show how to get around that. Maybe something is not enabled by default, but they recommend and show how to enable that. The more content like this that is produced the more we will understand how to securely create applications.

Whatever platform you use, understanding it will make the most difference. If the platform doesn’t have good documentation, push for it. Ask around or even do the analysis yourself to understand how security works in your situations.

Filed Under: General Tagged With: application security, developer, developer training, development, secure design, secure development, security, security coding, security testing, testing

April 16, 2017 by James Jardine Leave a Comment

Sub Resource Integrity – SRI

Do you rely on content distribution networks or CDNs to provide some of your resources? You may not consider some of your resources in this category, but really it is any resource that is provided outside of your server. For example, maybe you pull in the jQuery JavaScript file from ajax.googleapis.com rather than hosting the file on your server.
These CDNs provide a great way to give fast access to these resources. But how do you know you are getting the file you expect?

As an attacker, if I can attack multiple people vs just one, it is a better chance of success. A CDN provides a central location to potentially affect many applications, vs. targeting just one. Would you know if the CDN has modified that file you are expecting?

Welcome Sub Resource Integrity, or SRI. SRI provides the ability to validate the signature of the file against a predetermined hash. It is common for websites that provide files for downloads to provide a hash to validate the file is not corrupt. After downloading the file, you would compute the hash using the same algorithm (typically MD5) and then compare it to the hash listed on the server.

SRI works in a similar way. To implement this, as a developer you create a hash of the expected resource using a specified hashing algorithm. Then, you would add an integrity attribute to your resource, whether it is a script element or stylesheet. When the browser requests the resource, it will compute the hash, compare it to the integrity attribute and if successful, will load the resource. if it is unsuccessful, the file will not be loaded.

How it works

Lets look at how we would implement this for jQuery hosted at google. We will be including the reference from https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js

Initially, we might start by just creating a script tag with that as the source. This will work, but doesn’t provide any integrity check. There are a few different ways we can create the digest. An easy way is to use https://www.srihash.org/. The site provides a way to enter in the url to the resource and it will create the script tag for you.

Another option is to generate the hash yourself. To do this you will start by downloading the resource to your local system.

Once the file is downloaded, you can generate the hash by executing the following command:


openssl dgst -sha384 -binary Downloads/jquery.min.js | openssl base64 -A

Make sure you change Downloads/jquery.min.js to your downloaded file path. You should see a hash similar to:

xBuQ/xzmlsLoJpyjoggmTEz8OWUFM0/RC5BsqQBDX2v5cMvDHcMakNTNrHIW2I5f

Now, we can build our script tag as follows (Don’t forget to add the hashing algorithm to the integrity attribute:

<script src=”https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js” integrity=”sha384-xBuQ/xzmlsLoJpyjoggmTEz8OWUFM0/RC5BsqQBDX2v5cMvDHcMakNTNrHIW2I5f” crossorigin=”anonymous”></script>

Notice that there is a new crossorigin attribute as well. This is set to anonymous to allow CORS to work correctly. The CDN must have CORS set up to allow the integrity check to occur.

If you want to test the integrity check out, add another script tag to the page (after the above tag) that looks like the following:

<script>alert(window.jQuery);</script>

When the page loads, it should alert with some jQuery information. Now modify the Integrity value (I removed the last character) and reload the page. You should see a message that says “undefined”. This means that the resource was not loaded.

Browser support is still not complete. At this time, only Chrome, Opera, and Firefox support this feature.

Handling Failures

What do you do if the integrity check fails? You don’t want to break your site, right? Using the code snippet we tested with above, we could check to make sure it loaded, and if not, load it from a local resource. This gives us the benefit of using the CDN most of the time and falling back to a local resource only when necessary. The following may be what the updated script looks like:

<script src=”https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js” integrity=”sha384-xBuQ/xzmlsLoJpyjoggmTEz8OWUFM0/RC5BsqQBDX2v5cMvDHcMakNTNrHIW2I5f” crossorigin=”anonymous”></script>
<script> window.jQuery || document.write(‘<script src=”/jquery-.min.js”><\/script>’)</script>

When the integtrity check fails, you can see the local resource being loaded in the image below:

SRI-1

If you are using resources hosted on external networks, give some thought about implementing SRI and how it may benefit you. It is still in its early stages and not supported by all browsers, but it can certainly help reduce some of the risk of malicious files delivered through these networks.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Filed Under: General Tagged With: 3rd party component, application security, AppSec, developer training, development, secure design, secure development, security awareness, SRI, Sub Resource Integrity

February 6, 2017 by James Jardine Leave a Comment

Security Tips for Copy/Paste of Code From the Internet

Developing applications has long involved using code snippets found through textbooks or on the Internet. Rather than re-invent the wheel, it makes sense to identify existing code that helps solve a problem. It may also help speed up the development time.

Years ago, maybe 12, I remember a co-worker that had a SQL Injection vulnerability in his application. The culprit, code copied from someone else. At the time, I explained that once you copy code into your application it is now your responsibility.

Here, 12 years later, I still see this type of occurrence. Using code snippets directly from the web in the application. In many of these cases there may be some form of security weakness. How often do we, as developers, really analyze and understand all the details of the code that we copy?

Here are a few tips when working with external code brought into your application.

Understand what it does

If you were looking for code snippets, you should have a good idea of what the code will do. Better yet, you probably have an understanding of what you think that code will do. How vigorously do you inspect it to make sure that is all it does. Maybe the code performs the specific task you were set out to complete, but what happens if there are other functions you weren’t even looking for. This may not be as much a concern with very small snippets. However, with larger sections of code, it could coverup other functionality. This doesn’t mean that the functionality is intentionally malicious. But undocumented, unintended functionality may open up risk to the application.

Change any passwords or secrets

Depending on the code that you are searching, there may be secrets within it. For example, encryption routines are common for being grabbed off the Internet. To be complete, they contain hard-coded IVs and keys. These should be changed when imported into your projects to something unique. This could also be the case for code that has passwords or other hard-coded values that may provide access to the system.

As I was writing this, I noticed a post about the RadAsyncUpload control regarding the defaults within it. While this is not code copy/pasted from the Internet, it highlights the need to understand the default configurations and that some values should be changed to help provide better protections.

Look for potential vulnerabilities

In addition to the above concerns, the code may have vulnerabilities in it. Imagine a snippet of code used to select data from a SQL database. What if that code passed your tests of accurately pulling the queries, but uses inline SQL and is vulnerable to SQL Injection. The same could happen for code vulnerable to Cross-Site Scripting or not checking proper authorization.

We have to do a better job of performing code reviews on these external snippets, just as we should be doing it on our custom written internal code. Finding snippets of code that perform our needed functionality can be a huge benefit, but we can’t just assume it is production ready. If you are using this type of code, take the time to understand it and review it for potential issues. Don’t stop at just verifying the functionality. Take steps to vet the code just as you would any other code within your application.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Filed Under: General Tagged With: application security, AppSec, copy, developer, developer training, passwords, paste, secure code, secure defaults, security, security training

June 3, 2016 by James Jardine Leave a Comment

Understanding the “Why”

If I told you to adjust your seat before adjusting your mirror in your car, would you just do it? Just because I said so, or do you understand why there is a specific order? Most of us retain concepts better when we can understand them logically.

Developing applications requires a lot of moving pieces. An important piece in that process is implementing security controls to help protect the application, the company, and the users. In many organizations, security is heavily guided by an outside group, i.e.. the security group or 3rd party testers.

Looking at an external test, or even a test by an internal security team, often the result is a report containing findings. These findings typically include a recommendation to guide the application team in a direction to help reduce or mitigate the finding. In my experience, the recommendations tend to be pretty generic. For example, a username harvesting flaw may come with a recommendation to return the same message for both valid and invalid user names. In most cases, this is a valid recommendation as it is the reason for the flaw.

But Why? Why does it matter?

Working with application teams, it quickly becomes clear the level of understanding regarding security topics. The part that is often missing is the Why. Sure, the team can implement a generic message (using the username harvesting flaw above) and it may solve the finding. But does it solve the real issue? What are the chances that when you come back and test another app for this same development team that the flaw may exist somewhere else? When we take the time to really explain why this finding is a concern, how it can be abused, and start discussing ways to mitigate it, the team gets better. Push aside the “sky is falling” and take the time to understand the application and context.

As security professionals we focus too much on fixing a vulnerability. Don’t get me wrong, the vulnerability should be fixed, but we are too focused. Taking a step back allows us to see a better approach. It is much more than just identifying flaws. It is about getting the application teams to understand why they are flaws (not just because security said so) so they become a consideration in future development. This includes the entire application team, not just developers. Lets look at another example.

An Example

Let’s say that you have a change password form that doesn’t require the current password. As a security professional, your wheels are probably spinning. Thinking about issues like CSRF. From a development side, the typical response “Why do I need to input my password when I just did that to login to change my password?” While the change will most likely get made, because security said it had too, there is still a lack of understanding from the application team. If CSRF was your first reason, what if they have CSRF protections already in place? Do you have another reason? What about if the account is hijacked somehow, or a person sits at the user’s desk and they forgot to lock their PC? By explaining the reasoning behind the requirement, it starts to make sense and is better received. It dominos into a chance that the next project that is developed will take this into consideration.

When the business analysts sits down to write the next change password user story, it will be a part of it. Not because security said so, but because they understand the use case better and how to protect it.

If you are receiving test results, take the time to make sure you understand the findings and the WHY. It will help providing a learning objective as well as reduce the risk of not correcting the problem. Understand how the issue and remediation effects your application and users.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Originally posted at https://www.jardinesoftware.com

Filed Under: Uncategorized Tagged With: applicaitons, application security, AppSec, ba, developer, developer training, development, penetration testing, qa, secure development, security, security testing

January 25, 2014 by James Jardine Leave a Comment

Ep. 1: Introduction to the Podcast

Hey everyone,

I have spent a lot of time working in application security and prior to that, development. Over the years, I have had a chance to reflect a bit on some of the security issues I saw as a developer and as a security practitioner. In an effort to help share some of this knowledge and experience, I am starting a podcast series focused on secure development.  The goal is for shorter, 10-20 minute, episodes. I hope you take a moment to take a listen.

Transcript:

Hi, and welcome to the very first episode of the DevelopSec podcast, where our goal is to help develop security awareness amongst the individuals out in the world.

I’m your host, James Jardine. If you don’t know who I am, I started off as a developer, I started getting into application security a few years back. And now I actually am a principal security consultant at secure ideas here in Jacksonville, Florida. And I spend most of my time dealing with security. And so one of the things I wanted to do with this podcast was take some of that knowledge from both the defense side and the attack side, and bring it together and help bring some of this information to people that just may not be getting it or people that are just trying to get into security, we have a real strong need for security to be made more available.

In the security industry, we have many cons that we go to. There’s a con every week, I think, someplace across the world, maybe multiple cons every week, where security professionals get together and talk about some of the concerns that we have. But most of the time, we don’t see developers coming to those type of cons. And if you go to a developer con, there’s usually very little security talk going on. And so we really need to start finding ways where we can reach out to the developer community, and not just developer community, but other people involved with the development of applications that are running applications. So that way, everybody’s under the same knowledge base regarding security and how to protect people’s information.

Privacy is a huge concern these days. And we see it all the time in the news, we have to think more of just the vulnerabilities that we see. But the data that we’re collecting, and what do we do with that data? How do we treat that data? And that’s something that we’re seeing all the time now being brought to light, for example, the healthcare.gov site that everybody’s been talking about for the past few months, and concerns around security around it. And, you know, the big question there as is, what type of access, could somebody have to my personal information? If they were to do something malicious to that site? Whether it be some sort of SQL injection or harvesting of information, somehow gathering my personal information? What could they possibly do? Could they steal my identity? Could they, you know, use my credit cards to run up a massive amount of debt? You know, I don’t know, we, you know, nobody’s seen an actual assessment against the site to know what’s there. But there’s been lots of talk about, what are the privacy issues? What are the security concerns, and one of the biggest pushes around that site?

Really, when we talk about security is the question of, are we building security into our applications, as we build them. Security is not something that we can just bolt on afterwards. And it works all effortlessly. We can’t just deploy a web application firewall, and we’re all good. There’s lots to go about when we’re talking about building a secure application. And we don’t always have to trade functionality for security, we can, if we understand security, build the application with both functionality and security in mind.

Now, if you watch the news lately, not only have we seen healthcare.gov in the spotlight, but we also saw a little bit closer to us Snapchat, they had an issue where somebody actually exploited their API that they have available to be able to enumerate all the usernames or a large portion of the usernames and their phone numbers and pulling that information out. Again, this is something where we have to think well, you know, what information was taken? What could they have done? You know, it was brought to them that, hey, you have this problem? And, you know, maybe their concern was, well, you know, we’re okay with that. That risk being out there. And then somebody went ahead and exploited it, you know, and pulled that information down to show them, hey, this is what could happen. And the constraints that you put in place were easily by passable, and a lot of times developers don’t understand how it is that we can easily bypass some of the constraints that they put in place to try to block some of these attacks.

So we saw Snapchat lose 4.6 million user names and phone numbers. Most recently, we had Neiman Marcus, just identify that I think they had a little over a million credit card numbers stolen And from a breach that they had really big in the news is the Target breach, talking 40 million credit card and debit card numbers that got scraped out of their systems. And this is a big concern. I mean, these big retailers are somebody that, you know, we almost have to go to, right. I mean, there’s not that many big big retailers that are giving us what we need.

So when we start seeing companies like this, getting breached, it raises that concern level. And, you know, I don’t know about the cyber side of target. I know my wife and I watched an episode a few years back talking about Target’s more physical security side where they have more than just a loss prevention individual within the stores, but a team of professionals that actually track down fraud going on in the stores, and going out and finding people that are defrauding the store. So they take security seriously. But without all the details of really what happened, it’s hard to say, could they have done more? What should have been done? Why didn’t they detect this? Right? There’s lots of questions around this. And it’s going to be costly, right? Any of these breaches cost money, it costs the individual their time of having to get a new credit card. Now we have to update if we have automatic payments going on any place, we have to update this information. Now. It’s not that huge of a time drain, I don’t think for myself anyway. But it is going to be something that I have to spend a little bit of time on going through an updating some of that information. Credit card companies have to issue new credit cards, that’s a cost. So we have to think about that target itself. Right now has, they’re offering up $5 million to develop a program to help educate users on security issues. So the users are more educated on what’s going on. Right. And this is a big key, this is what we need to do we need to start educating the public. Because one of the things that happened when this breach occurred is a lot of people didn’t know what to do. My credit card numbers have been stolen, what what do I need to do? Do I need to put credit monitoring on do I need to cancel my car? Do I need to do this? Do I need to do that? People didn’t really have an idea because this isn’t the first time this has been brought out. Right? We saw this in TJ Max a few years ago where huge number of credit cards were stolen. But because it doesn’t happen publicly as his largest this, a lot of times we will kind of forget, well, what do I do here? My credit card number was stolen? Do I need to worry about ID theft? You know, do I have to worry about the charges that get put on my card. And this is the stuff that we want to start help educating the general public on. We want to start educating developers and business analysts and project managers and project owners on what it is to think about security help start implementing security into our systems. Look at a lot of the systems these days that never really were internet connected before but now are starting to become internet connected. Think about your smart TVs. Most of the TVs now come with a way to connect to the internet, either via a cable or through Wi Fi. So that we can now stream Hulu and Apple TV and all these different services straight into our TV. Well, now our TVs connected out to the Internet, what type of security was placed on there to determine if that TV is properly secured? We don’t know. I don’t know what type of security testing is going on there. But that’s stuff we want to start thinking about. Because now that’s a new device on our network that if not done correctly, could be that easy gateway for an attacker to get into our home networks. You think about security systems, a lot of security systems now are network connected. All these different control panels that we have, looking at control systems, right? I have the Nest thermostat and the smoke detectors, both of which connect to my network. So that way I can view the information at any time. Again, I mean, this is a huge deal of how much we’re becoming connected. Do these type of systems offer auto update? Do they update? Can they be updated? What if there is a security flaw found in one of these devices? Do I have to go spend $250 to replace it? Or is there a way that I can up you know, upload a firmware fix? We’re not thinking about these because a lot of the people that are creating these type of systems never had to think about internet connectivity you actually had to be there at the device. So an attacker would have to breach physical security get to the device connect directly to it, to be able to manipulate it. And that’s starting to change. So we’re starting to see a whole new set of developers coming into the world of security, because now they’re starting to see, wait a minute, this stuff that I was doing wasn’t really a big concern, because it was in this special little sandbox over here. But now we’re connecting it to the world. Now I have to start thinking about this. So as security professionals, we’ve been saying for years about how bad security is and how we need to fix it. And we’re starting to see security get better in web applications. Not all of them. But we are starting to see some security get better. And some companies are really starting to take it seriously about developing secure applications. But then we start looking at mobile apps, we start looking at these control systems and security systems, right? Mobile devices are the same thing. We’re seeing a lot of new developers come on board, everybody in their brothers creating mobile apps these days. But they developed developing them securely. And we’re not really seeing that all very often because people just jumping in. And they’re not the same people that have been developing web apps or desktop apps for the past 10 or 15 years, listening to the story of, Hey, why are we not doing this securely? You have to do this securely. Here’s your vulnerabilities and just getting browbeaten. For the past few years, these are all new people that maybe never developed before, before mobile devices ever came out. And they’re just coming in developing apps real quick, and they don’t really understand development, they don’t understand how the system they’re developing on actually works. So it’s a whole new breed of developers coming in that now we have to reach out to and start explaining again, hey, here’s the fundamentals of security. Here are what the attackers goals are why the attacker is coming after you. Oftentimes we hear, Oh, well, my company is too small, nobody would want to attack me. But that’s not necessarily the case. Because one of the biggest things in doing red teaming or the attack side, right is pivoting. Do I want to go after a large bank that has a lot of money to spend on creating a really strong security system? Where do I want to go after the small mom and pop store that has a direct connection into that bank, who doesn’t have the money to spend on top notch security, right? They maybe at best have some guy that they call when they have ID problems to come help them with ID, but they’re not doing anything with security, then tie mobile into that another, you know, doing stuff on their iPads. They’re, they’re just out and about using public Wi Fi messing with systems because they haven’t been trained on how to do this. So that’s one of the biggest goals that we want to kind of break down and greet here is the idea of raising the awareness level of why we need more security awareness why developers need to be involved, why more than developers need to be involved? Because it’s not just developers. Why did the general public should be more aware of how information security works? It’s our information that we’re passing to all these different companies, we should have an understanding of what they do to protect it, depending on the sector they’re in? How are they required to protect that information? What are they doing to protect that information and start demanding information on how they’re protecting my information that I’m giving them. So while we do that, some of the things that we’re going to cover, we’ll talk about the OWASP, top 10 list, which if you haven’t seen the OWASP, top 10, you got to owasp.org OW asp.org. They’ve got lots of information regarding web application security. So they talk about different types of attacks, how you can remediate those attacks. It’s a great developer resource to really get involved with. We’re also going to talk about sans top 25 Most Dangerous software errors. We’ll talk about the OWASP mobile top 10 vulnerabilities that are out there. Since mobile’s really starting to become big, I’m sure we’ll start to see some information about cloud vulnerabilities and the top items there. But we want to discuss from both sides are one what is the attackers perspective? And what should the defender be doing to help protect against that? I often use the analogy when I teach classes that, you know, defense is in doing software and applications, mobile applications. It’s very similar to this idea of building this castle. And I always like the analogy of a castle because it’s easy and it’s very simple. But when I build my castle If I don’t understand the attacks that are coming at my castle, then I can’t really understand how I should build my my castle to protect it. So if I’m thinking that an attack is coming from the ground, and it’s going to be close up, then the idea of a moat comes in really well, because now it’s going to be harder, right? I can raise my drawbridge, it’ll be harder for the attacker to get to my actual Castle, because now they can’t get across that moat, right? They got to come up with some means to get across there makes it more difficult. Can we still get across it? Yes. But it makes it that much more difficult. You have to earn that, right? And then if we think, Well, what if they’re going to catapult stuff, right? Well, maybe it’s going to be hard to catapult in the clear, so maybe I want trees closer. Right. So that way, there’s not as much clearing for them to be able to launch their catapults to shoot stuff at us. Or maybe we don’t want them to be able to use the trees that are close by to chop them down to build the ladders and stuff like that to get up into our castle, maybe we want a bigger clearing. So they have to be further away. And we can see further away from our castle, what’s going on. So we can then adjust and say Oh, I see people coming at us from a mile out, I can adjust to that quicker than adjusting to somebody that just came from 50 yards away. So it’s understanding these type of attacks. And how the adversaries coming at you is how you can then start to figure out what what is our best way to defend against these different attacks. So we’re going to look at it from both sides of that, as we go through this series. Some of the other things we’ll talk about, we’ll talk about some of the tools that are used both by attackers and tools that can be used by defenders, because tools often help us understand how the attacker works. This is especially big I just did, I wrote up a post talking about passwords. And how oftentimes people misunderstand what a secure password is. Because, you know, they think that it’s a oh, well, it’s something that only I know, because it was from 40 years ago. And it was my cat’s name that died and anybody else that knew that cat is dead now. So nobody else would ever know that cat’s name. Well, the problem is, is that’s not how attackers really go about attacking a password. Rarely is it where you’re sitting at somebody’s desk, and you’re looking at their pictures, like you see on TV, and you’re like, oh, they have a picture of their daughter, let’s try the daughter’s name. And it works. That’s usually not how it works, right? A lot of times are using automated tools to brute force these accounts. And so when we start realizing the ways and the techniques that attackers go about it, we can then start to understand why certain passwords wouldn’t be a good idea, right? Your cat’s name or you know, the the first car you owned, or some just random word that you just recognize with and nobody else would have any idea. doesn’t make as much sense now, because the tool doesn’t care about that, right? The tool is doing these dictionary type attacks and other brute force attempts that don’t take any of that into consideration to try to break into these.

We’ll talk about the techniques, both manual and through the tools that the attackers can use, that the defenders that the developers can use things that we as customers can actually use at home of ways where we can protect ourselves. When we’re shopping online, when we’re making transactions, everything we’re doing, we want to cover and really raise awareness of security for everybody. It’s got a stronger focus on developers, too, because they’re the ones that are creating these applications that we’re using. But it’s just as important for customers to understand how security works and how they can be secure. Whether you decide you want to implement Password Manager of some sort. The idea of using two factor authentication on any of the sites that you have, that’ll help increase that strength of protecting your accounts, all things that we’re going to talk about throughout this series.

So that really kind of wraps up this first episode. Hopefully Each episode will stay somewhere around 20 minutes as this one’s falling into. If you have any recommendations or questions, I encourage you to send them you can send them to info at develop sec.com You can also find the podcast out at developsec.libsyn.com as well. And we’re on Twitter as at develop sec. So thank you for your time and I look forward to the next episode

Filed Under: Podcast Tagged With: application security, AppSec, developer awareness, developer training, developsec, podcast, security, training

  • « Go to Previous Page
  • Go to page 1
  • Go to page 2

Primary Sidebar

Contact Us:

Contact us today to see how we can help.
Contact Us

Footer

Company Profile

Are you tackling the challenge to integrate security into the development process? Application security can be a complex task and often … Read More... about Home

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • GitHub
  • Twitter
  • YouTube

Contact Us

DevelopSec
Email: james@developsec.com



Privacy Policy

© Copyright 2018 Developsec · All Rights Reserved