DevelopSec

password

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

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.

by Leave a Comment

Disabling Paste for Passwords?

Passwords, while a simple concept, are one of the most complex issues in security. A majority of user authenticated systems rely on a password to verify the end user. Over the years we have seen many different recommendations for strong passwords. I have talked about this subject many times.

The complexity, while difficult to define, has gotten more difficult over time. At first, it was 8 characters with upper, lower case characters and a number or special character. The focus has shifted away from the types of characters and toward the length of the password. Common recommendations now say a strong password is at least 15 characters.

A popular recommendation from security professionals has been to use a password manager. A password manager allows you to store your passwords and protect them with a master password. The master password means that you only have to remember one long, complex password.

Using a password manager has many benefits. First, it allows you to store long, complex passwords without worrying about forgetting them. Second, it allows you to just copy and paste your passwords when signing into an application. This may not seem like that big of a deal, but many malicious programs use key loggers to steal passwords. If you paste the password in, and don’t type it, a key logger is useless. There are ways to grab data from the clipboard, but they are a less used tactic.

Some applications have started disabling the paste feature on password fields. This exists on some change password forms. The concern is that a typo entered in the password field would go unnoticed if pasted into the verify password field. The risk is the escalated customer support costs for lost passwords or account lockouts. Whether this is a valid risk is up to you. Few good reasons exist for disabling the paste feature on a password field.

The concern of recent is that the password field on the login form disables paste. In turn, this breaks many password managers. The benefits of good password management become degraded. Often, the reasons are due to a misunderstanding of how passwords are attacked.

Attackers do not rely on paste functionality for brute force attempts. In most situations, the attacker doesn’t even use the user interface for the attack. These type of attributes become useless against an attacker. Unfortunately, they only have a negative effect on the end user.

Don’t confuse disabling paste with disabling the autocomplete feature of a password field. Autocomplete is used for browsers to remember data for specific fields. While this is like what a password manager does, they are different. Autocomplete has been abused in the past and represents different issues.

Applications should be encouraging the use of password managers. They provide better password hygiene and ultimately help reduce the risk to the application. If you are making the decision to block the paste feature, prepare to answer to that decision. If the decision is well thought out and understood it will be easier to accept. Understand the reasoning behind the decision. It will generate a more enjoyable user experience.

If you experience an application that blocks your password manager, let them know. It is possible that they don’t even know it is an issue. As a customer, your opinion should matter. Stay positive and provide accurate information. Stay away from a negative stance. It will just make the business ignore your position.