DevelopSec

secure code

by Leave a Comment

Should Password Change Invalidate All Access Tokens?

Passwords are a part of our every day life. It is no wonder they are under such scrutiny, with many breaches focusing on them. We all know how to manage our passwords, or at least we should by now. We know that we should change our passwords every once in a while, especially if we believe they may have been a part of a recent breach. What about those access tokens?

Access tokens are typically used by your mobile devices to access your account without the need for you to enter in your username and password every time. In some situations, you may have to create an app password for your mobile device if you are using 2-factor authentication. This is because most applications still don’t support the 2-factor model. Instead, you create an application password and use that with your application.

Depending on your system, the management of these app passwords or tokens can vary quite a bit. In this post, I want to focus on how the ideal solution may work. First, the access tokens and the user’s password should not be related in any way. The closest they come to any relation is that they both provide authentication to the same application. This purpose here is that the compromise of one, does not compromise the other. While getting access to an access token may give me access to the account, it should not give me access to the password. If you are thinking that the access to the account means I could change the password, let me stop you right there. A good system would require the current password to be able to change the password. So this should be prohibited.

In the same vein, getting access to the account password should not lead to the compromise of the account’s access tokens. In a good system, there should be a way to manage these tokens, but that management should not include the ability to view existing tokens. Instead, that functionality is used to revoke an access token. In the instance of an application password (2-factor), you may also have the ability to create a new application password. This would still not give access to the existing password or token values.

So the question posed, or implied: If you change your account password, should that invalidate your devices?

If there is truly no relationship between the two items, and one doesn’t effect the other, then there may not be a reason to invalidate everything for every password change. As a good friend likes to always say, “what is the problem we are trying to solve?” So what is the problem? Let’s look at a few scenarios:

User just wanted to change their password

It is not unusual for a user to want to change their password. They may have even forgotten it. In this case, if the password and access tokens are unrelated, I don’t see a big risk around the access tokens that may have been created for other devices. The password should be completely separate from the access tokens and the change should have no impact to the mobile devices.

User’s password was leaked in a recent breach

This scenario is very similar to the one above. However, if an account has been compromised, it makes sense to review the devices that have been granted access and remove any that should not be there. The account compromise should not lead to the compromise of the access tokens already generated, but may enable the creation, or addition, of access tokens for new devices.

User’s device was lost or stolen

Something no one wants to think about, their device getting lost or stolen. In this case, the specific device’s access token has probably been compromised. This shouldn’t lead to a compromise of the user’s actual password. Like the above example, there should be a way for the user to log into their account and revoke access to that specific device, or worst case, all devices.

Should we, or shouldn’t we?

I don’t think there is an exact answer here. I think if done right, the two pieces are separate and stand alone. What happens to one, shouldn’t have an effect on the other. Unfortunately, that is not how things work in the real world. If you are a developer or architect designing these systems, take the time to consider these questions. Understand how your applications work, how the authentication pieces fit together, and how that will all tie together for the user experience. It may make sense to reset everything every time. On the flip side, it shouldn’t have to if designed properly. Remember the question: “What are we trying to solve?”

Application security is moving at a rapid pace, and it is great to see these types of topics coming up. As we start to raise more questions, we start to have more discussions. Share your feedback with us about this topic. Are there concerns that should be raised? Are there risks that should be considered? Share your thoughts with out on Twitter (@developsec).

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.

by Leave a Comment

Application Security and Responsibility

Who is responsible for application security within your organization? While this is something I don’t hear asked very often, when I look around the implied answer is the security team. This isn’t just limited to application security either. Look at network security. Who, in your organization, is responsible for network security? From my experience, the answer is still the security group. But is that how it should be? Is there a better way?

Security has spent a lot of effort to take and accept all of this responsibility. How often have you heard that security is the gate keeper to any production releases? Security has to test your application first. Security has to approve any vulnerabilities that may get accepted. Security has to ….

I won’t argue that the security group has a lot of responsibility when it comes to application security. However, they shouldn’t have all of it, or even a majority of it. If we take a step back for a moment, lets think about how applications are created. Applications are created by application teams which consist of app owners, business analysts, developers, testers, project managers, and business units. Yet, when there is a security risk with the application it is typically the security group under fire. The security group typically doesn’t have any ability to write or fix the application, and they shouldn’t. There is a separation, but are you sure you know where it is?

I have done a few presentations recently where I focus on getting application teams involved in security. I think it is important for organizations to think about this topic because for too long we have tried to separate the duties at the wrong spot.

The first thing I like to point out is that the application development teams are smart, really smart. They are creating complex business functions that drive most organizations. We need to harness this knowledge rather than trying to augment it with other people. You might find this surprising, but most application security tools have GUIs that anyone on your app dev teams can use with little experience. Yet, most organizations I have been into have the security group running the security tools (such as Veracode, Checkmarx, WhiteHat, Contrast, etc). This is an extra layer that just decreases the efficiency of the process.

By getting the right resources involved with some of these tools and tasks, it not only gets security closer to the source, but it also frees up the security team for other activities. Moving security into the development process increases efficiency. Rather than waiting on a scan by the security team, the app team can run the scans and get the results more quickly. Even better, they can build it into their integration process and most likely automate much of the work. This changes the security team to be reserved for the more complex security issues. It also makes the security team more scalable when they do not have to just manage tools.

I know what you are thinking.. But the application team doesn’t understand security. I will give it to you, in may organizations this is very true. But why? Here we have identified what the problem really is. Currently, security tries to throw tools at the issue and manage those tools. But the real problem is that we are not focusing on maturing the application teams. We attempt to separate security from the development lifecycle. I did a podcast on discussing current application security training for development teams.

Listen to the podcast on AppSec Training

Everyone has a responsibility for application security, but we need to put a bigger focus on the application teams and getting them involved. We cannot continue to just hurl statements about getting these teams involved over the fence. We say to implement security into the SDLC, but rarely are we defining these items. We say to educate the developers, but typically just provide offensive security testing training, 1-2 days a year. We are not taking the time to identify how they work, how their processes flow, etc. to determine how to address the problem.

Take a look at your program and really understand it. What are you currently doing? Who is performing what roles? What resources do you have and are you using them effectively? What type of training are you providing and is it effective regarding your goals?

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

by Leave a Comment

When One Testing Solution Isn’t Enough

Go to any conference, attend some webinars, or just do a search for application security testing solutions and you can quickly see the sheer number of solutions out there. As in every situation, there are some that are great and some that are not so great. With such great marketing, it is often very difficult to determine what is the best solution. All too often people are looking for that silver bullet. That one testing tool or pen testing company that will find everything. Unfortunately, that solution doesn’t exist, or I just haven’t seen it.

Application testing usually falls into two categories: Automated scanning and manual assessments. To break that down further, automated scanning is broken down into two disciplines: Static and dynamic.

Static Analysis

Static scanning means that code is scanned without running it. Here is a quick post about static analyzers. Inputs are traced through the code to see what paths are taken and determine vulnerabilities. Static scans can be efficient at finding flaws such as cross-site scripting, injection flaws, configuration issues, etc. Static scans excel at finding code issues like hard coded passwords, cryptography issues, and other items not possible through a dynamic or manual test. They still do not do very well at finding business logic flaws which can be the most devastating.

Dynamic Analysis

Dynamic scanning means that the application is scanned as it is running. Unlike a static scan, it can be very difficult to identify hard coded passwords or cryptographic issues because they are not visible to the end user. Dynamic scans do a decent job of identifying other flaws such as cross-site scripting, injection flaws, insecure cookies, and some other configuration issues to name a few. Dynamic scanners do not do a good job identifying authentication, authorization, or business logic flaws in general. Properly tuned scanners may be able to do this, but that requires extra work.

Manual Assessments

Manual assessments are mostly a manual process of analyzing source code or using the application to find security flaws. Source code review, has many advantages of the static scanning mentioned above. Penetration testing is very similar to the dynamic scanning mentioned. In both cases, the testing is done manually vs. using just an automated tool. Manual assessments (pen tests) are much more efficient at finding authentication, authorization and business logic flaw types. Of course the quality of the assessment is heavily influenced by the skill of the person doing the assessment.

Some of the big vendors have started offering all three types of assessment for their customers. The big players (White Hat Security, VeraCode, HP, etc.) all offer static, dynamic and manual assessments for your applications. And with good reason. If you have worked in an enterprise where you are required to have multiple assessments by different groups you quickly realize how nothing provides a complete solution. Each assessment paints a portion of the security picture. Items found by one may not be found by the other. In some instances you may think that two should have found the same item, but that is the nature of security.. No one finds everything.

Multiple Solutions

While you may think that it is overkill to have multiple scanning solutions or testers looking at an application, they all bring a different viewpoint and help identify different types of vulnerabilities. Sort of like an enhanced second pair of eyes. Not only can they double check the work the other has done, but in may situations they can identify different types of vulnerabilities. Not only do different solutions find different vulnerabilities, they also find them at different phases of the development lifecycle. It is common to use the static scanners in the development phase. Dynamic scanners are more commonly seen in the verification phase. Manual assessments, especially 3rd party penetration testers, are also in the verification phase, but near the end of the cycle. The closer to development a flaw is found, the quicker it is to remediate it.

The right solution is the one that fits your environment. Take the time to analyze your setup to determine the best way to implement a solution. These solutions take time and should be carefully considered.

by Leave a Comment

Password Storage Overview

Start reading the news and you are bound to read about another data breach involving user credentials. Whether you get any details about how the passwords (that were stolen) were stored, we can assume that in many of these cases that they were not well protected. Maybe they were stored in clear text (no, it can’t be true), or use weak hashes. Passwords hold the key to our access to most applications. What are you doing to help protect them?

First, lets just start with recommending that the users don’t re-use their passwords, ever. Don’t share them across applications, just don’t. Pick a password manager or some other mechanism to allow unique passwords for each application. That doesn’t mean using summer2015 for one site and summer2016 for another. Don’t have them relatable in any way.

Now that we have that out of the way, how can the applications better protect their passwords? Lets look at the storage options:

  • Clear Text
  • Encrypted
  • Hashed

Clear Text

While this may seem harmless, since the data is stored in your highly secured, super secret database, it is looked down upon. As a developer, it may seem easy, throwing a prototype together to have the password in plain text. You don’t have to worry if your storage algorithm is working properly, or if you forget your password as you are building up the feature set. It is right there in the database. While convenience may be there, this is just a bad idea. Remember that passwords should only be known by the user that created it. They should also not be shared. Take an unauthorized breach out of the picture for a moment, the password could still be viewed by certain admins of the system or database administrators. Bring a breach back into the picture, now the passwords can be easily seen by anyone with no effort. There are no excuses for storing passwords as plain text. By now, you should know better.

Encrypted

Another option commonly seen is the use of reversible encryption. With encryption, the data is unreadable, but with the right keys, it is possible to read the actual data. In this case, the real password. The encryption algorithm used can make a difference on how long it takes to reverse it if it falls into the wrong hands. Like the clear text storage, the passwords are still left exposed to certain individuals that have access to the encrypt/decrypt routines. There shouldn’t be a need to ever see the plain text version of the password again, so why store it so that it can be decrypted? Again, not recommended for strong, secure password storage.

Hashing

Hashing is process of transforming the data so that it is un-readable and not reversible. Unlike when the data is encrypted, a hashed password cannot be transformed back to the original value. To crack a hashed password you would typically run password guesses through the same hashing algorithm looking for the same result. If you find a plaintext value that creates the same hash, then you have found the password.

Depending on the hashing algorithm you use, it can be easy or very difficult to identify the password. Using MD5 with no salt is typically very easy to crack. Using a strong salt and SHA-512 may be a lot harder to crack. Using PBKDF or bcrypt, which include work factors, can be extremely difficult to crack. As you can see, not all hashing algorithms are created equally.

The Salt

The salt, mentioned earlier, is an important factor in hashing passwords to create uniqueness. First, a unique, randomly generated salt will make sure that if two users have the same password, they will not have the same hash. The salt is appended to the password, to basically create a new password, before the data is hashed. Second, a unique salt makes it more difficult for people cracking passwords because they have to regenerate hashes for all their password lists now using a new salt for each user. Generating a database of hashes based on a dictionary of passwords is known as creating a rainbow table. Makes for quicker lookups of hashes. The unique salt negates the rainbow table already generated and requires creating a new one (which can cost a lot of time).

The salt should be unique for each user, randomly generated, and of sufficient length.

The Algorithm

As I mentioned earlier, using MD5, probably not a good idea. Take the time to do some research on hashing algorithms to see which ones have collision issues or have been considered weak. SHA256 or SHA512 are better choices, obviously going with the strongest first if it is supported. As time goes on and computers get faster, algorithms start to weaken. Do your research.

Work Factor
The new standard being implemented and recommended is adding not only a salt, but a work factor to the process of hashing the password. This is done currently by using PBKDF, BCRYPT, or SCRYPT. The work factor slows the process of the hashing down. Keep in mind that hashing algorithms are fast by nature. In the example of PBKDF, iterations are added. That means that instead of just appending a salt to the password and hashing it once, it gets hashed 1,000 or 10,000 times. These iterations increase the work factor and can slow down the ability for an attacker to loop through millions of potential passwords. When comparing BCRYPT to SCRYPT, the big difference is where the work factor is. For BCRYPT, the work factor effects the CPU. For SCRYPT, the work factor is memory based.

Moving forward, you will start to see a lot more of PBKDF, BCRYPT and SCRYPT for password storage. If you are implementing these, test them out with different work factors to see what works for your environment. If 10,000 iterations is too slow on the login page, try decreasing it a little. Keep in mind that comparing a hash to verify a user’s credentials should not be happening very often, so the hit is typically on initial login only.

Conclusion

Password storage is very important in any application. Take a moment to look at how you are doing this in your apps and spread the word to help educate others on more secure ways of storing passwords. Not only could storing them incorrectly be embarrassing or harmful if they are breached, it could lead to issues with different regulatory requirements out there. For more information on storing passwords, check out OWASP’s Password Storage Cheat Sheet.

Keep in mind that if users use very common passwords, even with a strong algorithm, they can be cracked rather quickly. This is because a list of common passwords will be tried first. Creating the hash of the top 1000 passwords won’t take nearly as long as a list of a million or billion passwords.