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 <membership> 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”
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…”
Troy Hunt has published the hashes of 306,000,000 passwords that have been breached. And exposed it as a web service.
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”
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 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:
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.
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
<httpCookies> set requireSSL:
<httpCookies requireSSL="true" />
<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!
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:
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.