Author Archives: Jason Montgomery

A Principal and Senior consultant for over 13 years at ATGi (www.atgi.com). I’ve worn many hats – Unix/Linux/BSD sysadmin, domain admin, network engineer, web developer, programmer, architect, DBA, consultant, security specialist, ethical hacker, and author. I’ve had the added benefit of straddling both the Microsoft Windows and Unix/Linux/BSD platforms and have extensive experience with .NET and I am the Lead Author for SANS DEV544 .NET Development course. Also, I had the pleasure of co-authoring Profession K2 blackpearl, (c) Wiley Press 2009 (WROX).

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

Session Attacks and ASP.NET – Part 1

8
Posted by Jason Montgomery on June 14, 2009 – 9:14 pm
Filed under .Net, Sessions

I’ve spent some time recently looking for updated information regarding session attacks as they apply to ASP.NET and am still not completely satisfied with how Microsoft has decided to implement session management  in ASP.NET 2.0+ (haven’t looked at 4.0 beta yet).

Before illustrating how a specific attack works with some specific countermeasures for ASP.NET (in Part 2), it’s important to understand the Session and Authentication architectures in ASP.NET.

ASP.NET Session Architecture

Session state is setup and maintained through an HTTP Module. If the ASP.NET web.config file is setup to enable session stae, the this HTTP Module kicks into gear and the first time the web application uses the session object and the user doesn’t already have a session, the ASP.NET Session module will drop a cookie on the client or do some URL rewriting to put the Session ID in the URL. All authentication and authorization mechanisms in ASP.NET are also handled through HTTP Modules (Windows, Forms, Passport). The figure below illustrates the ASP.NET HTTP pipeline functions – a request is processed by every installed module and finally processed by a handler.

httpmodule

ASP.NET HTTP Pipeline – HTTP Modules and Handlers

What’s interesting about this architecture is that the session management and the authentication modules are completely decoupled and have no awareness of each other. This allows Sessions to function with or without any type of authentication – functionally, this can be useful. However, from a security perspective (depending on what you’re trying to accomplish) this can be somewhat of a problem.

So, for example, consider next Forms Authentication. If enabled,it uses a completely different cookie than the session cookie (or different URL parameters if using cookieless). Likewise, with Windows Authentication (integrated), Client Certificates, or Basic Authentication – even though there is no need for the second cookie, it still is decoupled from the authentication mechanism and will function completely independent of each other.

So before moving on, the take-away point about ASP.NET is this – ASP.NET Session is decoupled from any type of authentication. They are completely unaware of each other.

Next let’s look at a specific session attack…

Session Fixation

Session Fixation is a specific attack against the session that allows an attacker to gain access to a victim’s session. The attack starts with the attacker visiting the targeted web site and establishing a valid session – a session is normally established in one of two ways – when the application delivers a cookie containing the Session ID or when a user is given a URL containing the Session ID (normally for cookieless). In this step, the attacker has fixed, or locked in, a known good session.

The attacker, having fixated on this session, will then entice/trick the victim into using this Session ID. At this point the attacker and victim share the same Session ID. Now anytime the information stored in this fixated session is used to either make decisions for the victim or display information only the victim should see – these can be potentially used and/or viewed by the attacker.

This does imply that the victim must do something to affect session before the attacker can take advantage of them. For example, if a flag is stored in session that is used to indicates if a user is authenticated as well as the database key used to extract information for that user – then the attacker will wait for the victim to authenticate and then visit portions of the site they wouldn’t normally be allowed to visit, seeing anything that the victim sees – as long as they have the same authorization level, since the decisions to allow access and view user information were controlled by information stored in session.

See http://www.acrossecurity.com/papers/session_fixation.pdf for a nice writeup on Session Fixation.

The Countermeasures to session fixation are as follows (as described in the paper above):

  1. Prevent Logon to chosen sessions
  2. Prevent Attackers from obtaining valid session ID (if possible)
  3. Restricting Session ID usage (prevention techniques that also apply for stolen/hijacked session ID’s as well as session fixation)

Does ASP.NET Pass?

Does ASP.NET OUT OF THE BOX get a passing grade for protecting Session, considering the three countermeasures above? I’ll address each countermeasure and how ASP.NET stacks up below.

Prevent Logon to chosen sessions:

Some attempt to use the regenerateExpiredSessionId property of the <sessionState> element in web.config in hopes it will help.

The MDSN documentation states:

“regenerateExpiredSessionId – Specifies whether the session ID will be reissued when an expired session ID is specified by the client. By default, session IDs are reissued only for the cookieless mode when regenerateExpiredSessionId is enabled. For more information, see IsCookieless. ”

So this is only for EXPIRED (or non-existent) sessions, and old cookie expired Session ID’s will be thrown out.  So if the attacker retrieves a good session from the ASP.NET web application, and sends it to the victim – well, it’s not expired yet (unless the victim doesn’t fall for the attack in the allotted session timeout). This is a good thing, however, Session Fixation already requires an active session, not an expired one…so this particular attribute will not help.

Prevent Attackers from obtaining valid session ID (if possible):

SSL/TLS cannot be enforced in the web.config for Session ID delivery, this is only an option for the Forms Authentication cookie.

Restricting Session ID usage:

The ability to tie a session the authentication is not automatic – it requires custom code. Considering session management and authentication modules are out-of-the-box, ASP.NET could potentially couple them.

Comparing ASP.NET session management implementation to the recommended countermeasures for session fixation doesn’t look so good…ASP.NET however, does mark the cookie HTTPOnly, which does helps prevent XSS attacks against the session on *most* of the latest browser versions – this certainly reduces risk, but it is not foolproof.

There have been bug submissions to MS asking for a bug fix for their session management implementation [1] and others asking that Microsoft fix the way ASP.NET handles sessions [2] to address issues described in this two part post. The recommendation to fix these issues aren’t necessarily unreasonable; however, the way ASP.NET session management is implemented, ‘fixing’ the issues might not be so straightforward and might even be simply a side-effect of how session management was implemented and not necessarily just an oversight or vulnerability.  The down-side of the chosen implementation is that developers need to be educated on this specific nuance of ASP.NET session management and know when and how to protect their web applications accordingly.

Next, Part 2 will explore specific attack vectors, countermeasures and some thoughts that will hopefully spur on some additional discussion.

References

[1] MS Connect Denied Bug Submission on Session Fixation
https://connect.microsoft.com/feedback/viewfeedback.aspx?FeedbackID=143361&wa=wsignin1.0&siteid=210

[2] Preventing Session Fixation through Session ID Regeneration in Java and ASP.NET
http://keepitlocked.net/archive/2007/12/27/preventing-session-fixation-through-session-id-regeneration-in-java-and-asp-net.aspx

How Not to Do Web Site User Registration

48
Posted by Jason Montgomery on May 23, 2009 – 4:47 am
Filed under Uncategorized

The Internet is FULL of real life scenarios of how NOT to do web application security…it is unfortunate when a large, popular site shows the rest of the world some form of this inappropriate behavior. Unfortunate because it becomes both a HOW-TO for programmers, marketers, decision makers to repeat as well as an illustration of what NOT to do for the infosec community to harp on – both are undesirable.

Here’s a few screen shots I took while going through Account Registration on WordPress – this is a classic case study in what not to do.

While jumping through common hoops of account creation, WordPress required email address verification before activating my newly created account. After creating my account and waiting a few minutes, I was greeted with the following email requesting that I click on a link to verify that my email address did, in fact, belong to me:

Email notification of WordPress Account Activation Requirement

The names and email addresses have been removed to protect the innocent. This is pretty standard so far, no surprises – create an account, get an email, click the activation link, activate the account, login, good to go…

But then to my surprise, I’m greeted with the following Activation web page:
WordPress Credential Reminder

This is one of the very very few times I recall being shown both my user name and password on a web site. This can only mean that WordPress is storing my password in plain-text in their database or using reversible encryption – I suspect the former – plain text…with this knowledge I then glance up at the URL. *Sigh* – http:// – no ’s’, meaning this was sent over the wire unencrypted for anyone paying attention as my credentials bounced from Columbus, OH up to Cincinnati, OH -back down to Atlanta, GA and then over to Dallas, TX – at first I wanted to kick myself – I should have been paying more attention to the activation email link and noticed  the lack of the ’s’ and added it manually – but wait, why would I? I didn’t expect to be shown my credentials…this is not common.

Then I notice I have new Email…WordPress has also sent me an email notifying me that I have activated my account. View it in all its glory:Your Account has been Successfully Activated

Good GOD how many times do I need my credentials delivered to me over an unencrypted channel! Not to mention they managed in the email to group all information conveniently together – user name, password, AND login link…

I’ve seen flawed Password Reset schemes, but I think this might be the first poorly implemented Registration workflows I’ve run across and took notice.

Some quick tips for a more Secure User Registration:

  1. Perform all operations containing credentials (user name/password) over a secure connection. E.g. SSL/TLS
  2. Store passwords in the database using a one-way hash algorithm like SHA-1.
  3. Additionally, salt users password when generating the hash based on something unique to the user whose account you are protecting. The salt doesn’t have to a secret piece of information.
  4. If passwords must be recoverable (which should be a RARE requirement) store them using accepted open encryption algorithms – e.g. AES, 3DES.
  5. Never email a user their password.

Finally, I noticed that if you have my activation ID – without an authenticated session, you can go back and visit the activation page – anyone can now retrieve my email address and login name. Thankfully after the account is activated the first time, all subsequent requests do not reveal the password again, however, they do reveal my email address and user name which is completely unnecessary. Here’s what you see if you visit the activation page again after already activating your account:
What Subsequent Visits to the Activate Page Reveals
I’m going to add a 6th tip: There’s no need to keep telling the user they have activated their account once the activation key has been used- and there’s also no need to reveal the user name and email address to an unauthenticated user on the activation page – this only gives an attacker more information that they can use to reset the victim’s password and gain access to the account – for instance, when an attacker finds a valid activation id they could follow it up with a spear phishing attack to easily gain that final piece of information from the victim to compromise their account.

And here comes Tip #7: Since the activation page can be revisited and because the Activate ID is in the URL, this URL will be cached not only on the local users computer browser, but in web server logs, proxy server logs, router logs, firewall logs, etc. on potentially any system from here to Texas. If the activation key was discarded after first use or did not reveal any interesting information to begin with..who cares…but this is not the case.

While these features may be a benefit to users of WordPress (which is debatable, as it was overly repetitious), these features add an unnecessary level of Risk with little gain.

Also, I’d recommend going in and changing your WordPress password after registering – and hope they don’t email it to you again…they don’t appear to anyway…*fingers crossed*

* Update – it’s been over 16 hours and the activation link still works, revealing my user name and email – I’ll be checking back to see when it actually get’s removed. Additionally, I did not receive an email containing my updated credentials after I changed my password on WordPress…so the recommendation to change your password seems like a good one.

* Update 2 – Readers are reporting that WordPress does in fact hash the password, but only after mailing the plaintext one back to the user. And to clarify – many have suggested that WordPress is sending a randomly generated password. That is not the case. The password emailed to me was most certainly one of my creation.