0

This is my first question on SO so bear with me if this is stupid.

I am playing around with the password locking of worksheets in Excel (note: this is not the same as encrypting an entire excel-file).

The worksheet password is stored as a hash. If you use the Word "Jim" as password in Excel you get this salted hash as a result: l2nKB/0VLubEL2LL3MaanefnpLIJnZVJlTDDc4MVZFX70b50/YFBpQApC4C8fPKL+h+6xqVyakU/CLhKmsuN/w==

(EDITED) But that is only 88 characters long. Excel is supposed to use SHA512 hashing, so why isn't the hash 128 characters long? And why are there nonletters and non numbers as part of the hash? Regardles if its in base64, should there really be any other characters than numbers orletters?

(This question is about the hashing process that Excel uses. Removing protection is something else which I am not currently talking about. So you don't need to put up any helpful suggestions about that now :) If you are interested in that topic it might follow in a separate question )

Jimmy J
  • 1
  • 1
  • 3
  • https://stackoverflow.com/questions/18236106/what-is-the-length-of-a-hashed-string-with-sha512 – Axel Richter Aug 18 '17 at 08:50
  • @AxelRichter Thank you for the link! However I am still wondering since my hash contains characters that I thought were not legal in base64. Given that I am a total noob at this I might be asking a very stupid follow up question, sorry if that is the case! – Jimmy J Aug 18 '17 at 10:55
  • 1
    "my hash contains characters that I thought were not legal in base64". It does not. Legal Base64 characters are a-z, A-Z, 0-9, + and / (making for, unsurprisingly, 64 possibilities, or 6 bits per character), with = for padding. The Base64 string represents exactly 64 bytes, which is the 512 bits of a SHA-512 hash. As a hexstring, it would be `9769CA07FD152EE6C42F62CBDCC69A9DE7E7A4B2099D95499530C37383156455FBD1BE74FD8141A500290B80BC7CF28BFA1FBAC6A5726A453F08B84A9ACB8DFF`. This is longer as each character can represent only 4 bits. – Jeroen Mostert Aug 18 '17 at 11:03
  • @JeroenMostert Many thanks! Did you code the conversion or use an online converter? I did try the latter but did not get any valid result. base64decode.org declared the input to be invalid and cryptii.com gave a result with too few characters (93 without spaces, 123 with). The salt is btw gk0EahXb4wniRJmrE+5q+Q== , which I have guessed to be plain text and also in base64. Do you think you could help me with converting that to plain text and also even hexadecimal? Apparently, I am doing something wrong there. – Jimmy J Aug 18 '17 at 12:51
  • 1
    From PowerShell: `[BitConverter]::ToString([Convert]::FromBase64String("[string]")).Replace("-", "")`. Online conversion probably fails because the hash is a sequence of bytes, not encoded characters. You can't convert it to "plain text" because it *isn't* plain text -- if it were there'd be no need to Base64 encode it, after all. (And no, the salt isn't plain text either, you'd want a sequence of random bytes there.) – Jeroen Mostert Aug 18 '17 at 13:08
  • @Jeroen, thanks! You are ofc right about why the hash is not “online convertible”! Regarding the salt though, do you think you could elaborate? I was thinking that the hashing process of the password started by adding the salt as text before the hashing started. I.e. if salt is 123 and password is Jim: 1. Creation of salted password -> 123Jim. 2. Hashing of this into a salted hash. But perhaps this is done in some other way? For example separately converting salt and password to binary expressions, then adding them together and finally hashing this amalgamated binary expression? – Jimmy J Aug 18 '17 at 13:43
  • I have no idea how Excel specifically applies the salt, but a password is hashed by encoding its characters to bytes (let's say in UTF-8) and hashing those. You can't directly hash characters. So you could apply a salt by adding characters to the password, but you could also apply it by adding bytes to its encoded representation. The latter is much easier if your salt is generated at random, because random bytes are easier to get than random characters (all bit patterns are valid bytes; not all bit patterns are valid encodings of characters). – Jeroen Mostert Aug 18 '17 at 13:48

0 Answers0