Category Archives: Uncategorized

MyFitnessPal Breach – Take-Aways

It was recently announced that MyFitnessPal suffered a breach of around 150 million records ( The breach affected usernames, email addresses and hashed passwords. There are no reports that any other personal information, such as SSN or credit card info has been impacted. It is always important for us to understand the actual types of data exposed as it changes how we look at the risk created to the users. It is important to point out that while the site may allow purchases using credit cards, the way they are processing them doesn’t actually store them.

I don’t know what process is followed in this particular instance, but many applications now use 3rd party payment processors so there is no need for the site to store credit card numbers. Instead, the payment process is offloaded to the 3rd party, which in turn helps provide better protection for the information.

If we look at what type of information was released by the organization, we can make some assumptions about things we can do to help strengthen our own applications from this type of breach. The purpose is not to berate the group that got breached, but instead to learn from their experience. We already took a quick look at processing credit cards and how taking proper steps to not store them locally helps add a layer of protection. The next most important part of the information actually breached were the passwords. Well, hashed passwords. It was interesting that the statement in the article and the email sent by MyFitnessPal to its users stated that a majority of the passwords were hashed using bCrypt. This indicates that not all of the passwords were hashed this way. Of course, we don’t know how they were hashed, or even if they were hashed, so let’s focus on the fact that the ones that were hashed were hashed with bCrypt. When we talk about storing passwords, the two most commonly recommended algorithms are bCrypt and PBKDF2.

These algorithms combine both a unique salt per hash and a work factor. Hashing algorithms are perfect for storing passwords, because we rarely ever need to reverse the password back to its original value. Instead, we can hash the user supplied password at login and then compare it to the stored original hash. Unfortunately, hashing algorithms are fast, which makes them easier to brute force because a program can generate a large number of hashes very quickly. This is why the work factor is important. It slows down the hash process to reduce the number of hashes that can be created in a specified timeframe.

When we see a breach where it is announced that the passwords were stored using bCrypt or PBKDF2, there is a better chance that the passwords won’t actually be compromised. There are some exceptions and things to think about with this.

  • First, don’t make the mistake of announcing you used a certain algorithm when you didn’t. There are plenty of people that will get their hands on that data and if it is determined that the information provided was inaccurate, the fallout could be much worse than having just been honest up front.
  • Second, just because the passwords are properly hashed, poorly chosen passwords are still not very protected.

Passwords are a simple, yet complex beast. Determining what a good password is can be difficult and we see all sorts of rules about them on every site. We are taught that longer passwords are better passwords. And this is usually true. But we also have to realize that using common passwords, even if long, is a bad practice. Users that choose passwords like ‘Winter 2018’ are much more susceptible to having their password cracked, even if it was hashed with these recommended algorithms. I don’t recommend blocking users from using any random password that has been breached in the past, not associated with their account. However, you could block passwords that are on the “top 1000” type lists of commonly used passwords. For those users using password managers, this shouldn’t be a problem since they can be creating long randomly generated passwords.

The other part of the breach process I want to touch on is around the response to a breach. When we think about our SDLC, we should have a part where we start thinking about response plans. This is where we think about what types of events may occur, and more importantly, who will need to be involved if those events occur. Having the right response can have a huge impact on how the organization is perceived following a breach.

The type of information provided to the customers or end users and how it is provided is critical. We have seen with other breaches where if it appears the breach was covered up, or the information is inaccurate, people will have a very negative view of the organization. Make sure your organization has taken steps to identify the right people to have involved when getting ready to send out alerts. For example, you may want to have legal, marketing, HR, or other resources available. Each has their own specialty that can help make a smooth announcement.

As developers, as we identify potential breach scenarios, we can start to consider processes to handle them. For example, if your credentials database gets breached, what steps might you take to help protect the users. FIrst and foremost, containing the breach and making sure it is over. Then, how would you force a password reset to make sure that any passwords breached are no longer useful.

Use this recent breach as an excuse to review some of your internal processes.

How are you storing passwords?

How would you handle a password breach?

Reviewing these situations every once in a while is a healthy way to ensure that your applications are up-to-date in these protections.

Insulin Pump Vulnerability – Take-aways

It was recently announced that there were a few vulnerabilities found with some insulin pumps that could allow a remote attacker to cause the pump to distribute more insulin than expected. There is a great write up of the situation here. When I say remote attack, keep in mind that in this scenario, it is someone that is within close proximity to the device. This is not an attack that can be performed via the Internet.

This situation creates an excellent learning opportunity for anyone that is creating devices, or that have devices already on the market. Let’s walk through a few key points from the article.

The Issue

The issue at hand was that the device didn’t perform strong authentication and that the communication between the remote and the device was not encrypted. Keep in mind that this device was rolled out back in 2008. Not to say that encryption wasn’t an option 8 years ago, for these types of devices it may not have been as main stream. We talk a lot about encryption today. Whether it is for IoT devices, mobile applications or web applications, the message is the same: Encrypt the communication channel. This doesn’t mean that encryption solves every problem, but it is a control that can be very effective in certain situations.

This instance is not the only one we have seen with unencrypted communications that allowed remote execution. It wasn’t long ago that there were computer mice and keyboards that also had the same type of problem. It also won’t be the last time we see this.

Take the opportunity to look at what you are creating and start asking the question regarding communication encryption and authentication. We are past the time where we can make the assumption the protocol can’t be reversed, or it needs special equipment. If you have devices in place currently, go back and see what you are doing. Is it secure? Could it be better? Are there changes we need to make. If you are creating new devices, make sure you are thinking about these issues. Communications is high on the list for all devices for security vulnerabilities. Make sure it is considered.

The Hype, or Lack of

I didn’t see a lot of extra hype over the disclosure of this issue. Often times, in security, we have a tendency to exaggerate things a bit. I didn’t see that here and I like it. At the beginning of this post I mentioned the attack is remote, but still requires close physical proximity. Is it an issue: Yes. is it a hight priority issue: Depends on functionality achieved. As a matter of fact, the initial post about the vulnerabilities states they don’t believe it is cause for panic and the risk of wide scale exploitation is relatively low. Given the circumstances, I would agree. They even go on to say they would still use this device for their children. I believe this is important because it highlights that there is risk in everything we do, and it is our responsibility to understand and choose to accept it.

The Response

Johnson and Johnson released an advisory to their customers alerting them of the issues. In addition, they provided potential options if these customers were concerned over the vulnerabilities. You might expect that the response would downplay the risk, but I didn’t get that feeling. They list the probability as extremely low. I don’t think there is dishonesty here. The statement is clear and understandable. The key component is the offering of some mitigations. While these may provide some inconvenience, it is positive to know there are options available to help further reduce the risk.

Attitude and Communication

It is tough to tell by reading some articles about a situation, but it feels like the attitudes were positive throughout the process. Maybe I am way off, but let’s hope that is true. As an organization it is important to be open to input from 3rd parties when it comes to the security of our devices. In many cases, the information is being provided to help, not be harmful. If you are the one receiving the report, take the time to actually read and understand it before jumping to conclusions.

As a security tester, it is important for the first contact to be a positive one. This can be difficult if you have had bad experiences in the past, but don’t judge everyone based on previous experiences. When the communication starts on a positive note, the chances are better it will continue that way. Starting off with a negative attitude can bring a disclosure to a screeching halt.


We are bound to miss things when it comes to security. In fact, you may have made a decision that years down the road will turn out to be incorrect. Maybe it wasn’t at the time, but technology changes quickly. We can’t just write off issues, we must understand them. Understand the risk and determine the proper course of action. Being prepared for the unknown can be difficult, but keeping a level head and honest will make these types of engagements easier to handle.

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 or @jardinesoftware on twitter.

How Serious is Username Enumeration

Looking through Twitter recently, I caught a very interesting stream that started with the following message:

There were quite a few replies, and a good discussion on the topic of the seriousness of username enumeration flaws. 140 characters is difficult to share a lot of thoughts, so I thought this would actually be a great post.

What is Username Enumeration?

Username Enumeration refers to the ability to determine not only if a username is valid within a specific application, but also to automate the process of identifying a multiple valid usernames. The most common example of username harvesting is on the application logon form. The culprit, the unsuccessful login error message. This happens because the application creators want to be helpful and let the user know what went wrong. When the message is not generic, for example “unsuccessful login”, it may indicate if the user exists or not. An example message would be “Username does not exist”. This is bad. A better response would be “Username or password are incorrect”. This is a much more generic answer and doesn’t give away whether or not the username is valid.

Where do we find Username Enumeration?

As I mentioned above, the login screen is one of the most common locations we find username harvesting. However, it is not the only place. Probably the two next biggest offenders are the Forgot Password screen and the User Registration screen. With all three of these screens, it is critical to realize that the display message is not the only way to detect username harvesting. In reality, it is any difference that comes back between an invalid and a valid user. This could be the error message, a status code that is different, timing attacks, or a myriad of other techniques. Don’t just think about the error message. That one is typically the easiest, but not the only method for identification. API calls may also be a source for username harvesting.

The Login Form

The login form is typically vulnerable through the error message. To help protect the login form, make sure that the application returns a generic error message for any error situation. A good example of this is “Your login attempt was unsuccessful. If you continue to have trouble, contact support.” This message is good for invalid username, invalid password, and even account lockout.

The Forgot Password Form

The forgot password screen is usually vulnerable due to poor forget password design. Most systems ask for the username/email address and if correct, do one of the following: 1) Ask for secret security questions, 2) Display a message that an email has been sent to the email address on record. Unfortunately, for an incorrect username, the system returns an error message that the username was not found. To correct this problem, it is possible to either ask for more than just the username (something that is private to the account), or just always display the “email has been sent” message. In this configuration, no matter what, the email is sent form is displayed.

The Registration Form

The registration screen is a bit more tricky because, in most situations, you need to be able to alert the user that their username is already in use. Unlike the other two scenarios, the error message can’t really be fixed. One option on a registration screen is to enable the use of a CAPTCHA to attempt preventing automation attacks. If implemented properly the attacker would be slowed down in their enumeration making things more difficult. It may not make it impossible, but the goal is to reduce the risk.

How is Username Enumeration Used?

There are a few ways that username enumeration becomes important to an attacker. First, it is a good technique to limit down the list of possible usernames to attempt password attacks on. One example on twitter gave the example of taking a list of 100 million usernames and reducing it to 100 thousand to perform actual password guessing on. In this scenario, the attackers are also attempting to take advantage of weak password complexity, or just bad password hygiene. Often times, they may take the top 3 or 4 common passwords and try those against all of the valid usernames to see if anyone is using them.

The second way that username enumeration is used is for social engineering attacks. Or, at least, more targeted social engineering attacks. If the attacker knows that the user has an account on a specific application, it can make phone calls and emails much more convincing and ultimately more successful. Limiting emails to 100,000 users rather than 100 million helps reduce the overhead and reduces the chances of getting detected.

Somewhat related to social engineering attacks, this information could also be used to target individuals based on moral values. Remember the Ashley Madison breach that happened a while back. Depending on what the username is in use, it may be possible to identify people that use a particular site and sort of out them, or blackmail them. Think of other sites people may not want to be public about visiting.

How Serious is it?

I bet you didn’t think we would ever get here. It is important to understand how the attackers may be using a vulnerability to start to determine how serious it really is. Unfortunately, there isn’t an easy answer that fits every application. As I mentioned above, with poor password hygiene, the risk would be raised if someone is using one of those top 4 passwords. It also depends on the type of system, the type of data collected, the functionality the application performs, etc. No systems are created or rated equally.

In the scenario above for the login screen guessing the top 4 passwords, let’s not forget that it is possible to try all 100 million usernames from our list. Sure, it is helpful to reduce it down to only valid usernames, but the attack is still possible without the username enumeration flaw. In the ideal setup, the application would have some form of detection system in place that might detect all of the unsuccessful login attempts, but that is the ideal. It is not common enough to see that type of detection implemented in many applications. Without that detection, and a little crafty rate limiting by an attacker, the difference between 100 million attempts and 100,000 attempts is really just time.

As we all know, social engineering attacks are the latest and greatest. Any help we provide attackers in that arena is a step backwards for us. This could lead to a bigger problem and that is why we need to understand the issues we are trying to solve.

Should we fix it?

If we had all the time and resources in the world, the answer would be an easy “yes”. Unfortunately, we don’t have that. This really comes down to your organization’s risk assessments and priorities. I always like to provide the recommendation to resolve the issue, as it makes for a better application overall. Depending on your situation, the fix may not be straight forward or easy. You may have other higher priority items that need to be worked on. Remember, for the password attack, it is really a combination of a weak password issue as well. It is not just username harvesting on its own.

Take the opportunity to review how you are auditing and logging these types of events within your application. In some cases we may see logging occurring, but then there is no auditing of those logs. Detection and response is critical in helping reduce the risk of these types of flaws.

Continuing Forward

Username enumeration is a risk to any application. It is up to the organization to understand their business to determine how big or small that risk is. This isn’t something that should just be ignored, but it also doesn’t mean it is something that is a critical finding. Don’t just write the finding off. Use that as an opportunity to discuss the functionality, understand how it works, and determine the best course of action for the organization and the users.

Username enumeration is typically fairly simple to test for and should be worked into the QA testing cycle. Take the time to discuss with the architects, developers, business analysts, and the testers how the organization can test for this and reduce the risk.

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 or @jardinesoftware on twitter.

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 or @jardinesoftware on twitter.

Originally posted at

Introduction to Penetration Testing for Application Teams

In this presentation, James Jardine focuses on educating application teams on what a penetration test is and how to extract the most value from it. Application teams learn how to participate in the engagement and better understand the report.

You can watch the recorded session at any time at:

Sharing with Social Media

Does your application provide a way for users to share their progress or success with others through social media? Are you thinking about adding that feature in the future? Everyone loves to share their stories with their friends and colleagues, but as application developers we need to make sure that we are considering the security aspects of how we go about that.


  • Use the APIs when talking to another service
  • Don’t accept credentials to other systems out of your control
  • Check with security to validate that your design is ok

This morning, whether true or not (I have not registered for the RSA conference), there was lots of talk about the RSA registration page offering to post a message to your twitter account regarding you going to the RSA conference. Here is a story about it. The page asks for your twitter username and password to then post a message out on your twitter account. Unfortunately, that is the wrong way to request access to post to a social media account.

Unfortunately, even if you have the best intentions, this is going to come across in a negative way. People will start assuming you are storing that information, that you know have access to important peoples twitter accounts going forward. Maybe you do, maybe you don’t, the problem there is that no one knows what happened with that information.

Just about every social media site out there has APIs available and support some oAuth or other authorization mechanism to perform this type of task. By using the proper channel, the user would be redirected to the social media site (Twitter in this instance) and after authenticating there, would provide authorization for the other site to post messages as the registered user.

Using this technique, the user doesn’t have to give the initial application their social media password, instead they get a token they can use to make the post. The token may have a limited lifetime, can be revoked, and doesn’t provide full access to the account. Most likely, the token would only allow access to post a message. It would not provide access to modify account settings or anything else.

If you are looking to integrate or share with social media sites, take the time to determine the right way to do it. This is really important when it involves access to someone else account. Protect the user and yourself. Don’t just take the easy way out and throw a form on the screen. Understand the architecture of the system and the security that needs to be in place. There are a lot of sites that allow sharing with social media, understand how they are doing it. When in doubt, run this by someone else to see if what you are planning on doing looks like the right way to do it.

3rd Party CMS Security

One of the easiest ways to get content available on the Internet is to use a 3rd party content management system (CMS). These systems vary and are usually fairly simple to set up. There is no requirement for any technical knowledge and you can have content up and available within minutes in some cases. No need for that pesky HTML coding or web site management. One of the most common CMS platforms is WordPress ( Of course there are many other systems available, but it is common to hear about WordPress when it comes to security, highlighted recently in the article on threat post titled “More Than 1 Million WordPress Sites Open to SQL Injection Attacks“. As I was writing this post I did a quick search for Word Press in the news and this article titled “Bug in WordPress plugin can be exploited to take full control of website” from SC Magazine popped up from today.

To listen to the podcast on this topic you can go to

The previous examples are just a few of the vulnerabilities that have been released related to WordPress. You may be wondering if WordPress is safe to use, and I believe that it is. When we dig a little deeper into many of the news headlines about WordPress security, they often are not vulnerabilities in the core WordPress functionality, but in the plugins that are available. Plugins are 3rd party code that can be added to WordPress to add functionality. An example plugin would be to create a custom signature or bio box below each article. There are also plugins for statistics, multi factor authentication and controlling comment spam.

As mentioned, while vulnerabilities have been identified in the core components, it appears to be far more common for vulnerabilities to be identified in these additional plugins. In most cases, the developers are quick to release a patch once the vulnerability has been identified. The bad news – Many of the patches are not auto-applied. Here are some things to think about if you are implementing a WordPress solution for your systems.

WordPress AutoUpdate
The more recent versions of WordPress support an automatic update feature. If you are using the hosted version of WordPress then the updates should be handled, but if you have decided to host your WordPress site on your own servers this is not the case. Check with your hosting provider to see if they have a mechanism for updating your WordPress installation automatically. Also make sure that you are running the latest version of WordPress and you have enabled the auto-update feature. This will ensure that you have the latest patches for the core system, limiting the exposure of your site.

Know Your Plugins
Plugins have vulnerabilities and may require security patches. The first bit of advice in regards to plugins is to only run the plugins that you absolutely need. The fewer plugins that you have installed means the attack surface is smaller than with a bunch of plugins running out there. Now that you have limited the plugins that are installed, keep an inventory of them. Once you know which ones are installed you can watch the news or different social media feeds to see if any of them are identified. I am not aware of a way for the plugins to auto-update, it is a manual process. If you see that a plugin has been identified as vulnerable make sure that the update (when released) is applied as soon as possible. It is recommended to test the patch out to ensure it will not break anything before hand. If the patch does break something, a determination will have to be made as to whether or not the plugin must be uninstalled or not.

Use Security Controls
Get to know your CMS and what controls exist to help increase your security. If multi factor authentication is available, enable it. If you don’t need some features, then disable them. Maybe your site doesn’t use comments on articles. If that is the case, then turn that feature off.

Remove Default Configurations
Once the site is installed, remove default files that may have been used during installation but are not needed for day to day activity. It is common to see the installers leave behind files that are no longer needed. Scan your system with a tool like WPScan (for WordPress) to see if there are any gaping security holes. Make sure you have set the username and password for the system. Many of these platforms have removed the “default” credentials, but it is your responsibility to make sure that default credentials don’t exist.

Many of the CMS platforms are similar and support many of the same features. The recommendations listed above work for all of these. The point is that you have to be aware of your platforms, what components they use, and how to update those components in a timely manner. The benefits of a CMS are huge when used properly, but can be devastating if attacked.