EPiServer hash format

[thorsheim]

I'd like to see support for EPiServer hash format:

EPiServer is a CMS - and much more. Info at www.episerver.com

Runs on top of Microsoft IIS, uses Microsoft .NETs capabilities for password hashing. .NET supports the use of PBKDF2, SHA-1 and more.

Default password configuration for EPiServer 6.x installations:
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
passwordStrengthRegularExpression=""

Creating a test user with a test password:
testUser:testPassword

Gives us the following data stored into DB (before any decode etc..):
Password hash: UQgnz/vPWap9UeD8Dhaw3h/fgFA=
Salt: fGJ2wn/5WlzqQoDeCA2kXA==

JtR got support in jumbo 12 for 1.7.2 in 2008, thx to Johannes Gumbel in Sweden. At least some older code on it is available here: http://fossies.org/unix/privat/john-1.7....fmt_plug.c

Best regards,
Per Thorsheim

[atom]

looks like this is just an encoding thing. rest is salted sha1. will do it when there is some spare time.

[thorsheim]

Thx atom, highly appreciated! :-)

[atom]

It looks like that in the JtR source is somehow different to your expectation. I guess the algorithm changed in the meanwhile.

• Inside the JtR source it says the salt length is of fixed size 30 (binary).
  
• Your base64 encoded example salt decodes to a salt of length 16 (binary)?
  
• JtR expects an hex format, not base64.
  

This is from JtR source with their values and it works:

root@ht:~/oclHashcat-plus-0.08# perl -e 'print "\x5F\x1D\x84\xA6\xDE\x97\xE2\xBE\xFB\x63\x7A\x3C\xB5\x31\x8A\xFE\xF0\x75\x0B\x85\x6C\xF1\x83\x6B\xD1\xD4\x47\x01\x75Abc.!23\x00"' | sha1sum
4d5efdfa143edf74193076f174ac47cebf2f417f -

I played a bit with your Base64 values:

Hash: UQgnz/vPWap9UeD8Dhaw3h/fgFA= -> 510827cffbcf59aa7d51e0fc0e16b0de1fdf8050
Salt: fGJ2wn/5WlzqQoDeCA2kXA== -> 7c6276c27ff95a5cea4280de080aa45c

root@ht:~/oclHashcat-plus-0.08# perl -e 'print "\x7c\x62\x76\xc2\x7f\xf9\x5a\x5c\xea\x42\x80\xde\x08\x0a\xa4\x5ctestPassword"' | sha1sum
3e0f809853d3fbdf392a2959ccf803ee6312d401 -

... does not match, so i tried original algorithm:

root@ht:~/oclHashcat-plus-0.08# perl -e 'print "\x7c\x62\x76\xc2\x7f\xf9\x5a\x5c\xea\x42\x80\xde\x08\x0a\xa4testPassword\x00"' | sha1sum
988c21fec2c4fd168201bba7b7ec4f266a270ecd -

... still does not match

Without the exact algorithm I cant do anything, sorry

[thorsheim]

It looks like that in the JtR source is somehow different to your expectation. I guess the algorithm changed in the meanwhile.

• Inside the JtR source it says the salt length is of fixed size 30 (binary).
  
• Your base64 encoded example salt decodes to a salt of length 16 (binary)?
  
• JtR expects an hex format, not base64.
  

This is from JtR source with their values and it works:

root@ht:~/oclHashcat-plus-0.08# perl -e 'print "\x5F\x1D\x84\xA6\xDE\x97\xE2\xBE\xFB\x63\x7A\x3C\xB5\x31\x8A\xFE\xF0\x75\x0B\x85\x6C\xF1\x83\x6B\xD1\xD4\x47\x01\x75Abc.!23\x00"' | sha1sum
4d5efdfa143edf74193076f174ac47cebf2f417f -

I played a bit with your Base64 values:

Hash: UQgnz/vPWap9UeD8Dhaw3h/fgFA= -> 510827cffbcf59aa7d51e0fc0e16b0de1fdf8050
Salt: fGJ2wn/5WlzqQoDeCA2kXA== -> 7c6276c27ff95a5cea4280de080aa45c

root@ht:~/oclHashcat-plus-0.08# perl -e 'print "\x7c\x62\x76\xc2\x7f\xf9\x5a\x5c\xea\x42\x80\xde\x08\x0a\xa4\x5ctestPassword"' | sha1sum
3e0f809853d3fbdf392a2959ccf803ee6312d401 -

... does not match, so i tried original algorithm:

root@ht:~/oclHashcat-plus-0.08# perl -e 'print "\x7c\x62\x76\xc2\x7f\xf9\x5a\x5c\xea\x42\x80\xde\x08\x0a\xa4testPassword\x00"' | sha1sum
988c21fec2c4fd168201bba7b7ec4f266a270ecd -

... still does not match

Without the exact algorithm I cant do anything, sorry

Hm. Well, I will spend some time looking for the answers to this little puzzle. I'm pretty sure it can be found somewhere inside the episerver documentation, second I'll ask some other friends in crypto to have a look at it. :-)

I'll get back as soon as I have something more useful. Thx atom!

[atom]

There were some problem with converting the base64 values. Thanks to @sraveau for mentioning.

However, problem still exists:

root@sf:~/oclHashcat-lite-0.10# perl -e 'print "\x7C\x62\x76\xC2\x7F\xF9\x5A\x5C\xEA\x42\x80\xDE\x08\x0D\xA4\x5CtestPassword"' | sha1sum
8aff884cd7a4f9d330cb34f765867d12afa660f6 -

... does not match, so i tried original algorithm:

root@sf:~/oclHashcat-lite-0.10# perl -e 'print "\x7C\x62\x76\xC2\x7F\xF9\x5A\x5C\xEA\x42\x80\xDE\x08\x0D\xA4testPassword\x00"' | sha1sum
db43ccc9d706b0fe503de2706f1e0b330a9261f2 -

[thorsheim]

(also posted to the john-users mailing list just now):

Status is as given in the hashcat thread, except that I also asked @episerver if they could provide any insight:
http://www.twitter.com/thorsheim/status/...0929893377

And they replied:
http://www.twitter.com/episerver/status/...2474875905

..... (break for phone call):

As I started to respond to this e-mail, I got a call from an episerver representative who had both knowledge & interest in helping out, and we talked for quite some time. (Thank you!)

Yes, the episerver format in john is out of date. Somewhere around version 4.x of episerver they dropped using their own crypto implementations and went for using Microsoft .NET provided algorithms instead. episerver is now at 6.2x if I remember correctly.

What I forgot to mention in my post at hashcat forums is that the config also has an option named "passwordformat", with default value of "1". I got that one answered; it is related to the .NET configuration. In fact; depending on your .NET configuration, your episerver could seriously be at risk.

The good news; the default install seems to provide decent security, and probably better than many other solutions floating around. (Oops, marketing talk... sorry)

By default episerver will rely on the SqlMembershipProvider in .NET for securing your passwords. You can do cleartext or reversible encryption if you want, and you can do authentication against Microsoft Active Directory (SSO). Default though is SHA-1 with salt.

More info here: http://msdn.microsoft.com/en-us/library/...ormat.aspx

A list of cryptograhic services provided in .NET can be found here:
http://msdn.microsoft.com/en-us/library/92f9ye3s.aspx

There are also those who tries to implement bcrypt in there as well:
http://stackoverflow.com/questions/64607...rp-asp-net

There is lots more to be read about .NET etc, but I'm nowhere near being a programmer, and will not pretend to be one either.

Again; the good news is anyone running episerver also has .NET, and can pick from a good list of algorithms etc in order to protect their users passwords.

The bad news: I guess many episerver installations are running on default .NET configurations, probably making it easier to crack the password hashes than with a customized configuration. Of course when configured by someone who really understands what he/she is doing.

I hope this will aid in replacing current code for episerver hashes in john (and eventually hashcat + others). There is still some reading to do in Microsofts documentation, even for the default config settings that are supposed to be SHA-1 with salt.

--
Best regards,
Per Thorsheim

[atom]

Awesome Per, thanks for clarifying this. Do you have more informations about the sha1 salting algorithm? I tried several ones I know from but non worked. Maybe some source available somewhere?

[thorsheim]

Awesome Per, thanks for clarifying this. Do you have more informations about the sha1 salting algorithm? I tried several ones I know from but non worked. Maybe some source available somewhere?

I'll head straight for some of my episerver expert colleagues tomorrow at work, to see if I can figure out the exact details of the default configuration in .NET.

I'll be back. :-)

[sk5t]

Answered here: https://twitter.com/#!/skradel/status/18...9412002816
It's simply sha1(salt | utf16bytes(secret)). Don't blame .NET, blame the lazy MembershipProvider implementation... you could verify this (and investigate other possibly behaviors) by viewing the assembly containing the MembershipProvider in something like ILSpy.