26

I noticed in the html of my router this parameter:

form.addParameter('Password', base64encode(SHA256(Password.value)));

So when I type in the password passw I get this via sslstrip:

2018-09-25 21:13:31,605 POST Data (192.168.1.1):
Username=acc&Password=ZTQ1ZDkwOTU3ZWVjNzM4NzcyNmM2YTFiMTc0ZGE3YjU2NmEyNGZmNGNiMDYwZGNiY2RmZWJiOTMxYTkzZmZlMw%3D%3D

Is this hash easy to crack via bruteforce/dictionary? I am still a beginner, but that looks like double encryption to me. Also, is there some faster way of getting this password than cracking it?

Improve this question
3
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop ♦
    Sep 28, 2018 at 18:31
  • 7
    TL;DR, this isn't "double encryption". Base64 is an encoding—not encryption—and is reversible by design. SHA-256 technically isn't reversible, but with a caveat: this property is only true if the input is sufficiently unpredictable. For predictable inputs, it's extremely fast to simply guess a bunch of inputs and check if the output matches. A very rough lower-bound for security here would require that password to be at least 13 characters long and have been randomly chosen from uppercase and lowercase letters, digits, and ten symbols ((26+26+10+10)^13 is roughly 80 bits of entropy).
    – Stephen Touset
    Sep 28, 2018 at 19:39
  • The real question is: why so you want to know the password? You could send the same string to the server for validation and it will be ok without even knowing its real value.
    – Shmuel H.
    Sep 30, 2018 at 16:58

4 Answers 4

Reset to default
70

It's a base64 unsalted sha256 hash. It's not double encryption, but merely an unneeded encoding.

An unsalted hash means it's trivial to just search the hash on Google and probably it will find the result.

Improve this answer
5
  • 6
    Only trivial if the password is common.
    – zaph
    Sep 25, 2018 at 20:37
  • 23
    I meant "is trivial to search", not to find the password. But to bruteforce SHA256 using any bitcoin ASIC is trivial too. A Dragonmint 16T can do 16TH/s and would bruteforce a 12 chars alphanumeric password in less than 100 hours. A 8 chars alphanumeric would fail in a tenth of a second...
    – ThoriumBR
    Sep 25, 2018 at 20:44
  • 1
    Sure a Dragonmint is fast and specialized hardware. That is why using SHA256 is not secure for passwords, what is needed is a slow method such as PBKDF2, Argon2i or comparable methods, these are slow and should be used with parameters to require about 100ms or CPU time and additionally Argon2i requires substantial memory as well. Try e88f244abd61582387cc2afc0476e112550f24395cdf338ed7ad7deace2e6ebe, it is a the SHA-256 hash of a 12 character password.
    – zaph
    Sep 25, 2018 at 21:30
  • 6
    @zaph sure, everyone agrees that a slow method is best. That isn't the question though - the question is if the password security here is good, and the password security here uses a comparatively fast algorithm (SHA256). The fact that slow algorithms are better is a red herring.
    – Conor Mancone
    Sep 26, 2018 at 2:50
  • 6
    @ThoriumBR I'm 97% sure it wouldn't. Bitcoin ASICs are designed for double SHA-256, reporting only hashes starting with zeroes, hashing exactly two SHA blocks, and changing only the second block between iterations.
    – Maya
    Sep 28, 2018 at 15:00
82

I URL decoded it, then decoded it from base64, then passed it to an online hash database.

The result was: 

Hash                                                                Type    Result
e45d90957eec7387726c6a1b174da7b566a24ff4cb060dcbcdfebb931a93ffe3    sha256  passw

The fact that this is an un-salted hash makes it easy to look up. All the encoding is a convenience for the login service, not a security control.

With a salt, you cannot just look it up, so you would need to bruteforce. If you knew the salt, success depends on the password and the wordlist you use. There are methods to make the wordlist more efficient for bruteforcing, but it ultimately is a function of time.

Improve this answer
3
  • 6
    Knowing embedded device thinking, they probably just liked only having to deal with one data length for the password...
    – le3th4x0rbot
    Sep 26, 2018 at 18:08
  • 10
    @BaileyS more likely it's just an easy way to make binary data URL-safe.
    – Kevin
    Sep 26, 2018 at 23:21
  • Specifically SHA256 (and other hashing algorithms) is just returning a 256 bit number. Often the implementation of such functions returns the number already encoded in hexadecimal. Presumably in this case, it's raw binary data, hence the need to encode it in base 64 (which is not the norm for hashes, so kinda weird, but perfectly acceptable). Although if they're base 64 encoding a hash that's already hex, then that's especially weird and might be a sign that they don't know what they're doing (I mean, they are using an unsalted hash!).
    – Kat
    Oct 3, 2018 at 18:45
17

This is trivial to break due to the following:

  1. Base64 isn't encryption at all, it is an encoding scheme. Decoding Base64 is trivial.

  2. SHA256 is a cryptographic algorithm designed for validating data and thus is designed to be fast. This means that specialized computers with multiple GPUs can check passwords hashed with SHA256 at incredible speeds. The record for password cracking SHA256 at the time of writing is 21.4 GH/s (21 Billion hashes per second) set by 25 GPUs. For the intend of securely hashing a password SHA256 is poor choice. Key derivation functions are the way to go. SHA256 is weak for password hashing but great for data/message validation.

Improve this answer
1
  • Welcome @Kevin to this community.
    – hola
    Oct 1, 2018 at 3:59
13

Everyone agrees that using an unsalted hash is very bad, and that sha256 is not an ideal hash function. However this wisdom relates to the storage of passwords, not their transmission.

We don't know how the password is validated on the target device.

For all we know the data is subsequently passed through a password stretching function, salted and hashed on the target device (which would be secure) or it is simply compared with a stored literal value (insecure).

If the communications with the router is always via HTTPS as inidicated in the question, then this adds nothing to the protection of the data in transit and is redundant. If the communication were via HTTP, it could be argued that it prevents some very trivial attacks (but not, for example, a simple replay attack).

Improve this answer
2
  • "We don't know how the password is validated on the target device." - chances are high this barely encrypted password is stored as is. Why would the developer hash it for transmission otherwise?
    – Zac67
    Sep 29, 2018 at 7:49
  • 1
    @Zac67 So that the password entered by the user isn't leaked from an intercepted transmission, maybe. It doesn't make the target device any more secure, but helps against attacks on password reuse.
    – Bergi
    Sep 29, 2018 at 11:35

You must log in to answer this question.