Troy Hunt's Blog

Everything you ever wanted to know about building a secure password reset feature

2012-05-22T08:26:00.001+10:00

Recently I’ve had a couple of opportunities to think again about how a secure password reset function should operate, firstly whilst building this functionality into ASafaWeb and secondly when giving some direction for someone else doing a similar thing. In that second instance, I wanted to point them to a canonical resource on the ins and outs of securely implementing a reset function. Problem is though, there isn’t one, at least not covering everything I believe is important. So here it is.

You see, the world of forgotten passwords is actually a little murky. There are plenty of different perfectly legitimate angles and a bunch of pretty bad ones as well. Chances are you’ve experienced each many times as an end user so let me try and draw on some of these examples to see who’s doing it well, who’s not and what you need to focus on to get it right in your app.

Password storage: hashing, encrypting and (gasp!) plain text

We can’t talk about what to do with forgotten passwords until we talk about how they’re stored in the first place. We’ve got three primary ways in which passwords will usually be persisted in a database:

Plain text. You have a password column and it sits there in the clear.
Encrypted. Usually using symmetric encryption (the one key to both encrypt and decrypt), the encrypted password also sits there in a single column.
Hashed. A one-way process (you can hash but not un-hash), the password is hopefully accompanied by a salt, each of which sit in their own columns.

Let’s just get that first one out of the way quickly; never store passwords in plain text! Ever. One little injection vulnerability, one sloppy backup or any one of a dozen other simple little slipups and it’s game over, all your passwords – sorry – all your customer’s passwords are in the public domain. Which, of course, means a better than average chance that all their passwords for all their other accounts on totally independent systems are in the public domain. And it’s your fault.

Encryption is better, but still flawed. The problem with encryption is decryption; it’s possible to take those crazy looking ciphers and convert them back to plain text and once that happens, you’re back with readable passwords. How does this happen? A little flaw sneaks into the code which decrypts the password and makes it publicly accessible – that’s one way. The machine the encrypted data sits on gets owned – that’s another way. Another way again is that the database backup is obtained and someone also gets their hands on the encryption key, which is frequently pretty poorly managed.

Which leads us with hashing. The idea of hashing is that it only goes one way; the only way you can ever match a password from a user with its hashed partner is to hash the input and compare it. In order to prevent attacks from tools such as rainbow tables, we add randomness to the process by using a salt (check out my post on cryptographic storage for the full picture). The bottom line is that when done properly, we can have a high degree of confidence that hashed passwords should never again become plain text (I’ll save the respective merits of various hashing algorithms for a later post).

A quick argument about hashing versus encrypting; the only reason you should ever need to encrypt and not hash is when you want to see the plain text password and you should never want to see this, at least not in a typical website scenario. If you do, you’re probably doing something else wrong!

Always reset, never remind

Ever been asked to build a password reminder function? Take a step back and work through that request in reverse; why is a “reminder” needed? Because the user has forgotten their password. What are we really trying to do? Help them log back in again.

I get it – the word “reminder” is (often) used colloquially – but what we’re really setting out to do here is to securely help the user get back online. Because we want to be secure, there are two reasons why a reminder (i.e. actually sending them their password) won’t work:

Email is an insecure channel. In the same way as we wouldn’t send anything sensitive over HTTP (we’d use HTTPS), the transport layer for email is not secure. Actually, it’s much worse than just sending info over an insecure transport protocol as your mail often persists in storage, is accessible by system admins, is readily forwarded and redistributed, is accessed by malware and so on and so forth. Unencrypted mail is an extremely insecure channel.
You shouldn’t have access to the password anyway. Go back to that previous section about storage – all you should have is the password hash (with a nice strong salt), which means there’s no way you can pull the password back out and email it around anyway.

Let me demonstrate the problem courtesy of usoutdoor.com: Here’s a typical login page:

Clearly the first problem is that the logon page hasn’t been loaded over HTTPS, but then they’ve also gone and offered to “Send Password”. Now maybe that’s an example of the earlier mentioned colloquial use of the term, let’s dig a big further and see what happens:

Not looking much better, unfortunately and the email confirms the problem:

So this tells us a couple of important things about usoutdoor.com:

They’re not hashing the password. At best they’re encrypting it but they’re quite possibly just storing it in the clear; we have no evidence to the contrary.
They’re sending a persistent password – one we can go back and keep using over and over – via an insecure channel.

Now that we’re clear on that, the trick becomes how we go about ensuring the reset process happens securely and the first step to doing that is to establish that the requestor is actually authorised to perform the reset. In other words, we need a bit of identity verification but before we do that, let’s look at what happens when identity is confirmed without first verifying the requestor is actually the owner of the account.

Username enumeration and the impact on anonymity

Here’s a problem best illustrated graphically. The problem is this:

You see that? Focus now – we’re looking at the message which says “There is no user registered with this email address”. The problem, of course, is when a site like this confirms there is a user registered with that email address. Bingo – you’ve just uncovered your husband’s / boss’s / neighbour’s porn fetish!

Of course porn is a bit of a canonical example of where privacy is important, but the risk of matching an individual to a particular website goes beyond a potentially embarrassing disclosure such as this. One risk that arises is one of social engineering; once an attacker can match a person to a service, they have a piece of information that they can begin leveraging. For example, they may contact the individual whilst posing as a representative of the website and ask for additional information in a spearphishing attack.

This practice also opens up the risk of “username enumeration” where an entire collection of usernames or email addresses can be validated for existence on the website simply by batching requests and looking at the responses. Got a list of everyone’s email address from the office and a few spare minutes to do some scripting? You can see the problem!

So what’s the alternative? Well it’s actually quite easy and Entropay executes it very well:

What Entropay have done here is disclosed absolutely nothing about the existence of the email address in their system to someone who doesn’t own that address. If you do own that address and it doesn’t exist in their system, you get a nice little email like this:

Of course there may be legitimate use cases where someone either thinks they registered at a website – but didn’t – or they did but with a different email address. The response above deals with both those scenarios very nicely. Obviously if the address was valid you’d get an email which would facilitate a password reset.

The thing about the approach taken by Entropay is that identity verification happens via email before any sort of online verification. One approach some sites take is to prompt the user with a secret question (more on this shortly) before the reset can begin but of course the problem with this is that you have to answer the question along with providing some form of identification (either email or username) which then makes it almost impossible to respond intuitively without disclosing the existence of the account to an anonymous user.

There is a slight usability tax to pay using this approach and it’s that there is no immediate feedback when an invalid account is attempted to be reset. Of course this is the whole reason why we’re sending an email in the first place but from a legitimate end user perspective, if they’ve entered an invalid address then the first they’re going to know about it is when the email arrives. This may cause some frustration on their behalf, but it’s a small trade-off for an infrequent process.

Just one more slightly tangential note on this while I’m here – log on facilities which disclose the validity of the username or email address have exactly the same problem. Always defer to the user with a “You username and password combination is invalid” message as opposed to explicitly confirming the existence of an identity (i.e. your username was correct but your password was incorrect).

Sending a reset password versus sending a reset URL

The next concept we have to deal with relates to how the password is reset and there are two common approaches:

Generate a new password on the server and email it
Email a unique URL which will facilitate a reset process

Despite plenty of guidance to the contrary, the first point is really not where we want to be. The problem with doing this is that it means a persistent password – one you can go back with and use any time – has now been sent over an insecure channel and resides in your inbox. Chances are your inbox syncs to your mobile device(s) and possibly to your mail client plus it may reside online in your web-based mail service for who knows how long. The point is that your mailbox should not be considered a long term secure storage facility.

But there’s one more big problem with the first approach in that it makes the malicious lockout of an account dead simple. If I know the email address of someone who owns an account at a website then I can lock them out of it whenever I please simply by resetting their password; it’s denial of service attack served up on a silver platter! This is why a reset is something that should only happen after successfully verifying the right of the requestor to do so.

When we talk about a reset URL, we’re talking about a website address which is unique to this specific instance of the reset process. Obviously it must be random and not something guessable nor should it contain any external references to the account for which it’s facilitating the reset. For example, a reset URL should not simply be a path such as “Reset/?username=JohnSmith”.

What we want to do is create a unique token which can be sent in an email as part of the reset URL then matched back to a record on the server alongside the user’s account thus confirming the email account owner is indeed the one attempting to reset the password. For example, the token may be “3ce7854015cd38c862cb9e14a1ae552b” and is stored in a table alongside the ID of the user performing the reset and the time at which the token was generated (more on that in a moment). When the email is sent out, it contains a URL such as “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” and when the user loads this, the page checks for the existence of the token and consequently confirms the identity of the user and allows the password to be changed.

Now of course because the process above is going to (hopefully) give the user the ability to create a new password, we need to ensure that the URL is loaded over HTTPS. No, posting to HTTPS is not enough, that URL with the token must implement transport layer security so that the new password form cannot be MITM’d and the password the user creates is sent back over a secure connection.

The other thing we want to do with a reset URL is to time limit the token so that the reset process must be completed within a certain duration, say within an hour. What this does is ensures that the window for which the reset can occur is kept to a minimum so should anyone obtain the reset URL they can only action it within a very small window. Of course an attacker can always go and begin the reset process again but they’ll then need to obtain another unique reset URL.

Finally, we want to ensure that this is a one-time process. Once the reset process is complete, the token should be deleted so that the reset URL is no longer functional. As with the previous point, this is to ensure an attacker has a very limited window in which they can abuse the reset URL. Plus of course the token is no longer required if the reset process has completed successfully.

Some of these steps may seem a little excessive, but they don’t detract at all from the usability of the feature and they do add to the security, albeit in circumstances we’d hope would be uncommon. In 99% of cases, the user is going to action the reset within a very short period and they’re not going to reset the password again in the immediate future.

The role of CAPTCHA

Ah CAPTCHA, the security measure we all love to hate! In fact CAPTCHA isn’t so much a security measure as it is an identification measure – are you a human or are you a robot (or an automated script, as it may be). The intention is to avoid the automated submission of forms which of course could be used as an attempt to breach security. In a password reset context, a CAPTCHA means the reset feature can’t be brute-forced either to spam an individual or to attempt to identify the existence of accounts (which of course won’t be possible if you’ve followed the guidance in the identity verification section earlier on).

Of course CAPTCHA itself is not perfect; there are numerous precedents of “breaking” it programmatically and achieving reasonable success rates in the range of 60-70%. Then you have the approach I demonstrated in my post about Breaking CAPTCHA with automated humans where you could pay humans a fraction of a cent to solve each CAPTCHA and get a 94% success rate. So it has faults, but it does (slightly) raise the barrier to entry.

Let’s take a look at PayPal’s approach:

In this case, the reset process simply can’t begin until the CAPTCHA is solved so in theory, you can’t automate the process. In theory.

For most web applications though, this is going to be overkill and will definitely pose a usability overhead – people simply don’t like CAPTCHAs! A CAPTCHA is also the sort of thing you can retrofit later on if it’s required. If the service begins to get abused (this is where logging is important – more on that soon), dropping in a CAPTCHA is a piece of cake.

Secret questions and answers

With what we’ve looked at so far, we’ve been able to reset the password simply by having control of the email account. I say “simply”, but of course illegally gaining access to someone’s email account should be a hard thing. But it isn’t always.

Actually, that link above is about Sarah Palin having her Yahoo! account hacked and it serves a couple of purposes; firstly, it illustrates how easily (some) email accounts can be breached and secondly, it shows how poor secret questions can be abused – but we’ll come back to that one.

The problem with password resets which are 100% dependent on email is that the account integrity of the site you’re trying to reset the password on then becomes 100% dependent on the email account integrity. Whoever has access to your email now has access to any account that can be reset purely by receiving an email. For these accounts, your email is truly the skeleton key to your online life.

One way of mitigating this risk is to implement a secret question and answer pattern. You’ve no doubt seen this before; choose a question for which only you should know the answer then you may be prompted for this before you’re able to perform a password reset. It gives that bit of additional assurance that the person attempting to perform the reset is indeed the owner of the account.

Getting back to Sarah Palin, what went wrong here is that the answers to her secret question(s) were easily discoverable. Particularly once you have a highly public profile, information such as mother’s maiden name, education history or where someone might have lived in the past really isn’t that secret. In fact much of this can easily be discovered for almost anyone. And so it was with Sarah:

The hacker, David Kernell, had obtained access to Palin's account by looking up biographical details such as her high school and birthdate and using Yahoo!'s account recovery for forgotten passwords.

This is primarily a design flaw on Yahoo!’s part; by providing or allowing such basic questions they fundamentally undermined the value of the secret question and indeed undermined the security of their system. Of course password resets of an email account are always going to be trickier because you may well not be able to validate ownership by sending the account holder an email (short of having a secondary address on file), but fortunately there aren’t a lot of use-cases these days for building such a system.

Getting back to secret questions, one option is to allow the user to self-construct their own questions. The problem with this though is that you end up with either painfully obvious questions:

What colour is the sky?

Questions which can put people in an uncomfortable position when a human uses the secret question for verification (such as in a call centre):

Who did I sleep with at the Christmas party?

Or frankly stupid questions:

How do you spell “password”?

When it comes to secret questions, people need to be saved from themselves! In other words, the site itself should define the secret question, or rather define a series of secret questions from which the user can choose. And not just choose one either; ideally, the user should define two or more secret questions at the time of account registration which can then be used as a second channel of identity verification. Having multiple questions adds a higher degree of confidence to the verification process plus gives you opportunity to add randomness (not always show the same question) plus provides a bit of redundancy should someone legitimate forget an answer.

So what makes a good secret question? There are a few different factors:

It should be concise – the question is to the point and unambiguous
The answer is specific – you don’t want a question which could be answered in different ways by the same person
The possible answers must be diverse – a question about someone’s favourite colour would result in a small subset of possible answers
Answer discovery should be hard – if you can readily find the answer for anyone (think high-profile people) then it’s no good
The answer must be constant over time – asking for someone’s favourite movie may result in a different answer a year from now

As it happens, there’s a website dedicated to good security questions which, unsurprisingly, is at GoodSecurityQuestions.com. Some of these seem quite good, others fail some of the tests above, particularly the “discovery” test.

Let me walk you through how PayPal implements their secret questions and in particular, the extent they go verify identities. Earlier on we saw the page to begin the process (the one with the CAPTCHA), here’s what happens once you drop in an email address and solve the CAPTCHA:

Which results in an email like this:

So far this is all very normal, but here’s what’s behind that reset URL:

Right, so now the secret questions come into play. Actually, PayPal also allows password reset by verifying a credit card number so there’s an additional channel there which many sites won’t have access to. I simply cannot change my password without answering both secret questions (or knowing the card number). Even if someone takes over my email account, they cannot reset the PayPal account unless they know some intimate information about me. What sort of information? Here are the secret question options PayPal gives you:

The question about the school and the hospital might be a bit dubious on the “discoverability” test but the others aren’t too bad. But to add to the security, PayPal requires further verification of identity to change secret question answers:

PayPal is a pretty utopian example of a secure password reset: they implement CAPTCHA to mitigate against brute force, require two secret questions and then require another form of identify verification altogether just to change the answers – and that’s after you’re already logged in. Of course we’d expect this from PayPal; they’re a financial institution and they handle lots of money. This doesn’t mean every password reset process should follow these steps – that’s overkill in most cases – but it’s a good reference point for when security is serious business.

One nice thing about the secret question approach is that if you haven’t implemented it from day one, it can be a later addition if the risk profile as the asset being protected demand it. A good case in point is Apple who just recently rolled out this mechanism. When I went to update an app on iPad the other day, I was prompted with the following:

This then presented me with a screen to define several secret question and answer pairs and a rescue email:

As with PayPal, the questions are pre-determined and some of them are actually pretty good:

Each of the three question and answer pairs presents a different set of possible questions so there are quite a number of different ways an account can be configured.

The other thing to consider with the answer component of the secret question is storage. Sitting it in the DB is plain text poses similar risks to doing the same with the password, namely that a database disclosure will immediately reveal the value and not only put the app at risk but quite possibly other totally unrelated apps which depend on the same secret questions (it’s the Acai berry conundrum all over again). Secure hashing (a strong algorithm and cryptographically random salt) is an option, however unlike most password scenarios, there may be a legitimate reason to make the answer visible in plain text. A typical scenario is when a human operator is verifying an identity over the telephone. Now of course hashing is still feasible (the operator can simply enter the answer the customer provides), but at worst, the secret answer should have some level of cryptographic storage, even if it’s just symmetric encryption. Bottom line: treat secret answers as secret!

Just one more thing on secret questions and answers – they’re more vulnerable to social engineering. Attempting to directly elicit an account’s password out of someone is one thing, striking up a conversation with them about their education history (a common secret question) is quite another. In fact you can quite legitimately have a discussion with someone about many aspects of their life which could constitute the secret question and not arouse suspicion. Of course the very intention of a secret question is that it relates to someone’s life experiences so that it is memorable and therein lies the problem – people like to talk about their life experiences! There’s not a lot you can do about that other than to ensure that the available secret questions are less likely to be the kind that could be socially engineered out of someone.

Two factor authentication

Everything you’ve read up until now has involved verifying an identity based on things the requestor knows. They know their email address, they know how to access their email (i.e. they know their email address password) and they know the answers to some secret questions. “Knowledge” – or something you know – is considered to be one factor of authentication, the other two common factors are something you have, such as a physical device, and something you are such as your finger prints or retina.

In most scenarios it’s a bit infeasible to perform biologic validation, particularly when we’re talking about web application security, so it’s usually the second attribute – something you have – which is used in two factor authentication (2FA). One common approach to this second factor is to use a physical token such as an RSA SecurID:

Common uses for a physical token include authenticating to corporate VPNs and financial services. The premise involves authenticating to a service using both a password and the code on the token (which rotates frequently) combined with a PIN. In theory, an attacker must know the password, have the token and also know the token PIN in order to identify themself. In a password reset scenario the password is obviously not known, but possession of the token can be used to verify the legitimacy of the account claim. Of course like any security implementation, it’s not fool proof, but certainly it raises the bar to entry.

One of the main problems with this approach is the cost and logistics of implementation; we’re talking distributing physical devices to every customer and educating them about a new process. Then of course they actually need to have the device on them when they need it which isn’t always the case with a physical token. Another option is to implement the second factor of authentication using SMS which in a 2FA scenario can be used as validation that the person instrumenting the reset process actually has the mobile phone of the account holder. Here’s what Google does:

Now you also need to have 2-step verification enabled, but what this means is that the next time you need to reset your password, your mobile phone can become your second factor of authentication. Let me demonstrate how to initiate this this via my iPhone, for reasons which will soon become apparent:

After identifying the email address of the account, Google recognises that 2FA has been enabled and we’re able to reset the account via verification that can be SMS’d to the account holders mobile phone:

We now need to elect to begin the reset process:

This sends an email off to the registered address:

The email then contains a reset URL:

When the reset URL is accessed, the SMS is sent and the website prompts for it to be entered:

Here’s that SMS:

After it’s entered into the browser, we’re back into classic password reset territory:

This might seem a little verbose – and it is (I think that 3rd iPhone screen could go) – but it does validate that the person conducting the reset has access to both the email address and the account holder’s mobile phone. This could well be 9 times more secure than an email only channel for password resets, but there’s a problem…

The problem has to do with smart phones. The device below can verify only one factor of authentication – it can receive an SMS but not an email:

However this device can receive an SMS and receive a reset email:

The problem is that when we view email as the first factor of authentication then we view either SMS (or even an app generating tokens) as the second, these days that’s all bundled up into the one device. Of course what this means is that if someone gets their hands on your smartphone then all that convenience suddenly means you’re back to one channel; that second factor of “something you have” means you also have the first factor. And all of that’s behind a single 4 digit PIN – if the phone has even has a PIN in the first place and has been locked.

Yes, 2FA as Google has implemented it certainly provides additional security, but it’s not fool proof and it’s certainly not dependent on two entirely autonomous channels.

Resetting via username versus resetting via email address

Should you allow a reset only via email address? Or should you be able to reset via username too? The problem with resetting via username is that there’s no way to notify the user if the username was invalid that doesn’t disclose the fact that someone else may have an account with that name. In the previous section, a reset via email ensured the legitimate owner of that email could always receive feedback without disclosing its existence in the system publicly. You can’t do that with just a username.

So the short answer is: email only. If you’re trying to do it with username then you’re going to have cases where the user is left wondering what’s going on or you’re disclosing the existence of accounts. Yes, it’s only a username and not an email address and yes, anybody can choose any (available) username they’d like but there’s still a good chance you’re going to implicitly disclose account holders due to the propensity of username reuse.

So what happens if someone forgets their username? Assuming the username isn’t already the email address (which is often the case), then the process is similar to how a password reset begins – enter the email address then send a message to that address without disclosing its existence. The only difference is that this time around, the message simply contains the username rather than a password reset URL. Either that or the email explains that there is no account on file for that address.

Identity verification and email addresses accuracy

A key aspect of password resets – arguably the key aspect – is verifying the identity of the person attempting to perform the reset. Is this indeed the legitimate owner of the account? Or someone attempting to either break into it or inconvenience the owner?

Email is clearly the most convenient, most ubiquitous channel for verifying an identity. It’s not fool proof and there are many cases where simply being able to receive emails at the account holder’s address is not sufficient if a high degree of identity confidence is required (hence the use of 2FA), but it’s almost always the starting point of a reset process.

One thing that’s critical if email is going to play a role is confidence that the email address is actually correct to begin with. If someone has a character wrong then clearly resets aren’t going to get through. An email verification process at the point of registration is a sure way of ensuring the address is correct. We’ve all seen this in practice; you register, an email is sent to you with a unique URL you need to click through to which therefore verifies you are indeed the holder of that email account. Not being able to log on until this process is complete ensures there is motivation to validate the email address.

As with many aspects of security, this model imposes a usability overhead in exchange for giving us a greater degree of security in terms of confidence in the user’s identity. This might be fine for a site where the user places a high value on being able to successfully register and is happy to add one more step to the process (paid services, banking, etc.) but it’s the sort of thing they may well just walk away from if they perceive the account as being a “throwaway” such as simply a means of commenting on a post.

Identifying who initiated the reset process

Clearly there is scope for abusing the password reset feature and evildoers can do so in a number of different ways. One very easy trick we can use to help verify the source of the request – one which usually works – is to attach the IP address of the requestor to the reset email. What this does is equips the recipient with some information to identify the source of the request.

Here’s an example from the reset feature I’m presently building into ASafaWeb:

That “find out more” link takes you off to ip-address.com which will give you things like the location and organisation of the requestor:

Now of course anyone wanting to hide their identity has numerous ways of obfuscating their real IP address, but this is a neat little way to put some form of identity to the requestor and in most cases, it will give you a good idea of who was behind the reset request.

Notifying a change via email

One theme which has pervaded across this post is communication; tell the account holder as much as possible about what is going on at each step in the process without disclosing anything which could be used for nefarious purposes. It’s the same thing once the password has actually been changed – let the owner know!

A change of password can come from one of two different sources:

Changing the password while already logged on because the owner wants something different
Resetting the password while logged off because the owner has forgotten it

Whilst this is a post primarily about resets, a notification in the first example above mitigates the risk of someone else changing the password without the legitimate owner’s knowledge. How could this happen? A very common scenario is that someone else has obtained the legitimate owner’s password (reused one breached from another location, key logged, easily guessable, etc.) and has decided to change it and lock them out. Without an email notification, the real owner has no idea of the change.

Now of course in the reset scenario the owner must have already initiated the process (or defeated the various identity verification measures outlined above) so the change shouldn’t come as a surprise to them, but email notification is positive feedback and additional verification. Besides, it makes for a consistent experience in both of the scenarios above.

Oh, and in case it’s not already obvious, don’t email them the new password! Some of you may laugh, but it happens:

Log, log and then log some more

The thing about a password reset feature is that it’s ripe for abuse, either by an attacker wanting to gain access to an account of someone just wanting to cause mischief and inconvenience for the account holder or system owner. Many of the practices discussed above will help mitigate abuse, but they won’t stop it and they certainly won’t stop people from attempting to misuse the feature.

One practice that can be absolutely invaluable for detecting malicious behaviour is logging and I mean really extensive logging. Log failed log on attempts, log password resets, log password changes (i.e. while the user is already logged on) and basically log anything you can that will help you identify what’s going in should you really need it in the future. Even log individual parts of the process, for example a good reset feature will involve initiating the reset via the website (log the request and log attempts to reset with an invalid username or email), log the visit to the website with the reset URL (including attempts to use an invalid token) then log the success or failure of the secret question’s answer.

Now when I say logging, you don’t just want a record of the fact the page was loaded, you want to collect as much info as you can so long as it’s not sensitive. People, please don’t log the password! What you do want to log is the identity of the authenticated user (they’ll be authenticated if they’re changing an existing password or if they’re attempting to reset someone else’s while logged in), any attempted usernames or email addresses plus any reset tokens they attempted to use. But you also want to log things like IP address and if possible, even request headers. This allows you to reconstruct not just what the person (or attacker) was attempting to do, but who they were.

Delegating responsibility to other providers

If this all just seems like a lot of hard work, you’re not alone in your thinking. The reality is that building a secure account management facility isn’t simple. It’s not that it’s technically hard, it’s just that there are a lot of nuts and bolts involved. It’s not just resets, there’s the whole registration process, secure password storage, handling multiple invalid login attempts and so on and so forth. Whilst I advocate using pre-built functionality such as the ASP.NET membership provider, there’s still a lot of work to be done.

These days there are numerous third party providers who are happy to take the pain of writing all this yourself and abstract it all away into a managed service. The options include OpenID, OAuth and even Facebook, among others. Some people swear by this model (indeed OpenID has proven to be very successful on Stack Overflow), but then others literally find it a nightmare.

Undoubtedly, a service like OpenID takes a number of problems away from the developer but also undoubtedly, it introduces all new ones. Does it have a role to play? Yes, but clearly we’re not seeing authentication providers adopted en mass. Banks, airlines even shopping – I can’t think of a single one which doesn’t impalement their own authentication mechanism and there are clearly some very good reasons for that.

Malicious resets

One thing about each of the examples above is that the old password is only rendered useless after the account owner’s identity has been verified. This is very important as if the account could be reset before verifying identity and then the door is opened for all sorts of malicious activity.

Here’s an example: someone is bidding at an auction site and towards the end of the bidding process they lock out competing bidders by initiating the reset process thus removing their competition. Clearly there can be major adverse results if a poorly designed reset feature can be abused. Mind you, account lockouts by invalid login attempts is a similar story, but that’s one for another post.

As I mentioned earlier, allowing anonymous users the ability to reset anyone’s account simply by knowing their email address is a denial of service attack just waiting to happen. It may not be a DOS in the way we often think of it, but there’s no faster way to lock someone out of their account than though a poorly designed password reset feature.

The weakest link

All of what you’ve read above is fantastic in terms of securing a single account, but one thing you need to remain conscious of is the ecosystem around the account you’re securing. Let me give you an example:

ASafaWeb is hosted on the very excellent service provided by AppHarbor. The reset process for their hosting account goes like this:

Step 1:

Step 2:

Step 3:

Step 4:

After reading all the earlier info in this post it’s easy to see there a few areas which, in a perfect world, we’d approach a bit differently. The point I want to make here though is that if I publish a site such as ASafaWeb onto the AppHarbor service then implement some great secret questions and answers, throw in a second factor of authentication and do everything else by the book, none of this will change the fact that the weakest link in the process can trump all of this. After all, if someone can successfully authenticate to AppHarbor using my credentials then they can go and reset every single ASafaWeb account to whatever password they like anyway!

The point is that the strength of the security implementation needs to be looked at holistically; you need to threat model each and every entry point in the system, even if it’s just a cursory process such as what I did above with AppHarbor. This is enough to give me a good indication of how much effort I should be investing in the ASafaWeb password reset process.

Tying it all together

This post contains a lot of information to absorb so let me distil it down to a simple visual representation:

Keep in mind also that you want to be logging the activity at as many of these points as possible. And that’s it – easy!

Summary

If this seems like a comprehensive post, consider that there’s plenty of additional material I could have included but elected not to for the sake of brevity; the role of a rescue email address, what happens if you lose access to the email on the account (i.e. you change jobs) and so on and so forth. As I said earlier, it’s not that resets are difficult, it’s just there are a lot of angles to it.

Even though resets aren’t difficult, they’re often implemented poorly. We saw a couple of examples above where the implementation could lead to problems and there are many more precedents where resets gone wrong did cause problems. Just the other day it seems that a reset was abused to steal $87k worth of Bitcoins. That’s a serious adverse result!

So take care with your resets, threat model the various touch points and keep your black hat on while building the feature because if you don’t, there’s a good chance that someone else will!

Talking cloud: Not all .NET roads lead to Microsoft

2012-05-17T07:44:00.001+10:00

Strangely enough, there are time when I talk about things that aren’t directly related to security and yesterday’s guest appearance on the Uhuru podcast was one of these. In fact “the cloud” is something I’m deeply interested in and have spent a lot of time thinking about and working with lately, one significant of example of which has been the use of AppHarbor for hosting ASafaWeb.

Yesterday I had a short chat to Michael Surkan from Uhuru Software on how I was adapting to the new world cloud order and particularly what I like about the AppHarbor offering. I’d had some involvement with the Azure in the very early days and made the decision to choose AppHarbor about a year back so hopefully those timeframes put some of my comments in context (but I’m sure people more knowledgeable about Azure than me will call me on the inevitable mistakes in what I said!). This is now up on the Uhuru website:

Listen: Not all .NET roads lead to Microsoft

We had a good chat offline afterwards and one thing that really stuck out is the number of players entering the cloud market and the different angles they’re approaching IaaS / PaaS / SaaS from. It’s great news for those of us on the development side as we can choose from a much broader range of app hosting models than we ever had access to before. Offerings such as Azure are a very different paradigm to the likes of AppHarbor which is very different again to what you get from the Amazon offerings. Good times to be a developer!

Speaking about ASP.NET security on the OWASP podcast

2012-05-09T07:58:00.001+10:00

I’ve been writing and speaking about OWASP for long enough now that it was probably about time I contributed to the podcast so when Jim Manico invited me to talk, it was a no-brainer! I had a good chat with Jim about a range of aspects related to ASP.NET; good stuff in the framework, not such good stuff in the framework, where I’m seeing people go wrong with .NET security and then a bit about some of the things I’m doing in terms of writing the OWASP Top 10 for .NET devs and ASafaWeb.

You can listen to it now via MP3 or do yourself a favour and subscribe to the podcast on iTunes or via RSS.

Interview with the man behind Comantra, the “cold call virus scammers”

2012-05-08T06:23:00.001+10:00

If you live in a western country and have a landline telephone with a listed phone number, chances are you’ve been “cold called” by someone on the other side of the world with an introduction that goes something like this:

“Hello, I am from the Microsoft technical support division and I am calling you because we have detected some problems with your computer. This is very important – I need you to go and turn your computer on right away…”

It doesn’t matter if you have a computer, in fact it doesn’t matter if you’ve never even touched a computer because these calls are totally random. There is no implicit support that will proactively monitor your computer from a central location, these calls are nothing more than a scam intended to prey on the fear of unsuspecting people who can be convinced there are genuine problems with their PC so that they can be parted from their hard earned cash for “support” they don’t need.

I had been on the receiving end of this scam myself a number of times so I began recording several of the events and posting them to YouTube and this blog. Tens of thousands of views and hundreds of comments later, its clear this scam is rampant and many people are indeed being stung by it.

So I decided to contact the man behind the company which most frequently features in these scam calls: Comantra. That man is Rajesh Bajaj:

I came across Rajesh after doing some basic research on Comantra and a quick Google confirms he is indeed the man to talk to. As it turns out, Rajesh has his own counterview of how Comantra operates and was willing to answer some email questions which I promised to reproduce in their entirety.

The interview

1. What is your role at Comantra?

I am the director

2. Comantra describes themselves as a “technical support service”. How does Comantra usually acquire new customers?

Please check the below link it
https://www.comantra.net/site/news/105
http://comantra.wordpress.com/2012/03/12/long-awaited-new-mantra-from-comantra-is-all-set-to-strengthen-brand-repositioning/
we are not not accepting any fresh registration.

3. There have been reports of Comantra “cold calling” perspective customers in countries such as Australia and the UK. Has Comantra ever made unsolicited phone calls to perspective customers?

Yes, telemarketing and telesales also was part of our sales team however sales team was suppose to stick to a quality script like its as pc health check call

4. There are claims that operators purporting to be from Comantra have phoned individuals and advised them that their PC is infected with viruses. Is there any truth to this or is it a case of Comantra being a “victim of organised reputation assault” as you’ve suggested on your blog?

Yes you are correct we have been victim of organised reputation assault. We were following a very strong and a quality script like its as pc health check call however we have received number complaints about it even though we have stop the registration we still get mail that they received the call from comantra. Our research team has also found that there are some companies who are making cold calls without even having a website and with the customer demand, different companies website are presented whom they don’t even relate to. They also charge them with western union.

5. One of the services Comantra offers is the detection and removal of malware and spyware. How is malicious software usually identified by Comantra and can you do this remotely for individuals who are not yet customers?

Malware or spyware removal is a job of a tool the only expertise required is that we have choose the correct tool for the stipulated problem.

Yes do entertain non registered customers as well we show them our technical team skill and also if they like the service and happy with result they pay us accordingly like for a incident or a annual subscription.

6. Have Comantra staff ever been trained to refer to warnings in the Windows Event Viewer as harmful files which indicate infection on the PC?

7. Has Comantra ever sold Windows warrantees and if so, what does this comprise of?

No, we only cover software part which is windows, the platform on which the major computer runs could be said as AMC in which we do not cover hardware part.

8. Are you aware of any other organisations making cold calls and claiming to have remotely identified viruses on individuals’ PCs?

No comments

9. In September last year, it was reported that Microsoft ejected Comantra from its Gold Partner program. Could you tell us a little more about this situation?

This was really disappointing for us it took a lot for us to get this we even discussed this matter with Microsoft to reinstate back our status but was we met the failure in it.

The fair reason was a negative reputation for our company which would have encouraged the Microsoft in taking this decision

10. Is there anything else you’d like to add about Comantra in relation to the claims of it being involved in a scamming program?

With complete negative result about our company we were forced to stop the registration and we have closed our sales team and are only operating with our technical department to serve our registered customers. However we we are building a very strong and tested marketing strategy to get the new customer. we have a plan to start a fresh registration again in the near future which will not include telesales only inbound calls will be entertained.

Closing comments

Let me list out a few observable facts. Firstly, Comantra’s website is located at comantra.net and a WHOIS on the domain name confirms Rajesh’s involvement:

The website lists the Australian phone number 0872001644:

As I got more involved in tracking this scam, a number of people contacted me and provided me with this number and Comantra’s name, both of which had been left with them by callers claiming to have remotely detected malicious activity on their PC. A Google search of this number returns numerous results about being cold called by Comantra and the Event Viewer being used as a means of convincing people of the presence of viruses. There is also a UK number – 01916451644 – and a US number – 8882266073 – both of which yield similar search results.

This is also the phone number I called in my video about Scamming the scammers. During this (admittedly lengthy) video, there are numerous points where the identity of the organisation is confirmed as being Comantra, including when I’m taken to their site to register then make payment:

The Windows 7 image I used in the video was a clean install with all the latest service packs, patches and running Microsoft Security Essentials. It was 100% free of malicious files or anything else which would cause adverse behaviour by the machine.

During the video and after being directed to the Event Viewer, I was told “This is the errors and the warnings that are in the computer, these are the very harmful files in the computer” followed by “That is the reason your computer is having a lot of problems”. When I asked about the errors I was told “These are the corrupted files” then “This are not functioning properly in the computer” and “The software part of your computer is getting corrupted day by day”.

When discussing the Windows warranty, I was told “You've got two types of warranty on the computer, one is the software and another is the hardware” then “The software one is for 4 years and the hardware one is for 5 years” and “As the software warranty expired from the computer that's why your computer is experiencing problems”. When I asked if I could pay the warranty directly to Microsoft, I was told “No, as we are the service providers of Windows operating system” and “We take care all the users of Windows operating system all over the world”.

The discussions above were indisputably held with Comantra staff.

I made a commitment to Rajesh to report on the interview he gave in an entirely objective fashion so I’m going to sign off the post like this: You be the judge – use the comments below to express your opinion and draw your own conclusions. Is Comantra indeed running a scam or is it possible, as Rajesh claims, that they’re a rising star fallen victim to organised reputation assault?

“Type www.” – “Ok, w-w-w-d-o-t”; antagonising call centre scammers

2012-04-25T07:58:00.001+10:00

This ain’t my first rodeo, this ain’t the first I’ve seen this dog and pony show. I first wrote about virus call centre scammers back in October along with my recording titled Anatomy of a virus call centre scam. I followed up a couple of months ago with Scamming the scammers – catching the virus call-centre scammers red-handed which screen recorded the entire process right up to where they attempted to commoditise the scam, or in other words, get cash out of me.

Imagine my pleasure when they called me back last night! I use the term “they” very colloquially; it’s always the same scam run against the same run-sheet but there seem to be a number of companies behind this special brand of evil. This time it was a group called “E-Protection” and it doesn’t take long to establish that these guys have a bit of a record.

This time I decided to see how effectively they could support the Windows 8 Consumer Preview virtual machine I had running. The sheer incompetence of particularly the first operator I spoke to is quite astounding, not just technically but the fact that very little of what I was saying was actually absorbed. By the time I got to the second guy at about the 29 minute mark I thought it might be time to inflict some of the pain they’ve been dishing out to their victims back onto them. Enjoy :)

But there is a serious side to this; go back and look at the comments (particularly in that second video I linked to) and you’ll see a number of people being defrauded. There’s very little the authorities in countries like Australia can do about it as these guys are based offshore (I did try – and got nowhere). Unfortunately the other players in the scam also have little interest in doing anything to prevent it. I contacted LogMeIn via Twitter right after the event and all they had to say was this:

I’m sorry, but that’s just not good enough. At the very least, they could place a clear warning on the page the scammers are directing you to. These guys need to start showing a bit of social responsibility.

As you can see, particularly from the first operator in the latest video, the scammers simply don’t give a damn; not listening, just running through the script and when it’s clear you can’t provide them any value, they’ll just hang up (this also happened to me last week, just a bit too early to extract a meaningful episode).

As I said at the end of this video, please educate your less-technical family and friends on this one, there are a heap of similar videos out there from other people – it’s rampant and it obviously works because it’s been running long enough.

Technology and Friends: Troy Hunt on ASP.NET Security

2012-04-24T08:15:00.001+10:00

It already seems like a lifetime ago, but it was only last month that I was over in Seattle at the 2012 MVP Summit. While I was there, I had a short chat on video with Dave Giard for his Technology and Friends blog. We predominantly spoke about ASP.NET security and in particular, cryptographic storage of credentials and transport layer security so it’s a little more focussed than many of my talks.

The original post is over on Dave’s blog under Episode 207: Troy Hunt on ASP.NET Security and on the video on Viddler. Big thumbs up for Dave’s choice of soundtrack, I think I’m going to have to use that myself in future presentations!

10 graphic examples of the abomination that is iTunes on Windows

2012-04-20T07:33:00.001+10:00

This is a rant; an unapologetic, no holds barred rant on why something that I hold in such high esteem – my iOS devices – could have come from the evildoers who created this spawn of Satan: iTunes. I love my Apple TV, my iPad, my iPhone, my wife loves her iPhone, heck, even our two year old loves his hand-me-down iPhone. They all rock – big time. They’re the best damn devices I’ve ever owned, without exception.

But the otherwise joyous experience of ownership is continually crippled by the searing pain that is iTunes. Not every other day, not once or twice a day but many times every single bloody day. It’s a rare occasion I tweet about “bloody iTunes” and don’t receive a chorus of support from other disenchanted, otherwise happy Apple customers. It’s not just me folks, oh no.

Rather than suffer in silence or be comforted by the occasional mere “me too” tweet, a few months back I started capturing the litany of problems that iTunes threw my way, dropping a collection of the more painful examples into the blog post below. Oh – and just before the comments about “it works fine on my machine because I have a bejillion MB of RAM and a flux capacitor CPU”, all my experiences to follow are across many machines with lots of GBs of RAM and cores in CPUs and no moving parts in disks. It ain’t me folks!

1. It just…….haaaaaangs

Frequently I open up iTunes of a morning (often inadvertently because I’m simply looking for a power source for the iPhone) and am greeted by something like this:

That big black outline is iTunes call for help – it’s frozen and totally unresponsive. Eventually it snaps out of its micro-coma. When it feels like it. After a little nap.

2. It thinks hex mean something useful

It must, because I get them all the time. No, not every other day, every single day. Many times. If the iPhone is within earshot (or wifi-shot, as it may be), iTunes is going to have a little internal identity crisis and regurgitate a totally meaningless error:

Why? I mean why throw hex at me? Just gracefully explain you don’t know what’s wrong and move along.

3. Actually, it’s not just hex errors

Don’t worry, iTunes is not hexist and only uses base 16 to do its dirty work, negative integers make fine error codes as well:

Is this better or worse than a +50 error? And do error codes really need to sound like hit-points in some crazy Apple derivative of D&D?!

4. Because it sees double because it sees double

I have one iPhone. My wife has one iPhone. So why the hell do I see two instances of each collection of purchased items?!

I’m sure there’s probably some explanation about having had multiple devices over time but of course they’ve all cleanly upgraded to the next one and all been under the same Apple IDs, yet here we are.

5. Hello? iPod Nano? Where are you?

When I plug in this little guy:

I expect iTunes to do something. Show me it’s connected. Make a beep. Give me some love. Anything, just acknowledge its existence! But here’s what usually happens:

Yep, no devices. So I unplug it then try again. And again. Rinse, lather, repeat and so on. Eventually it might show up:

Why is this so hard? Windows knows it was plugged in – it gave me an affirmative beep and allowed me to browse the contents; why does iTunes just give it the silent treatment?

6. Reboot? But I don’t want to reboot!

iTunes is a media player; why must every single update force me to shut down everything I’m doing and reboot the entire machine?!

I mean, this isn’t exactly a service pack or anything that needs to get down into the guts of the OS, why on earth does an app that plays some music and syncs my phone want to reboot the whole damn machine?! Stop doing this!

7. Uh, no, I didn’t change anything

When I change a setting, I expect I might get a message asking me to affirm the aforementioned change. When I don’t change a setting, I don’t expect to see this?

So why must it continue to taunt me?! Over and over and over again, iTunes continues to hammer me with this pointless, incorrect message. Just stop it, dammit!

8. Networks – we need more networks!

Now I know this isn’t iTunes per se, but given it only started happening after the iOS 5 upgrade it’s probably pretty fair to say it’s something screwy on the Apple side. Every single time I plug the iPhone in, I’m now challenged to “Select a location for the network”:

Clearly this is related to the phone enabling a personal hotspot – which it had always done in the past – but why must I continually define the network location again and again and again? And it’s not just me folks, oh no.

9. Any day ending in “y” is a good day for a crash

Total cardiac arrest is another favourite of iTunes:

Sometimes it performs an Easter miracle and rises from the dead, other times it remains well and truly comatose and simply will not resurrect. Which would actually be fine, if it stayed dead and wasn’t required again.

10. Because it’s now constantly there

iTunes has sucked for a very long time now. It has a rich history of user experience faux pas that clearly time has not allowed Apple to heal. But at least it was always a conscious decision to enter into the realm of iTunes pain, I mean you had to explicitly fire it up and as such, you had time to brace yourself for the inevitable onslaught of pain.

Not anymore. Wireless sync in iOS 5 sounds like a great idea and I’ll admit I was lured in by the promise of being able to chuck cables away. But there’s an ugly downside to this: iTunes now constantly comes to life from an otherwise dormant state. Clearly there’s a background process that identifies there’s an iOS device in range and decides to bring iTunes back to life at some arbitrary point in time.

In fact the whole iTunes conundrum made me reminisce about this little illustration from defectivebydesign.org:

Six years on from this design and whilst some progress has been made on the DRM front, we’re now not only tied into iTunes by the iPod but by the iPhone, iPad and now even the bloody Apple TV if you want to play your existing media.

Summary

Clearly whilst genuinely frustrated with the whole iTunes experience, there’s a degree of tongue in cheek going on above. But let me step away from my own subjective experiences for a moment and share the following quote from Slashdot’s iTunes’ Windows Problem post just a couple of days ago:

But today, the toxic waste of success cripples iTunes: increasingly non-sensical complexity, inconsistencies, layers of patches over layers of patches ending up in a structure so labyrinthine no individual can internalize it any longer. 'It's a giant kitchen sink piled high with loosely related features, and it's highly un-Apple-like' says Allen Pike. 'Users know it, critics know it, and you can bet the iTunes team knows it. But for the love of god, why?'

“It’s un-Apple-like”. That, for me, is the entire iTunes experience in a nutshell.

10 illustrated examples of Visual Studio 11

2012-04-19T08:50:00.001+10:00

Fresh from the 2012 MVP summit with lots of enthusiasm and grand ideas, I thought it would be worthwhile repeating my 25 illustrated examples of Visual Studio 2010 and .NET 4 post with the technologies of today (or should that be tomorrow?) albeit a few weeks later than I had planned. There are some very, very exciting new things in the pipeline which I’d like to share while they’re fresh in my mind and analogous with that post from two and a half years back, I’d like to actually show you what’s happening.

There’s so much great new stuff in Visual Studio 11 that it deserves its own post! If I can create the time, I’ll also try and get around to covering ASP.NET specifically. Keeping in mind I’m a very web-centric guy, let me show you some of the features which have gotten me a bit excited about what’s coming in the very near future.

1. Its grey (and other UX changes)

Let’s just get this out there right now; the new Visual Studio UX is polarising. Actually, polarising would suggest there are two different views of it. The reality is there is a strong chorus of “Ugh” at the moment. You see it’s all about Metro these days and that means VS 11 now looks like this when running on Windows 8:

Just in case you need a little reminder of how things used to look, here’s VS 2010 on Win 7:

There are three things I want to call out in VS 11 as they’re the three which are repeatedly brought up:

The greyness.
The capitals on panel titles.
The colons on the panels.

You can get a better idea of those last two items here:

The theory is that all those nasty colours get a bit distracting when what you really want to be doing is focussing on code, not file icons or buttons on menus. Many people countered that with “Yeah, but I minimise all my panels anyway”.

So what do we make of all this? Well, the feedback I’ve seen and heard honestly hasn’t been positive. Sure, it’s Metro and Metro is the new black but it almost seems to be Metro in name more than anything else – certainly it doesn’t jump out and remind me of the Metro I know from Windows Mobile 7 or Windows 8.

One very apt comment I heard in one of the sessions was that Metro is great for, say, a mobile app but an IDE is a very different paradigm. Does that mean Metro won’t work in VS? I don’t know, but certainly it’s a very different context.

Love it or hate it, the thing is that this is a first beta and things will almost inevitably change to some degree. I suspect the release version won’t be too far off the preview version, but clearly some refinement will still happen. This is evident in a few places where colour is still evident:

And:

As a closing thought on UX, the only other thing I’d say is “use it”. Give it a go and see if it really does impact the development experience and if that experience is negative, then come back and complain about it :)

2. Quick search

This one is actually very cool and should offer a major productivity advantage. Up in the top right corner of the IDE we now have a little “Quick Launch” text box which you can shortcut to with CTRL-Q. I look at this as the Visual Studio equivalent of the Windows key in Windows 7; hit it, type whatever you want then it will find it for you. For example:

In this case, VS has found everything from menu items to configuration options to open documents. There are also other categorisations it searches for and I think this is going to be one of those super useful features that you soon wonder how you lived without, just like that aforementioned Windows 7 feature is for me now.

3. Backward solution compatibility

When I started rolling out Visual Studio 2010 in my workplace, one of the greatest hurdles to adoption was the solution file format. Once you opened a .sln created with an earlier version of the IDE you had no choice but to upgrade the solution version. Doing this then meant no going back (without some nasty hacks) so in short, either everyone who might possibly work on the solution upgraded to the new IDE or nobody did. And then if you worked across multiple project versions you needed to run multiple versions of the IDE. Nasty.

Here’s how Jason Zander explains it in his introduction of VS 11:

The compatibility improvements in Visual Studio 11 will make it easier to work with your existing Visual Studio assets, without doing any “upgrades” of project files. In the majority of cases, you can use Visual Studio 11 and also continue collaborating on projects with your teammates using Visual Studio 2010 SP1.

To demonstrate this new friendly behaviour, I created a VS 2010 web application then opened it up in VS 11. Here’s the difference between the two solution files:

This will cause some minor differentiation in the logos:

But the important bit is that after opening the solution in VS 11 you can still jump back into VS 2010 and things work just fine:

Look at all that colour! The only caveat in all of this is that you still need to be on VS 2010 – this isn’t going to help projects stuck on earlier versions of the IDE.

For me personally, this is going to make rolling our VS 11 significantly easier as it can be done more on a needs basis rather than just because you want to open a solution someone with the newer IDE worked on.

4. Smarter Solution Explorer

There’s a bunch of new stuff the Solution Explorer can do that we either didn’t have before or was nested over in other windows such as the Class View. What’s neat about this revision is that the Solution Explorer becomes a real hub for all sorts of activities:

The search feature also makes an appearance so finding those pesky files nested down under five folders becomes a pretty easy task (note it also searches for class members – not just file names):

5. Find and replace goes lightweight

First a quick reminder of what the good old CTRL-F would do for us in VS 2010:

A great big dedicated panel with lots of options. Compare that now to how VS 11 approaches things:

Ok, that’s a rather streamlined approach! In case you’re wondering where all that missing stuff has gone, it’s still there:

You’ll notice that the control is also resizable so if you’ve got a fetish for long searches you can keep it all visible in the text box. And if you really long for the find and replace of old, you can CTRL-SHIFT-F back into it:

Does all this feel just a little bit familiar? It did to me, because my VS 2010 already behaved in this fashion courtesy of the Productivity Power Tools so it’s interesting to see that Microsoft has just gone ahead and rolled this into the IDE as a first class citizen.

One more thing; if you’re like me and have trouble wrapping your head around regexes, there’s more help at hand than we had before:

6. Windows 8 ready

There should be no surprises here given the timing, but VS 11 now comes with a bunch of Metro project templates ready for Windows 8:

One important thing to note though is that you’re going to have big problems building a Metro app if you’re not running Windows 8. Developers on Windows 7 or – gasp! – earlier versions of the OS are going to need to get with the times first.

7. CSS editing gets much cooler

There are a number of enhancements in the CSS editing space but here are a few of my favourites. Firstly, there’s a built in colour-picker which pops up in any context where it might make life a little easier for you:

The other neat little feature is the ability to pre-fill browser specific schema prefixes on certain CSS attributes. For example, begin making a “border-radius” entry, hit “tab-tab” and watch the magic:

Here’s another new one: what’s wrong with the following CSS?

Answer: nothing. The indentation you’re seeing is hierarchical; the tag with the ID “login” may have an anchor tag which may then have a “username” class. It looks a little odd at first but I suspect it will become advantageous in terms of helping you properly structure your CSS in a logical fashion.

These are little enhancements, but they contribute to the overall increased productivity theme we see in each release of the IDE.

8. Image previews

From the “small but handy” file, say hello to image previews:

There’s not much to say here beyond what you observe above; hover the mouse over an image and a little thumbnail pops up. Saves you accidentally selecting the wrong file at times and avoids having to actually open the entire file one by one. Quickly flicking through images is now dead easy.

9. Choosing a browser to run the app in is finally easy

I don’t know what it was about earlier versions of the IDE, but no matter how many times I set my default browser to IE (right click file –> browse with), it would always revert back to my OS default (Chrome) when I pulled the project up at another date. The fact that Hanselman had enough material on this for a lengthy blog post is evidence that this hasn’t exactly been a smooth experience in the past.

VS 11: problem solved. Right up there next to the run button is the ability to choose the browser you want to fire up:

This is a significantly better implementation as not only do you always have the browser F5 is going to give you right in front of you, but it’s dead easy to change it. That old “Browse with…” option was painful because it was usually only after the solution built and fired up the wrong browser that you realised there was a problem. And then try getting the “Browse with…” dialogue up on an MVC app; can’t do it on the controller, can’t do it on the view so you end up creating a temporary HTML file just to access the dialogue! Maybe there’s a better way I’m not aware of, but fortunately it doesn’t matter anymore anyway.

10. Page Inspector (it rocks!)

One very, very cool new feature is the page inspector. Once you move away from the one file per rendered page paradigm and get into things like master pages, user controls, layout pages and partial views, things start getting very messy when you want to work out where rendered content in the browser is actually coming from.

Enter the Page Inspector. Let’s just take a look at it then I’ll run through the highlights. Firstly, you can run it up directly from what is usually your run button:

Which then gives you the site running within the IDE plus a couple of new windows (click to enlarge):

What’s happening here is that the site is running in the top left panel and I’ve selected part of the heading. We’re then seeing this selection in the bottom left panel like you’re probably familiar with in the IE9 developer tools. Next to it is the CSS that has been applied.

The real magic though is the panel to the right. Here you can see the actual file containing the selected text, in this case it was “Index.cshtml”. Regardless of the file the text was contained in, Page Inspector will find it and highlight it in the source.

But wait – there’s more; you can now change content in that right hand panel and VS 11 will allow you to refresh the Page Inspector view and see those changes immediately reflected in the page:

Unlike using the IE9 developer tools or a product like Firebug, this is actually a means of actively evolving the code – these are “sticky” changes which are saved to the source file and persist beyond this instance of Page Inspector. If this all sounds a bit hard to visualise, check out the Channel 9 video of Page Inspector in action. Very, very cool.

Summary

Firstly, a little piece of good news from Jason Zander if VS 11 is looking appealing to you:

Visual Studio 11 Beta meets our “Go Live” quality bar for pre-release software. Therefore we are recommending it for use in production, and supporting it as “Go Live” release.

Of course you can still work with your .NET 4.0 and earlier projects with VS 11 so using the new IDE is no way needs to drag your apps into the new version of the framework. Based on my experience of using VS 11 on Windows 8 in a VM it certainly seemed just as stable as 2010 on Windows 7. Having said, I don’t think I’ll be taking any risks with my work machine just yet.

So overall feelings? Other than the grey, it’s continued incremental improvements across a wide range of areas. Actually I’m not saying the grey isn’t an improvement, it’s just something I’m yet to fully adapt to. Like the previous couple of versions, all of these little improvements add up to a smoother, more productivity experience rather than one massive bang from a killer feature (although Page Inspector might get close to that for some). Positive steps forward, I reckon.

References

5 interesting security trends from Verizon’s 2012 data breach report

2012-04-16T17:31:00.001+10:00

A few weeks back there was a great document released by Verizon (yep, the big American telco) titled Verizon 2012 Data Breach Investigations Report. This weekend at the OWASP Appsec Asia Pacifica Conference, I sat in on a talk from Mark Goudie from Verizon who helped put the whole report in perspective. Now this is a really interesting report because rather than talking about vulnerabilities (i.e. potential risks), they’re actually looking at exploits; this is hard facts, people!

This report is based on 855 incidents in 2011 (don’t be confused by the year in the title!) and because Verizon does this each year, there’s lots of data on how trends are changing. It’s also 80 pages of hard facts which can be rather a lot to digest. But there are some really interesting nuggets in there for those who take a bit of an interest in security. Let me cherry-pick a few of the good ones.

1. Breaches are (almost) no longer coming from inside the organisation

It wasn’t that long ago that the common belief (and there were plenty of numbers backing this up), was that a significant portion of breaches stemmed from inside the organisation. Disgruntled employees, opportunistic mutineers, those off to greener pastures grabbing a handful of data on their way out – whatever – but it’s now a very different story:

Who is behind data breaches?
98% stemmed from external agents (+6%)	No big surprise here; outsiders are still dominating the scene of corporate data theft. Organized criminals were up to their typical misdeeds and were behind the majority of breaches in 2011. Activist groups created their fair share of misery and mayhem last year as well—and they stole more data than any other group. Their entrance onto the stage also served to change the landscape somewhat with regard to the motivations behind breaches. While good old-fashioned greed and avarice were still the prime movers, ideological dissent and schadenfreude took a more prominent role across the caseload. As one might expect with such a rise in external attackers, the proportion of insider incidents declined yet again this year to a comparatively scant 4%.
4% implicated internal employees (-13%)
<1% committed by business partners (<>)
58% of all data theft tied to activist groups

Going back to that earlier comment about attacks previously often coming from inside, take a look at how the data has changed over time:

Threat agents over time by percent of breaches:

Or to put it another way, breaches originating internally are now only 12% of what they were a few years ago and breaches from partners are near non-existent. The bad guys are now well and truly outside the organisation – but they’re still getting in.

Oh – and in case you’re wondering why 98% plus 4% plus under 1% adds up to more than 100%, some breaches span both external and internal players. For example, someone external socially engineers someone internal into divulging their credentials. Makes sense now!

2. Hacktivists are becoming seriously bad news

This shouldn’t come as a surprise, but the number above is still alarming; 58% of data theft was tied to individuals purporting to carry out their illegal activities on the basis of some form of activist belief. Frankly, when you look at the demographic of those being caught in the act (frequently teenagers or early 20’s), I suspect that whilst these individuals are readily attaching themselves to hacktivist groups such as Anonymous and LulzSec, it’s more about gaining a bit of notoriety and having some lulz than it is about fighting for a cause.

From the report:

The most significant change we saw in 2011 was the rise of “hacktivism” against larger organizations worldwide.

Regardless of the motivations of hacktivists, the fact remains that there is a groundswell of individuals out there queuing up to take a shot at just about any website they can get their hands on. They don’t need the financial incentive of true cybercriminals or the political and military goals of nation states, they just need an easy target. Frankly, for website owners, this indiscriminate targeting should be rather worrisome.

3. The majority of breaches are related to simple credential theft

Here’s an interesting one; how do you think most hacks are being carried out these days? Some funky SQLi? Sneaky 0-day exploits? Not quite:

Threat Action Types by number of breaches

Variety	Category	Breaches
Use of stolen login credentials	Hacking	30%
Backdoor (allows remote access/control)	Malware	18%
Exploitation of backdoor or command and control channel	Hacking	17%
Tampering	Physical	17%
Keylogger/Form-grabber/Spyware (capture data from user activity)	Malware	13%
Pretexting (classic social engineering)	Social	12%
Brute force and dictionary attacks	Hacking	8%
SQL injection	Hacking	8%
Phishing (or any type of *ishing)	Social	8%
Command and control (listens for and executes commands)	Malware	8%

The use of stolen credentials is, relatively speaking, off the chart. Nearly a third of breaches involved the theft of credentials (among other vectors – another one of these does-not-add-up-to-100% scenarios), which is quite astounding. I say this because obviously once credentials are obtained, the “hack” itself may be very unsophisticated indeed.

Of course the bigger question this raises is “How are these credentials being stolen?” The report alludes to keyloggers and spyware being to blame so again, these breaches are often the result of a series of incidents opening various doors leading up to the eventual data breach.

4. You’re way more likely to be socially engineered by talking to someone than via email

Social engineering is what happens via email, right? I mean there is a common belief that modern social engineering is something which predominantly has its roots online – or perhaps that was just my belief. The numbers, however, paint a very different story:

Social vectors by percent of breaches within Social

What strikes me as surprising with these numbers is that the phone and in-person vectors both involve actually talking to and verbally engaging with the victim. The veil of anonymity provided via email and social networking sites is not there; the attacker has to respond on the spot with credibility and actually convince their victim to divulge information or perform activities they wouldn’t (or at least shouldn’t) normally do.

On the other hand, nobody expects the Spanish inquisition; putting a voice – or even a face – to an attacker gives them enormous leg-up over a random phishing email when it comes to actually establishing some credibility. I recently read Kevin Mitnick’s Ghost in the Wires and when you consider how easily he was able to gain trust and leverage his victims’ good nature against their better judgement, the figures above perhaps don’t seem so surprising.

5. Breaches take only minutes yet are discovered after months – and then they take a long time to fix

How much effort does it actually take to breach a vulnerable target? Apparently you can measure it in minutes:

Timespan of events by percent of breaches

The significant bulk of results falling into the “Minutes” category suggest that most breaches recorded by Verizon are very simple affairs. We’re talking 85% of them taking minutes or even less (I assume “Seconds” would imply some form of automation).

But the other stunning fact here is how long it takes to actually discover the compromise after the fact; “Months” is very bloody long time! So someone has broken in, stolen your data and by the time you realise it, they’re looooong gone.

The last row is also concerning because it says that more than half the time it takes at least some weeks to fully plug the hole and get back to business as usual. Think about the business impact of this – we’re taking a major adverse outcome in many of these cases.

You know what the most interesting stat is? It’s the one that’s not in the chart above but would be simply titled “Attacks that were never discovered”. Now of course by its very nature we’re never going to see this charted, but the very fact that it more often than not takes months to discover a breach, there are undoubtedly a significant number that go undiscovered. Forever. In fact the report does make a mention of this:

We hypothesize that many insider crimes go unreported because the organization is unaware of them, or because they decide for political reasons to handle it internally.

Makes you wonder who has been in your systems without you ever even realising, doesn’t it?

Other interesting titbits

On PCI compliance:

We still hear the common mantra “How could I have been breached?—I’m compliant!” We cannot stress enough that while compliance definitely helps drive security, compliance does not equal security.

Does anyone really think that being PCI compliant alone means you’re “unhackable”?! I suspect the big compliance sticker appeals to those who perhaps don’t have a great appreciation of the finer points of software security and it is those same individuals who are quoted above. Just sayin’.

On the variety of hacking attacks:

Like every year, a handful of techniques dominate the charts. Generally, the hit parade can be subdivided into the authentication attacks, and technical attacks that bypass or break authentication altogether.

Now this covers everything from exploiting default (yes – default!) or guessable credentials, the use of stolen credentials and brute forcing auth systems. It’s interesting to juxtapose this with the OWASP Top 10; no injection, no XSS (the “Top 2”), rather its third on the list – “Broken authentication and session management”.

On attacks against larger organisations:

So, what about larger organizations? Surely they’re a lot more difficult to infiltrate, right? Sadly, our data seems to suggest otherwise; it does not appear that cybercriminals have to work much harder to compromise larger organizations than they do for smaller ones.

Frankly, I think that any assumptions about larger organisations being harder attack targets is folly. We know from previous studies that the vast majority of breaches occur at the software layer and my view – which some may dispute – is that developers are developers are developers. Let me explain: these guys (of which I consider myself one), are the ones introducing the vulns and while some organisations invest more in their security education than others, I see no evidence that larger organisations take the security competency of their developers any more seriously than smaller organisations. The figures would seem to support this.

On social engineering:

The “carbon layer” of information assets (the user) is notoriously susceptible to social tactics such as deception, manipulation, and intimidation, and savvy threat agents know how to use this to their advantage.

I just like this one because I’ve never heard of the user being referred to as the “carbon layer” before. Nice :)

A graphic demonstration of information leakage through security misconfiguration

2012-04-05T17:08:00.001+10:00

A couple of days back I wrote about how 67% of ASP.NET websites have serious configuration related security vulnerabilities. In the post, I drew on figures collected by ASafaWeb and observed that small misconfigurations in config files could very easily disclose information that could be leveraged to exploit the application.

Quite a bit of discussion ensued through the comments, via Twitter and on Reddit. I found it slightly amusing that some camps felt these weren’t vulnerabilities at all as they couldn’t directly be exploited. Frankly, that’s a semantic argument; there’s a significant risk in what’s classified as “security misconfiguration”, this is why OWASP includes it in the Top 10.

Today I inadvertently stumbled across a perfect illustration of security misconfiguration which whilst not related to ASP.NET, was just what I needed to provide some perspective. This example comes courtesy of kogan.com who just a few hours ago, had a homepage which looked like this:

I’m not going to provide the original sized image because frankly, there’s a lot of info up there I don’t want to be responsible for redistributing (Google cache may well be taking care of that anyway). What I can tell you is that it consisted of:

The website framework (Django) and version
The identity the error was occurring under
The physical location of the script
The line of code the script was failing on
The version of Python being run
The web server (Apache) and version
The database being used (MySQL)
The host address of the database
The username connecting the database
The password being used to connect to the database
The exact query being run on MySQL
The SMTP server it was using
The username used on the SMTP server

Now this is no lightweight, static brochureware site – this is a full blown e-commerce website. This is a site which actually enables the purchase of electronic goods and ultimately asks customers to trust them with their credit card details.

But this isn’t intended to be a Kogan-bashing exercise, in fact I’m sympathetic because security misconfiguration is dead easy to get wrong. I’m no Django expert but the consensus seems to be that it was a simple case of still running in debug mode in production, which sounds about right:

Never deploy a site into production with DEBUG turned on.

Did you catch that? NEVER deploy a site into production with DEBUG turned on.

One of the main features of debug mode is the display of detailed error pages. If your app raises an exception when DEBUG is True, Django will display a detailed traceback, including a lot of metadata about your environment, such as all the currently defined Django settings (from settings.py).

Hey, it happens, and if you deploy enough web apps you’ll eventually do the equivalent of this yourself in your chosen technology.

Despite what it might look like, I’m actually leading somewhere with this: you absolutely must check every aspect of your security configuration post-deploy. It’s so easy for a simple setting to be changed during development, make its way into source control and then arrive with a bang in production. Practices like config transforms in ASP.NET are great mitigations but they’re not fool proof.

Going back to where I started in this post, this is why those security misconfiguration findings in ASafaWeb are so important. This is why you need to treat them seriously and this is why you need those post-deployment checks whether it be via ASafaWeb for your ASP.NET sites or simple manual checks for any technology stack.

So what now for Kogan? Well, that slipup wasn’t momentary; they’d been warned about this the day before and judging by their Twitter stream today, plenty of other people observed the error page in its full blown glory. At the very least, there will need to be password resets all around and frankly I’d be cycling as much other disclosed info as possible while they’re at it. Then of course there’s the issue of what resources were accessed – and possibly manipulated – using the disclosed information so some degree of forensic investigation is going to need to happen too. At best, a whole bunch of time is going to be blown making sure everything check out. At worst, well, use your imagination.

Check your websites, folks.