Category Archives: Authentication

Response to Nielsen’s “Stop Password Masking”

17
Posted by Jason Montgomery on June 28, 2009 – 11:00 am
Filed under Authentication

I just ran across Jakob Nielsen’s Alert Box post titled Stop Password Masking and wanted to provide some feedback from a security vs. usability perspective. I have great respect for Nielsen’s contribution to the usability of the web. Back in the early days of the internet (mid 1990’s), his books were gospel at my consulting firm, ATGi.

My initial reaction to his article was ‘that’s a crazy idea’ – but after some reflection, I really felt like it was a good mental exercise to actually consider what he was saying. If I hadn’t known who Nielsen was, I probably would have dismissed his suggestion outright. Sometimes it is a good exercise to go back and review why we do the things we do – especially as it relates to information security controls. Nielsen questions the real security benefit of password masking – something I haven’t given a second thought to…well, ever.

“Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures.”

Nielsen’s probably right: It might be costing you business. The question is, how much business? Security shouldn’t be the be-all, end-all goal. It’s there to serve the organization first and foremost. Viewing the cost of security controls with respect to the function it’s protecting is the correct perspective. Enter risk analysis – risk analysis is an important process that helps determine if the cost of having (or not having) a security control mitigates threats, while not adversely affecting the business (too much). It’s about reducing risk to an acceptable level, not about 100% security. It’s a balancing act. Why not target 100% security? Well, if an organization attempted to implement absolute security, it’d go out of business – it’s just too expensive. For example, it doesn’t make sense to spend a million dollars on security solutions that will protect a web site that only earns a few thousands dollars a month.

Again, Nielsen pretty much has it right- except for the ‘true loss of security’ statement:

“The more uncertain users feel about typing passwords, the more likely they are to (a) employ overly simple passwords and/or (b) copy-paste passwords from a file on their computer. Both behaviors lead to a true loss of security.”

Next Nielsen gives a nod to the importance of security and provides an option for masks that takes security into consideration:

“Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they’re using an Internet cafe. It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win.”

Though I would go further than Nielsen: Users, unless forced, won’t use a complex password even if there is no mask, unless complexity is enforced. If complexity is enforced, a non-masked textbox would certainly help the user meet complexity requirements more easily – which is probably what Nielsen means. Likewise, when presented with an option for masked password or not masked – users typically chose convenience over security so in most cases I would want to default the option to show the mask.

Using simple passwords or ‘copy-paste passwords’ is not NECESSARILY a ‘true loss of security’, but the devil’s in the details.

The loss of security for ‘copy-paste password’ scenarios (which assumes users are storing passwords locally in a file of some sort) assumes a local computer or local network compromise. If so, he’s correct – the gig is up, but that’s not necessarily a true loss of security…well, it IS for the ONE compromised user (or network of users) – but not for all the users of that web site. The main reason we insist on password complexity is increase the keyspace of a password which helps stop brute force and dictionary attacks that originate from attackers “out there” who don’t require access to the user’s computer to begin with. The attacker attempts to find a collision with a password for a known account through a dictionary attack and if they have more time, a brute force attack. Additionally, Password Manager Software (KeePass or Password Safe) will encrypt password stores locally and even associate them automatically with the appropriate web site. Though I suspect the use of password management tools is the exception, not the rule.

As for users choosing too simple of a password: If the site allows users to pick an insecure password, that’s already a failure of the site. But it’s possible to have both a simple password as well as a secure password. Contrary to common belief, good passwords don’t necessarily have to contain symbols, digits, upper and lower case characters.  The reason these complexity requirements were introduced was to protect against brute force attacks as well as dictionary attacks on shorter passwords. Humans have a natural propensity to use simple dictionary words that are easy to remember – such as names, meaningful numbers/dates, pet names, etc., as passwords – hackers take advantage of this seemingly reasonable behavior and use it to their advantage. By adding complexity – that is, the symbols, digits, upper/lower characters – this makes the dictionary attacks more expensive (time consuming) to the attacker since each time we increase the length and the number of possible combinations, this increases the keyspace of the password. So if instead of increasing the combinations, instead increase the password length and use a simple phrase or sentence as the password. These long passwords with less complexity are called a passphrase. Dictionary attacks are useless against passphrases since they are not made up of a dictionary words. By increasing the keyspace by requiring a minimum of 30 normal alpha characters (including spaces and maybe an optional period or comma) we’ve also made it very expensive (time consuming) to brute force. So my passphrase could be “my name is jason and this is my password.” – this is 40+ characters and no more difficult to remember than a dictionary word – but it’s not found in any dictionary so it will stop dictionary attacks and it has a very large keyspace so it will slow down brute force attacks considerably, making them impractical.

A true loss of security? It doesn’t have to be – at least not for the organization. However, I can already hear Nielsen groaning on the usability of typing 40+ characters blindly into a masked password box. :) This is where two-factor authentication can solve the problem of passwords and passphrases completely – which can really improve usability.

Nielsen’s observation about typing in passwords on mobile devices makes the most sense to me. It is more difficult to shoulder surf someone on a mobile device. It’s also much more difficult to type a password with complexity requirements correctly on a mobile device unless you’re a profession texter. There’s probably not as much risk here by unmasking, so we could probably forgo the mask on mobile devices.   It’s trivial to detect mobile devices, so simple choosing to use a non-masked text box in these situations would be okay for most situations.

But before we go running to dump the masked password box, there’s a few questions we must ask – what are the unintended side-effects of this change? Are there good workarounds to these issues? How much education do developers need to implement this? Remember, we’ve known about and had solutions to SQL Injection for over 10 years now, yet there’s still a constant barrage of developers who still don’t know how to protect against this properly – this is an education problem.

Here’s my initial pass of issues I see by displaying (not masking) passwords to end users:

  1. Accidental observation - in the enterprise there are many opportunities where someone else will be at your computer and may accidentally see your password. A great example of this is when using older command line programs that required the password as an argument. I’ve on occasion seen others’ passwords and others have seen mine.
  2. Autocomplete Web Forms – Modern web browsers now remember and prefill text boxes with previously used input. This is a usability feature at the expense of privacy/security. This means the password is stored not only  in the OS somewhere for retrieval later, but will pop-up anytime a user starts typing in the textbox. This has the most serious implications on public systems. Developers, if aware of the issue, can prevent this data from being stored by setting the autocomplete attribute to off in the form. This is a developer educational issue.
  3. Compliance – I don’t want to get into all the details here, but bad password management practices can cause compliance issues. Lack of compliance can affect business. Not masking passwords may be in violation of certain security requirements for the organization.
  4. Nuanced Issues - there are potentially a variety of issues for every masked password box implementation – for instance, in .NET for Windows Applications, there’s a way to encrypt passwords in memory (using the System.Security.SecureString object). Displaying the characters in the textbox first may completely defeat the security provided by this control.
  5. What else? - Are there other issues here?

Certainly a usability guy isn’t going to or need to understand all the ins and outs of security, just as I won’t understand the broad range of usability issues.  We should be cautious when recommending broad sweeping changes that affect security. Additionally, us security folks should not resist usability improvements that affect security just because we’ve always done things another way – we should have a good solid business reasons why we do things the way we do. We need to make sure changes can continue to protect our customers/users. Changes to security functionality can often cause unintended side-effects that can put us at risk.  Not that there isn’t a good solution – to me, the most IDEAL solution to improve usability would be to dump passwords as the authentication mechanism all together – there are some partial solutions to this problem, but Identification is a difficult problem to solve – we’re definitely not there yet.  Personally, I look forward to the day where authentication, passwords, and password management all become a thing of the past, but that’s a completely different conversation.

Session Attacks and ASP.NET – Part 2

16
Posted by Jason Montgomery on June 24, 2009 – 11:00 am
Filed under .Net, Authentication, Sessions

In Session Attacks and ASP.NET – Part 1, I introduced one type of attack against the session called Session Fixation as well as ASP.NET’s session architecture and authentication architecture.  In this post, I’ll delve into a couple specific attack scenarios,  cover risk reduction, and countermeasures.

Attack Scenario: ASP.NET Session with Forms Authentication

So understanding the decoupled nature of ASP.NET’s session management from the authentication mechanisms outlined in the previous post, let’s walk through two different session fixation attempts with Forms Authentication and session management.

Scenario 1: Attacker does not have a Forms Authentication Account

  1. Attacker browses target web site and fixates a session
  2. Attacker traps victim to use the fixated session
  3. Victim logs in using Forms Authentication and moves to areas of the site protected by forms authorization
  4. Attacker cannot pursue because he has not authenticated.

Not a big deal – UNLESS session reveals information or makes decisions outside of an authenticated area (within the same Application of course), which is very plausible.  If the programmer happened to use Forms authentication and then strictly uses Session to make security decisions (no IPrincipal role authorization with Principal Permissions or authorization sections in the web.config), some real issues can result. Since session is decoupled from authentication, any area not controlled by authorization that shows session information can be exploited by the attacker.

Scenario 2: Attacker has their own Forms Authentication account

  1. Attacker browses to web site and fixates a session.
  2. Attacker Logs in to site using Forms Authentication.
  3. Attacker traps victim to use the fixated session.
  4. Victim logs in and moves to areas of the site protected by forms authorization.
  5. Attacker, still logged in under their own credentials, has the victim’s session.

This was odd and even surprising to me at first when I actually pulled it off, but it works because Authentication is completely decoupled from the Session Management – they are tracked separately (different cookies, remember?).

Consider next that session fixation isn’t the only problem – any session attack can take advantage of the decoupled nature of ASP.NET Session management and Authentication. If the attacker can fixate, hijack, or steal a Session from the victim, this type of attack will succeed no matter if the web site uses Forms Authentication, Windows Authentication, Client Certificates, etc. It doesn’t matter. As long as the attacker also has an account in the system as well as the victim’s Session ID, they can take over the session…that is unless the developer adds some additional checks – more on this later.

The take-away point is this – out of the box, authentication within ASP.NET does not provide protection from session attacks . This means that ASP.NET’s session implementation is not concerned with the security of session as it relates to authentication. Session is a feature that developers can provide to any user, authenticated or not.

This means that developers must understand the implications of the asymmetrical relationship between session and authentication and protect against it or the ASP.NET sites will be vulnerable to various session attacks.

Countermeasures

The session infrastructure in ASP.NET is okay, but not as robust from a security perspective as it could (or should be, in my opinion). The ASP.NET session keyspace is decent – 120 bytes with good entropy, and a default 20 minute sliding window for expiration (30 minutes for Forms Authentication).

Comparing the configuration features APPLICABLE for securing the cookie for Forms Authentication vs Session – it’s clear great care was taken to provide a broad range of options to protect the Forms Authentication Ticket cookie.  The Session configuration options pale in comparison.

Web.Config Option Session Cookie Forms Cookie
Cookieless + +
Timeout + +
Require SSL - +
Cookie Domain - +
Cookie Path - +
Disable Sliding Expiration - +

Table – 1: Forms vs. Session Options

While not an “apples to apples” comparison (since session and authentication are different animals), the point I want to illustrate is this is the Cookie Protection features for both should be similarly strong.

Cookieless – should be avoided for both Forms Authentication and Session at all costs. It’s just too easy to hijack a session with the ID in the URL unless you really aren’t concerned so much with security.

Timeout – This timeout is typically a sliding value – so as long as the user is active on the site, the cookie remains valid (session OR authentication).

Require SSL – This requires that SSL be enabled for the Cookie to be transmitted.   Forms authentication allows this, Session does not (though you can certainly do this programmatically which is a good idea if your site security should requires a higher level of protection).

Cookie Domain – This allows you to override the default domain on the cookie.

Cookie Path – This allows the cookie to be used for certain paths.  This is important, as it can limit the area of the site where the cookie is valid. Forms Authentication allows this, Session does not, but perhaps could be set programmatically (not sure what the side effects would be, since ASP.NET may attempt to create a new cookie if the session object is used outside the set path).  This could potentially help add protection to the session if this cookie path is to set to only authorized areas of the site.

Sliding Expiration – By setting this to false, Forms Authentication allows an absolute expiration of the cookie. For example, you can force expiration every 10 minutes, whether the user is active or not. With session, there’s no way to force expiration.

While none of the above features are a slam-dunk 100% mitigation, they all certainly reduce risk. If ASP.NET was able to allow the Authentication Modules to collaborate with the Session module internally in certain situations through configuration, that would go a long way to add some protections in ASP.NET against session attacks.

So then the BEST solution, would be for ASP.NET to issue a NEW session ID after any successful authentication, and then transfer the session over to the new Session ID. That way if the attacker has a victim’s session, once they log in, it will vaporize from the attackers perspective. Or better yet, NEVER deliver session until the user logs in. There’s some code that looks like it may allow a new session ID to be distributed on login in KB899918 [4], but it’s not presented in any useful or reusable way for the masses.  The code is incredibly long and difficult to follow due to the nuances of setting cookies, allowing redirects, etc.  The language of the KB article is also not very clear.

A way to mitigate (and even detect) this attack now for Forms Authentication or any other authentication mechanism, is to simply store something related to the Authentication in Session. Then on each subsequent request, make sure they match. This couples the authentication mechanism to session management – if they don’t match – then a session attack occurred (or something’s out of sync programmatically). So for Forms Authentication, you would store the Forms Authentication Ticket Name in Session. This value is stored in the forms cookie which is encrypted and persisted to the client after authentication and can be configured to be transmitted only over SSL/TLS.

Once you couple session and the authentication mechanism together and than configure Forms authentication properly, you can provide adequate session protection. Another important point – don’t use Session anywhere outside of the authenticated areas of your site.

What Should Be Done?

As noted in Part 1, Microsoft closed a Bug submitted for this issue.  To be fair, Microsoft has worked hard to improve the security of their code through the Security Development Lifecycle.  To me, adding this feature in future versions of .NET is a no-brainer and right in step with their current security approach.

So back to the original question:

Should ASP.NET improve the session management module in ASP.NET to allow for more secure configuration by coupling it with Authentication mechanisms in ASP.NET?

I guess it depends on your perspective. The fundamental question is should Session be coupled to an authentication mechanism? This will depend on what the web site is doing and the level of acceptable risk, etc. If so, the session HTTP Module would need to be aware of the other Authentication HTTP Modules (which sort of breaks the pattern). Another option would be for each HTTP Module to implement its’ own or share a common session manager…of course there are  situations when you might want to use session without requiring authentication – should SSL, Path and Domain be configurable in the web.config for <sessionState>?  Or should things remain as they are, and should those concerned with the issue just fix it in code as described above?

Should the onus be on the developer to know about this and mitigate it in code? Without having the feature in the framework and in the MSDN documentation, most developers will remain in the dark about these issue. Remember, we’re still dealing heavily with SQL Injection and XSS issues in web sites…issues that we have known about how to protect against for years.

The INFOSEC community will almost always recommend you move a session after Authentication, meaning they have to be tied together (if the risk profile is such that you need that level of protection) – ASP.NET’s is decoupled – there-in lies the issue…

Love to hear your thoughts as well!

References

Here’s what a somewhat brief Google turned up for me on Session Fixation and ASP.NET – nothing quite seemed to address the issues described above:

[1] Threats and Countermeasures for Web Services
http://msdn.microsoft.com/en-us/library/cc949001.aspx
[2] MSDN Magazine March 2009 Security Briefs
Reveals the perspective from MS that the only attack is via cookieless Sessions (inaccurate):
http://msdn.microsoft.com/en-us/magazine/dd458793.aspx
[3] MS Employee Blog
Reveals assumption that cookie-less session is where the problems is (inaccurate):
http://blogs.msdn.com/paraga/archive/2005/12/10/502345.aspx
[4] How and Why SessionID’s are reused in ASP.NET (.NET 1.1)
http://support.microsoft.com/kb/899918
[5] JoelOnSoftware Forum Discussion on Session Fixation:
http://discuss.joelonsoftware.com/default.asp?dotnet.12.484800.5

How can I tell if my password is encrypted?

7
Posted by Johannes Ullrich on May 29, 2009 – 2:28 am
Filed under Authentication

For most websites, we don’t have the source code available. As a user, we more or less trust the site is doing “the right thing”, or well, we just use a throw away password that we accept to be compromised.

Sometimes, it is obvious. For example the site is sending you your password in the clear. Other times, it is less obvious. Usually, if a site is imposing limits to your password, like the length or it doesn’t allow certain characters, you can guess that your password will be stored in the clear.

The reason is simple: If the password is hashed, then it doesn’t matter how long it is, or what characters it uses. It will always end up as a fixed length hex string. SHA1 creates 20 bytes (40 hex characters), MD5 creates 16 bytes (32 hex characters). The one exception may be if the code uses a database function to do the hash. For example some pseudo code:

$hash=md5($password);
update users set passwordhash='$hash'

In this case, it doesn’t matter if the password includes a single quote or whatever. However, it could matter in the following snippet:

update users set passwordhash=sha1($password)

(Needless to say, I wouldn’t use dynamic SQL like this, but this is the topic of another blog post).

The length of the password is typically limited, if stored unencrypted, because the database table was defined with a certainl length for this field. Maybe even worse: If you are not told about it, your password maybe truncated “silently”.

[digg=http://digg.com/security/How_to_tell_if_a_website_encrypts_your_password]