Reset your Sitecore Admin password to ‘b’ when using SHA512 hashing

2017-10-192022-08-17 Andy Burnshashing, passwords, Security4 Comments

Okay, this this relates to my recent post on password hashing in Sitecore, and why we should move away from SHA1. Let’s say you’ve decided to use SHA512 for a brand new instance like Sitecore recommend…

When you create a new website, you must change the weak default hash algorithm (SHA1) that is used to encrypt user passwords to a stronger algorithm.

To change the hash algorithm:

Open the web.config file and in the node, set the hashAlgorithmType setting to the appropriate value. We recommend SHA512.

Okay, funky, but how do I make the existing admin’s password work? Continue reading “Reset your Sitecore Admin password to ‘b’ when using SHA512 hashing” →

Hashing for fun and profit…

2017-10-052017-09-29 Andy Burnspasswords, Security1 Comment

Nope, not cannabis, nor potato, but rather this:

Yup, password hashes in Sitecore. Unfortunately, they’re not all that secure – but they can be. Continue reading “Hashing for fun and profit…” →

Check Users Passwords during Registration/Login

2017-09-292017-09-29 Andy Burnscrypto, passwords, Security1 Comment

Troy Hunt has published the hashes of 306,000,000 passwords that have been breached. And exposed it as a web service.

https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-passwords/

Awesome!

This lets you tell a user if a given password has appeared in a breach. You send the service a hash of the password, and Troy’s web service responds if that hash has appeared in a breach.

Why is that useful? You can pro-actively inform users if their password has been breached (and recorded in haveibeenpawned) at either registration or login. You may want to block users from using that password, or you could just warn them.

Continue reading “Check Users Passwords during Registration/Login” →

Sign up for Sitecore Security Notifications

2017-04-26 Andy BurnsSecurityLeave a comment

I was asked the other day, where do you sign up for Sitecore’s security notifications? Well, I get them – but I don’t think I ever did. I suspect it was just part of doing their developer’s course.

However, you can apparently do this here: http://www.sitecore.net/landing/xc/2016/xc-ops-sitecore-security-notifications

I’ve not tried it, though.

Sitecore Permissions

2017-01-182017-01-13 Andy BurnsPermissions, SecurityLeave a comment

Sitecore permissions are always a bit of a pain to figure out. You’ve got the question of inheritance of rights from parent nodes, and how role rights conflicts are resolved.

Well, these two links are particularly useful, I found:

Assigning Access Rights
The Inherit Access right
… and the section of the Sitecore documentation that they’re in

There’s quite a lot of reading there, but it’s good content. The easiest way I’ve found for considering permissions is:

Unspecified (effectively no-access) is beaten by Inherited rules (variable) is beaten by Allowed (has access) which is beaten by Deny (No access).

In other words, an explicit Deny will block access to a user.

If there is a conflict between explicitly assigned roles, Deny wins.

If rights are assigned directly to a user (rather than a role) they win – though you shouldn’t be assigning rights directly to users. It’s unmanagable in the long term.

Simple, right?

Secure your Sitecore Cookies

2016-10-212016-10-21 Andy BurnsASP.NET, cookies, HTTP, HTTPS, Security, SSL2 Comments

So a Sitecore site I’ve been working on recently underwent a penetration test, which turned up an interesting item. The ASP.NET_SessionId and SC_ANALYTICS_GLOBAL_COOKIE cookies aren’t set with the ‘Secure’ flag. Further, my own checking showed that the .ASPXAUTH token was also set without the ‘Secure’ flag.

As the entire site is only served over HTTPS, this seems to be a bit remiss.

Fortunately, there are a couple of easy fixes to this that can be set in the Web.config

Under <System.Web> and <httpCookies> set requireSSL:

<httpCookies requireSSL="true" />

And in <forms> set requireSSL too.

<forms name=".ASPXAUTH" cookieless="UseCookies" requireSSL="true" />

This latter one is needed for the .ASPXAUTH cookie, but that seems to do it.

Don’t forget to set the HTTPOnly flag as appropriate for your cookies too!

Awkward Page Request Validation in Sitecore

2016-02-092016-01-11 Andy BurnsSecurity, webconfigLeave a comment

I was configuring a new Sitecore 8.1 instance. It’s a vanilla, straight-off-the-installer instance, and yet I noticed that the node’s request validation was off:

<pages validateRequest="false">

This did, at least, come with a comment above it:

If requestValidationMode attribute of httRuntime node is set to 2.0, Sitecore requires this setting to be set to “false” for Sitecore client to work and it shouldn’t be changed. You can however set ValidateRequest attribute in the @Page directive to “true” for your layout .aspx files.

This is bonkers. The default configuration for this site is to remove request validation on my brand new Sitecore instance on the off-chance I should want to configure it to use an older, non-default requestValidationMode. Instead, I should stumble across this comment in the web.config file and add the appropriate attribute to all the layouts of my solution. And someone thought that this was a good idea?

Even if I were upgrading and I did rely on the httpRuntime requestValidationMode being 2.0, I would prefer that this was set to true, with instructions for how I should handle it in the case of an upgrade.

Crazy. One to be aware of.

Encrypting your ViewState

2016-02-082016-01-11 Andy BurnsMachineKey, Security, ViewstateLeave a comment

This one puzzled me a bit – but I wanted to encrypt my viewstate in Sitecore. I set my machine key, and set my algorithms – but it didn’t seem to do anything.

Well, the <pages> node has a viewStateEncryptionMode setting.

<pages validateRequest="true" viewStateEncryptionMode="Always">

Turn that on, and all seems good.

Disable trace.axd

2016-01-292015-12-17 Andy BurnsSecurity, webconfigLeave a comment

This is annoying misconfiguration I’ve come across a few times – tracing has been enabled on production systems.

Having tracing enabled allows an attacker to view the last 50 web requests made to the server, including information like Session ID values and the physical path to the requested files.

Nasty.

One can easily turn this off, though, by setting the <trace> node of web.config…

<trace enabled="false"...

However, you can do a bit more than that. I believe that this problem occurred on live sites because configuration files were promoted from development to production. To this end, you can set localOnly="true" – this means that trace is only available on the local developer’s machine. This doesn’t substitute for disabling trace, but it does help reduce that risk.

The trace element – https://msdn.microsoft.com/library/6915t83k(v=vs.100).aspx

Secure your ASP.NET Viewstate

2016-01-262016-01-13 Andy BurnsSecurity, ViewstateLeave a comment

This is just a short reminder for myself – when configuring ASP.NET websites, don’t forget to Secure the viewstate. If you don’t, then the ViewState is just base64 encoded – and can be decoded.

Securing this involves:

Setting a machine key in the web.config. In a load balanced environment, this machine key should be the same on all front-end servers; it’s used in encryption and decryption of the viewstate, and so has to be the same on all webservers. If it is not, and a user’s session skips to another server, then decryption of the viewstate will fail.
Make sure the the validation algorithm is set to ‘AES’
Make sure that the ‘decryption’ algorithm is set to auto.

That seems to be it. I did see instructions that said that I should:

On the <pages> node, add the attribute viewStateEncryptionMode=”Always”

… ~~but I didn’t seem to have to do this~~. Actually, in the end I did have to set this too.

Edit: How to generate your machineKey easily

Andy Burns' Blog

Whatever I'm working on

Security